Quando e dove ho cancellato una password?

Pensa allo scopo dell'hashing.

Se qualcuno irrompe nel tuo database non troverà password ma solo hash che devono essere forzati alle password per essere utili.

Consentendo al client di inviare un hash anziché la password, l'hash diventa effettivamente la nuova password e tutti i benefici vanno persi. Ad esempio, se qualcuno entra nel database può accedere immediatamente a tutti gli account con i dati che trovano lì.

Pertanto il client deve sempre inviare la password e il server deve eseguire l'hashing.

Idealmente , dovremmo fare la maggior parte (ma non tutti!) dell'hashing sul lato client.

Il bisogno generale di hashing della password, con tutte le iterazioni e i sali coinvolti (vedi questa risposta ), è quello di assicurarsi che il valore archiviato (il" token di verifica password ") non possa essere facilmente utilizzato per un attacco di dizionario offline (l'utente malintenzionato tenta la password potenziale, fino a uno che corrisponde al il valore memorizzato è stato trovato). Affinché quella funzionalità specifica sia soddisfatta, è sufficiente che l'hashing della password lenta e salata si verifichi "da qualche parte" e che la macchina client sia un posto ragionevole.

Tuttavia, la protezione dagli attacchi di dizionario offline è solo una parte dell'obiettivo di sicurezza. In particolare, non vogliamo che un utente malintenzionato sia in grado di ottenere valori "equivalenti alla password". Se esegui l'hashing completo lato client, e memorizzi il valore "così com'è" sul server, allora un'anteprima sul database del server (come accade troppo spesso con iniezioni SQL e nastri di backup persi) rivelerà i valori hash e consentirà l'attaccante per accedere immediatamente come qualsiasi utente. Pertanto, vuoi comunque eseguire alcuni hashing lato server.

Ciò che funziona, ad esempio, è avere l'hash lento e salato sul client, risultante in un valore V e il server memorizza SHA-256 ( V ). Dato che l'hash lento e salato è stato fatto, la protezione contro gli attacchi di dizionario è lì; e poiché il server non memorizza V ma richiede ancora al client di inviare V per ottenere l'accesso, le violazioni di sola lettura non vengono ridimensionate banalmente in un compromesso completo in lettura-scrittura.

L'hashing lato client ha la caratteristica molto interessante dell'utilizzo delle risorse lato client, non lato server, consentendo così a un determinato server di elaborare molti client concorrenti senza esaurire la CPU, pur avendo ancora un hashing di password lento e salato complessivo. Tuttavia, questo non è spesso fatto in pratica a causa di alcuni inconvenienti:

• Il client non può eseguire l'hash senza conoscere il sale, che è memorizzato sul server. Il protocollo implica quindi un ulteriore viaggio di andata e ritorno: il client deve inviare il nome utente, il server risponde con il sale, e quindi (solo allora) il client può eseguire l'hash lento e salato.

• I client sono eterogenei: alcuni possono essere piuttosto deboli, il che implica un limite rigido al numero di iterazioni che possono essere applicate (perché uno smartphone lento come client non significa che l'utente umano è più paziente). Questo è particolarmente vero per i client basati sul Web, perché i calcoli Javascript sono terribilmente lenti (se confrontati con il codice nativo o persino con le applet Java o Silverlight).

• Hash lato client indica codice lato client, che potrebbe non essere facilmente aggiornato o modificato. Con l'hashing sul lato server, la scelta della funzione hash dipende interamente dal server e può essere cambiata senza dover modificare in alcun modo i client installati.

• Alcuni server preferiscono avere accesso a password non crittografate di tanto in tanto, non per l'archiviazione, ma per altre funzionalità come la rilevazione automatica di password utente molto povere o l'invio di una copia delle password alle autorità competenti (ove applicabile) - Non sto dicendo che questo è buono o cattivo , ma quando si applica, non è soggetto alla scelta di chi progetta il sistema di accesso; un paese in cui deve consentire alle agenzie governative di dare un'occhiata alle password, quindi, beh, è necessario, quindi diventa un elemento del contesto da trattare).

Le password devono essere sottoposte a hash almeno una volta sul server, per prevenire attacchi in stile pass-the-hash in cui un utente malintenzionato può semplicemente iniettare l'hash da lui annusato dalla rete per l'autenticazione. Ciò tuttavia non significa che non si dovrebbe anche effettuare l'hash della password localmente. Una strategia abbastanza paranoica consiste nel fare in modo che l'utente invii un hash iterato di una password, utilizzando un numero elevato di iterazioni, ad esempio 10.000, che vengono quindi archiviate.

Quando l'utente vuole autenticarsi, inserisce la stessa password, ma ha solo hash 9999 volte. Quindi il server esegue l'hashing locale della password hash 9999 volte e, se corrisponde alla password hash 10.000 volte memorizzata, il server sostituisce l'hash memorizzato con l'hash iterato 9999 volte. Ad ogni tentativo successivo l'utente itera l'hash un numero di volte inferiore e, se autenticato correttamente, il server sostituisce il vecchio hash con il nuovo hash.

L'utente è costretto a reimpostare la sua password quando il numero di iterazioni diventa basso. Varie tattiche possono essere utilizzate per incorporare sali in vari punti per aggiungere ulteriore sicurezza. Il server deve anche contenere il numero di iterazioni che si aspetta che il client abbia inviato in modo che il client (o più client) possa essere tenuto sincronizzato.

In sintesi, hash sempre la password sul server, ma ciò non impedisce anche l'hashing localmente, il che può anche impedire al server di conoscere la password dell'utente, anche se brevemente.

Should the client's computer perform the hashing function and send the hashed result to my server (hoping that nobody figures out a working hash to send)?

Se usi firefox, consiglio vivamente di scaricare un piccolo strumento semplice chiamato "TamperData". Accendilo e vedi quali tipi di devastazione puoi giocare se ti siedi tra il client e il server.

Quindi la risposta a questa domanda è: NO. Il modo migliore per gestirlo è archiviare un hash salato sul database e l'applicazione server considera tutti i dati in arrivo come dannosi. Nel tuo caso, come implementeresti l'hash del client? In Javascript? Per verificare l'hash, il codice del server e del client deve essere in lock-step e poiché l'autore dell'attacco ha pieno accesso al tuo algoritmo di hashing Javascript ... hai reso pubbliche molte informazioni sull'implementazione, come ad esempio quale hash stai usando, dovresti dare via anche il tuo sale - troppo per fidarti troppo del caso. È meglio che le tue pagine siano semplici e stupide e lasci la convalida per l'applicazione server. L'usabilità potrebbe richiedere alcune convalide sul lato client, fai solo attenzione perché, ancora una volta, stai dando via i dettagli dell'implementazione ai tuoi possibili aggressori.

In breve:

1. Assumi che tutta la fonte (client / server / database) sia di dominio pubblico e disponibile gratuitamente. Un punto secondario qui è anche ricordare che l'inclusione di librerie Javascript nelle tue pagine ti apre per attaccare. Meglio avere copie locali nella tua organizzazione che sono state esaminate professionalmente. Fai attenzione anche ai servizi web! Solo perché una fortuna-500 espone un webservice non significa che un utente malintenzionato non possa sfruttare il proprio input / output contro di te!

2. Trova i tuoi limiti - nelle applicazioni MVC come le applicazioni web è piuttosto facile. Tutto ciò che proviene dall'utente viene considerato ostile fino alla convalida.