Best practice per l'autenticazione / sicurezza delle applicazioni Web (qualsiasi piattaforma)


12

Oggi ho ricevuto una domanda dal mio manager che mi chiedeva cosa pensavo fosse un design accettabile per l'autenticazione di un'applicazione web form, specialmente per quanto riguarda la natura di molti browser popolari a "Ricorda password" per i campi di accesso tipici del tuo nome utente password .

Ho problemi a trovare una risposta che ritengo accettabile. Alla luce degli imbarazzanti difetti di sicurezza di Sony, voglio davvero stare attento, anche se i dati archiviati sulle persone hanno una sensibilità inferiore. Non stiamo memorizzando numeri di previdenza sociale o indirizzi, tuttavia stiamo memorizzando numeri di telefono, indirizzi e-mail e una foto di un visitatore.

È preoccupato che un utente possa semplicemente ricordare la password su un terminale pubblico, quindi qualcuno può semplicemente saltare su questo terminale e iniziare a visualizzare o modificare i dati in modo non autorizzato. Sono abbastanza certo tuttavia che, almeno sulle workstation Windows, il browser non "Ricorderà la password" tra gli account utente di Windows.

Oltre a ciò, sto implementando una crittografia della password unidirezionale sul lato server (archivia la password crittografata nel database, crittografa la password fornita dall'utente sul server, confronta con la stringa crittografata dal database). Non ci sono piani immediati per incorporare la crittografia SSL, ma questa è ancora un'opzione.

Ci sono grossi difetti di sicurezza con questo approccio? Hai qualche suggerimento migliore?


Quando si memorizza la password crittografata unidirezionale (cioè con hash), assicurarsi di utilizzare un hash forte (cioè non MD5) o saltare la password (vedere stackoverflow.com/questions/420843/… ) o entrambi.
Jordan Reiter,

Controlla il sito Web OWASP ( owasp.org ). Hanno molte informazioni di sicurezza molto utili, tra cui "cheat sheet" per vari protocolli.
Ralph,

Ci sono alcune linee guida per l'autenticazione del sito Web basata su moduli qui stackoverflow.com/a/477578/463478
Solo tu il

Risposte:


13

Alcuni consigli di alto livello:

  1. Archivia solo i dati di cui hai bisogno
  2. Crittografa sempre i dati sensibili (SSN, password, numero di carta di credito, ecc.) Quando li memorizzi
  3. Crittografa sempre il traffico utilizzando SSL durante la trasmissione / ricezione di dati riservati
  4. In caso di dubbi sulla sensibilità delle informazioni, crittografarle
  5. Non fidarti dell'input dell'utente (qualcuno tenterà di inserire qualcosa di brutto)
  6. Non fidarti dei tuoi dati (qualcuno può modificarli nel database, ad esempio iniettando script dannosi)
  7. Non rotolare la tua crittografia
  8. Proteggi i server che ospitano le applicazioni / i database
  9. Aumentare l'onere per gli utenti finali per motivi di sicurezza (restrizioni delle password, mai esporre le password, non inviare URL tramite e-mail, ridurre i tempi di sessione, ecc.)

Il mio suggerimento per te sarebbe quello di ottenere un libro sulla protezione delle applicazioni Web. Ci sono troppe informazioni da trasmettere in un'unica risposta / blog / articolo. Il solo argomento della crittografia è sostanziale.


Qual è il ragionamento alla base dell'utilizzo di SSL invece di implementare la propria crittografia? Considereresti di usare qualcosa come WS-Security per creare la tua crittografia? Configurare SSL può essere una seccatura.
Mr. Jefferson,

Questa è una buona lista di controllo. Sono sorpreso che non ci siano più voti positivi.
Kristofer Hoch,

2
@ Mr.Jefferson Direi che il 99.999999% delle volte non vuoi MAI "lanciare la tua crittografia".
Zach Leighton,


1

Direi che dovresti stare bene.

La maggior parte degli utenti sarà abbastanza brillante da non salvare la propria password su un terminale pubblico e le password verranno archiviate per profilo. Tieni presente che potrebbero semplicemente scriverlo su una nota adesiva o utilizzare una password debole.

Se la pagina di accesso non è crittografata su SSL, non sarebbe troppo difficile per un utente malintenzionato annusare quella password mentre viaggia attraverso la rete. Un buon lavoro ha hashing la password nel database, tuttavia, che impedirà a un potenziale aggressore di vedere le password di tutti (che potrebbero usare con l'indirizzo e-mail per tentare di accedere ad altri siti su cui l'utente potrebbe trovarsi).

Se desideri ancora, ci sono modi per disabilitare il comportamento del browser, come ha sottolineato Chad. L'ho visto solo sul sito Web della mia banca e sul sistema Live di Microsoft.


Ottimo post, ho dimenticato di aggiungere però che il nome utente non sarà l'indirizzo e-mail, tuttavia un utente avrà un indirizzo e-mail memorizzato nel sistema. È divertente menzionarlo, anche perché anche siti popolari come Facebook sono suscettibili di sniffing di pacchetti per add-mail e password.
maple_shaft

Voglio anche aggiungere che non sto sottolineando i difetti di sicurezza in Facebook come una "scusa" necessariamente per un modello di sicurezza scadente nella mia applicazione. Solo perché la mamma di Joey gli permette di guardare i film di R non funziona bene :)
maple_shaft

1

A un certo punto, non puoi (e non sei legalmente tenuto a) proteggere un utente da se stesso. La funzionalità "Ricorda password" può essere rischiosa, ma è un rischio assunto dall'utente. Allo stesso modo, se l'utente decide di riutilizzare la propria password per più servizi, assume anche questo rischio. Inoltre, non è necessario avvertirli di non scrivere la propria password su una nota adesiva e di incollarla sul proprio monitor, anche se spesso lo fanno anche gli utenti.

Cioè, fino a quando qualcuno litiga e modifica con successo le regole. Vedi anche: "Attenzione: i contenuti potrebbero essere caldi".


0

Non credo che tu possa controllare in modo affidabile se il browser ricorda o meno una password. È semplicemente dalle tue mani se il browser lo fa o no. Né è necessariamente un enorme rischio per la sicurezza per te . Si dovrebbe sempre presumere che gli attacchi possano essere fatti da accessi validi. Non dare per scontato perché qualcuno ha un utente / pass di accesso valido che non sarà all'altezza. Dopotutto, ci sono molti modi in cui le password possono cadere nelle mani sbagliate.

Immagino che ciò che potresti fare sia randomizzare ogni volta i nomi dei campi nel modulo di accesso. Invece di <input name="username", utilizzare qualcosa di simile <input name="user658667587". Ciò renderebbe inutili i nomi utente memorizzati nella cache. Ma non so se ne varrebbe la pena. Per non parlare degli utenti fastidiosi che non sono presenti su macchine pubbliche.

Se ti trovi in ​​una situazione estremamente sensibile alla sicurezza (operazioni bancarie, investimenti) puoi semplicemente chiedere alle persone durante l'accesso se si tratta di una macchina pubblica. Puoi anche memorizzare nella cache gli indirizzi IP noti quando le persone accedono e se accedono da una posizione diversa richiedono un numero pin non tipizzabile (ad esempio, fai clic sulle immagini) oltre al normale utente / pass. La mia banca fa qualcosa di simile a quello.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.