Passphrase di hashing in JavaScript lato client piuttosto che lato server - È valido?

Question

Passphrase di hashing in JavaScript lato client piuttosto che lato server - È valido?

#1 da (6 voti)

0

Ancora una domanda di salting-and-hashing-for-web-sites è stata lasciata sullo zerbino dello StackExchange di Information Security.

L'approccio spesso menzionato per la gestione delle password dei siti Web consiste nell'utilizzare un linguaggio lato server per utilizzare un algoritmo di hash appropriato (allungato o progettato in altro modo per consumare risorse di elaborazione eccessive), combinare con un sale randomizzato e voilà: a password memorizzata in sicurezza Ovviamente sto semplificando eccessivamente.

Anche se questo impedisce alle tabelle del database rubate di contenere passphrase potenzialmente riutilizzate, significa comunque che la password deve essere consegnata al server da sottoporre all'hash, il cui risultato viene confrontato con l'hash memorizzato. SSL lo protegge durante il trasporto, naturalmente, ma c'è ancora una finestra della passphrase in chiaro che esiste per l'hashing.

Cosa succede se l'hashing è stato effettuato sul lato client? L'utente userebbe comunque una passphrase che non corrisponde al risultato finale memorizzato e un individuo esperto di tecnologia che ignora il codice JavaScript e invia direttamente un hash non otterrebbe alcun risultato. Inoltre, l'hashing sul lato server potrebbe essere implementato per i client privi di JavaScript. In questo modo, il carico del server viene ridotto e un server comprimamente nascosto non otterrebbe alcuna password man mano che il sito continua a funzionare.

TL; DR: l'unico problema che riesco a vedere è che la randomizzazione del client per il sale non può essere considerata attendibile. È questa l'unica ragione per cui questo approccio non è più ampiamente raccomandato?

javascript cryptography passwords web-application salt

posta Louis Jackman 04.02.2014 - 16:52

fonte

1 risposta

Leggi altre domande sui tag javascript cryptography passwords web-application salt

Il mio WiFi e il mio computer sono stati violati? Protezione della password di amministratore locale contro software di terze parti

score 6 · Accepted Answer

L'hashing della password deve essere applicato per far fronte alla debolezza intrinseca delle password, ad esempio l'entropia bassa. Se l'hashing si verifica sul client o sul server, non importa molto per la sicurezza, a patto che si verifichi da qualche parte tra l'umano e lo storage. Poiché l'hashing della password buona utilizza un salt , l'hashing lato server, lato client memorizzato di solito comporta un round trip aggiuntivo (il client invia il nome utente, il server restituisce il sale corrispondente, il client hash la password e invia il risultato). Inoltre, poiché ciò che il client invia è equivalente alla password (che mostra l'accesso) e non si desidera memorizzare valori equivalenti alla password "così come sono" nel database, è comunque necessario hashing sul server - ma quello può essere un hash semplice, non salato, non cancellato.

L'hashing della password con Javascript può essere un problema, tuttavia: l'hashing della password è una corsa agli armamenti tra il difensore e l'attaccante. La funzione di hashing della password è deliberatamente lenta per rendere costosa la ricerca esauriente; ma questo rende uso costoso per tutti. Se l'hashing è fatto in Javascript, allora avverrà a velocità Javascript, cioè non molto veloce. Corrispondentemente, non sarai in grado di aumentare il numero di iterazioni il più alto possibile, rispetto alla situazione in cui si verifica l'hashing sul server.

Quanto sopra è la risposta generica, ma i dettagli possono variare. Gli interpreti di Javascript tendono a a diventare più veloci nel tempo. Ancora più importante, un determinato server potrebbe dover gestire molti client contemporaneamente, mentre ogni client deve solo preoccuparsi di se stesso. Se il server deve gestire 100 client al secondo e mantenere comunque il tempo di autenticazione entro un secondo, non può allocare più di 10 ms di valore della sua CPU per istanza di password; mentre con l'hashing sul lato client, il client può utilizzare un secondo al suo interno, che potrebbe essere sufficiente a compensare la lentezza di Javascript.

100 client al secondo sono una cifra alta, e anche se alcuni client Javascript alcuni sembrano abbastanza veloci, ci sono anche clienti che non lo sono (ad es. persone con vecchi smartphone - il mio smartphone funziona con Android 2.2 e l'interprete Javascript nel suo browser non è un campione della corsa). Per questo motivo, adesso , sembra che l'hashing della password lato client con Javascript non sia (ancora) un'idea vincente. Questo potrebbe cambiare in futuro o in alcune situazioni specifiche. Ad esempio, l'hashing sul lato client ha il vantaggio di migliorare notevolmente la resistenza del server ad alcuni attacchi DoS ; se la resistenza a DoS è ritenuta più importante dell'esperienza utente di telefonia mobile, l'hashing lato client è la strada da percorrere.

Per un'introduzione generale sull'hash della password, compresi i concetti lato client vs lato server, vedi questa risposta .