È sicuro memorizzare una cronologia hash della password per impedire all'utente di mantenere ripetutamente la stessa password in alcuni casi?

Sicurezza della memorizzazione della cronologia hasc

Is it safe to keep the history of hashes?

Relativamente. Posso immaginare alcuni scenari in cui ciò danneggerebbe la sicurezza dell'utente, ad esempio:

• Un utente utilizza una password relativamente debole, lo realizza e aggiorna la password a una password migliore, basata sulla password precedente (semplice esempio: superawesome - > !sup3eraw3s0m3! ), ciò potrebbe portare a un utente malintenzionato per rompere più facilmente la password ora più sicura (prima cracciono la password facile, la hanno nella loro lista di parole ora, e poi applicano le regole di base come e-> 3, ecc.)
• In precedenza utilizzavano una password sul tuo sito web che utilizzava anche in molti altri siti web, interrompeva la fiducia nel tuo sito web e modificava quindi la password sul tuo sito web. Un utente malintenzionato potrebbe ottenere il tuo database, crackare la vecchia password (che pensavano sarebbe stata eliminata dal tuo database) e quindi provare le credenziali di accesso su un altro sito web.
• Dopo un po ', hai un sacco di cronologia su un utente che cambia spesso le password. Un crack di hacker indica il 30% degli hash della cronologia e ora ha una buona idea di come quell'utente specifico crei le password. Se l'utente non crea password veramente casuali, sarà molto più semplice interrompere la password corrente.

Quindi non ti consiglio di mantenere una cronologia hash della password.

Alternativa

How can I stop him to keep the same password from the previous history?

Non tenere una cronologia. Quando un utente cambia la sua password, hai ancora l'hash della password originale nel database. Puoi confrontarlo con quello per evitare duplicati esatti.

Ma usando bcrypt, questo succede:

According to my observation, if a user changes his password and keeps the same as a previous one, the hash values become different

Succede perché bcrypt gestisce automaticamente i sali per te. Quindi, quando hai cancellato una nuova password, questa viene sottoposta a un hash diverso e quindi l'hash è diverso. Puoi recuperare old salt e poi passarlo su password_hash come argomento per ottenere lo stesso hash.

Migliore alternativa

Potresti anche richiedere all'utente di inviare la vecchia password quando si cambiano le password (che aumenta anche la sicurezza [*]), e quindi puoi anche controllare se la nuova password è simile alla vecchia password (ad esempio usando distanza di hamming o simile).

Entrambe le mie alternative non impediscono però i cambiamenti ciclici (ad esempio super-secure-password - > another-awesome-credential - > super-secure-password ), ma non sono sicuro che sarei davvero preoccupato per questo.

_{[*] chi esegue il dirottamento di una sessione non può modificare la password e la password non può essere modificata da CSRF (anche se esiste una vulnerabilità XSS).}

In realtà, i commenti su come Google gestisce le vecchie password (riconoscendole ancora per recuperare un account bloccato), mi hanno fatto pensare ai pro e ai contro di questo, e se potevi usarlo per evitare che le persone riutilizzassero vecchie password in modo relativamente sicuro. Non che io pensi davvero che lo vorrai (personalmente penso che il 99% delle "best practice applicate" per l'uso delle password porti solo a scrivere la loro password, questo è vero a meno che la persona coinvolta non riconosca davvero l'importanza della password ( ad esempio consente il funzionamento di una centrale nucleare), nel qual caso non è necessario applicare le migliori pratiche in modo tecnologico).

Per prima cosa, diamo un'occhiata a come Google ha potuto implementare il proprio sistema in modo relativamente sicuro. Dai commenti sopra capisco che quando si perde l'accesso alla propria e-mail e si dimentica la propria password corrente, viene avviata una sorta di recupero-flusso di lavoro, in cui uno fornisce "prove" della propria identità. Probabilmente a un certo punto un umano deciderà se ripristinare l'accesso a quell'account. A quel punto hanno bisogno di tante prove quante sono in grado di scoprire che sei tu! La conoscenza di una password precedente può fornire un suggerimento.

Ora i problemi di memorizzazione dei vecchi hash delle password sono menzionati da @tim nella sua risposta elaborata - anche se sospetto che Google protegga i loro database molto meglio della maggior parte degli altri, una violazione dei dati può sempre accadere. Se invece di memorizzare un hash di password completo a 128-bit / 256-bit (salato), memorizzano solo i primi 16 bit (per le vecchie password), allora sarà impossibile per un utente malintenzionato estrarre una password da questo ^* . Allo stesso tempo, se qualcuno fornisce 2 password che corrispondono a 2 dei 4 hash a 16 bit memorizzati, questo è un grande suggerimento che la persona non è un hacker completamente casuale ^** .

Dì che il tuo requisito è di non consentire alcuna password mai utilizzata prima sul sistema per quell'utente (ad esempio, il tuo capo ha letto da qualche parte che è una buona idea e non permetterà a nessuno di cambiare idea). Ancora una volta sono pienamente d'accordo con la valutazione di @ Tim che la memorizzazione degli hash per le vecchie password è una pessima idea. Quindi, cosa succede se usiamo la soluzione Google suggerita e archiviamo solo un piccolo hash per una password? Il problema è che se usiamo gli hash a 16 bit, abbiamo un ragionevole cambiamento nel disabilitare una password che non era stata usata in precedenza, ma che ha lo stesso hash a 16 bit. L'attacco compleanno mostra che per 16 bit, dopo 36 password, c'è una probabilità dell'1% che venga respinta almeno una nuova password --- questo può o non può essere accettabile. Più bit significa che questa possibilità si riduce, ma le informazioni esposte da un database compromesso diventano più grandi.

^* Se le tue vecchie password sono "monkey1", "monkey2", "monkey3", un hacker potrebbe ancora essere in grado di captare questo schema. D'altra parte, dal momento che Google non richiede modifiche alle password mensili, mi aspetto che le persone che utilizzano modelli semplici non si preoccupino affatto di cambiare la propria password di google.

^** Ancora una volta voglio chiarire che non è nient'altro che un suggerimento! L'intera idea delle vecchie password è che sono state modificate perché potrebbero essere state compromesse. Quindi la conoscenza di una vecchia password non è nemmeno un suggerimento; probabilmente vorranno che scannerizzi la tua carta d'identità o qualcosa del genere prima di ripristinare l'accesso. Tuttavia, aggiunge un primo livello di protezione contro un ragazzino di 16 anni che tenta di hackerare l'account di un insegnante o uno script di computer che tenta di hackerare molti account contemporaneamente. 16 bit significano che solo 1 tentativo di password casuale 64k passa.

La maggior parte dei commenti qui è abbastanza buona e identifica i problemi chiave. Tuttavia, uno punto che deve essere considerato è che è necessario valutare questi tipi di domande nel contesto e sii molto attento alle generalizzazioni che lo affermano è buono o cattivo.

Le domande sulla cronologia delle password sono correlate al concetto di invecchiamento della password e richiedere agli utenti di cambiare regolarmente la propria password. Un tempo, è stato riconosciuto best practice per invecchiare le password e mantenere una cronologia per garantire che gli utenti non abbiano riutilizzato a password precedente Questo era, nella maggior parte dei casi, appropriato per i tempi e gli ambienti più in voga in quel momento. Tuttavia, le cose sono cambiate e per molti, essere costretti a cambiare regolarmente la password e il riutilizzo della password è di piccolo vantaggio e forse anche dannoso.

Ci sono state alcune ricerche che presentano la premessa che l'invecchiamento delle password e la cronologia delle password potrebbe effettivamente ridurre la sicurezza anziché aumentarla. La base ipotesi e idee sono

• La maggior parte delle persone ha solo un numero stabilito di password valide che sono in grado di ricordare
• Quando è costretto a cambiare regolarmente la password e viene impedito il riciclo password, usano / patterns / per aiutare a rendere il requisito gestibile
• Se sei in grado di ottenere abbastanza informazioni sulla cronologia delle password, identificandole i modelli possono diventare possibili. Questo potrebbe non solo rendere lo spazio di ricerca per indovinare una password più piccola, potrebbe addirittura consentire la previsione delle password future.

Quindi, questo significa che l'invecchiamento della password e la cronologia sono una cattiva idea? Possibilmente e possibilmente non. Dipende dall'ambiente.

Nella mia vita privata, uso un gran numero di servizi web. Cerco di adottare bene pratiche di password - Io uso password diverse su siti diversi, io uso strong password e utilizzo la verifica a due fattori, ove possibile. Non comunico password su canali non sicuri ecc. In questo ambiente, essere costretti a cambiare il mio è improbabile che la password impedisca di riutilizzare una password sicurezza. Se il fornitore di servizi non protegge queste informazioni in modo appropriato, potrebbe persino ridurre la mia sicurezza, dato che gli aggressori potrebbero essere in grado di indovinare il mio intelligente password 'pattern'.

D'altra parte, ho lavorato contemporaneamente in un ambiente in cui molti membri dello staff viaggiava molto e spesso utilizzava reti sconosciute e forse insicure. In questo situazione, c'era un rischio molto più alto che una password è stata compromessa. Per questo scenario, che richiede agli utenti di cambiare regolarmente le loro password, può essere giustificato in quanto ridurrà la superficie di attacco, cioè la quantità di tempo in cui un compromesso la password può essere utilizzata da terze parti non autorizzate. L'applicazione della cronologia delle password lo farà assicurarsi che l'utente non ricicla una password che potrebbe essere già stata compromessa. (in realtà, probabilmente molto più beneficio sarebbe ottenuto attraverso l'utente educare e insegnare alle persone come riconoscere reti potenzialmente pericolose e permettendo loro di cambiare la loro password quando possono valutare con precisione i rischi piuttosto che forzare una taglia unica si adatta a tutti i tipi di soluzione, ma l'educazione e la consapevolezza dell'utente sono a molto difficile da rompere!).

La misura in cui la cronologia delle password può essere un problema di sicurezza dipende in realtà da come bene, la storia è assicurata. Il pericolo è che la gente possa pensarlo perché è così solo una cronologia delle passate password, non richiede lo stesso livello di protezione che i dati della password effettivi richiedono. Questo di solito sarebbe un errore. La password la cronologia deve essere trattata con lo stesso livello di protezione della password corrente dati. Se questo è fatto in modo efficace, allora probabilmente non è più un rischio di vero e proprio hash della password e, naturalmente, se i dati attuali della password non lo sono adeguatamente protetto, quindi le preoccupazioni sulla cronologia delle password sono probabilmente irrilevanti.

Le password devono essere sottoposte a hash utilizzando un algoritmo di stretching approvato, come PBDKF2 o bcrypt. Inoltre, dovrebbero essere combinati con un sale unico che viene poi salvato con l'hash. Poiché il sale è unico, gli attacchi possono avvenire solo contro l'hash e il suo sale.

Poiché la funzione di hashing è computazionalmente proibitiva (se implementata correttamente), non si osservano ulteriori danni mantenendo gli hash e i sali precedenti delle password precedenti.

Poiché è necessario conservare una cronologia per assicurare le best practice per la password, l'unica soluzione appropriata è di salvare l'hash ed è salt, ruotandoli mentre l'utente aggiorna le proprie password.