Test di una password per somiglianza con gli hash precedenti

Question

Test di una password per somiglianza con gli hash precedenti

#1 da (2 voti)
#2 da (1 voti)
#3 da (-1 voti)

0

Questa domanda è un follow-up di un commento di Tobias Kienzler alla risposta a" Qual è lo scopo dell'impostazione "Età minima della password"? .

Considerare una politica per le password che le nuove password non possono essere identiche alla password corrente o alle cinque password dell'utente che precedono la password corrente. Né possono essere simili alla password corrente o a nessuna di queste password precedenti, dove "simile" è definito come Levenshtein distanza 2 o inferiore. (Per rispondere a questa domanda, non assumere requisiti di complessità diversi da sei o più caratteri, una lettera e una cifra.) Ciò protegge, ad esempio, da "bush41", "clinton42", "bush-43" (che deve essere fermato) ), "obama44" (che dovrebbe essere consentito) e "clinton 45" o "bush 45" (entrambi devono essere fermati).

Il normale flusso di modifica della password richiede la password corrente in modo che qualcuno non possa eseguire una modifica della password con un cookie di sessione Firesheeped. Il flusso di modifica della password alternativo invia un token di ripristino attraverso un altro canale, ad esempio e-mail, voce o testo. Nel flusso ordinario, posso verificare se la nuova password è simile alla password corrente utilizzando la funzione di distanza Levenshtein da una libreria. Ma non ho la password precedente; tutto ciò che ho sono salate di PBKDF2. Né posso verificare la somiglianza con la password corrente se l'utente ha inserito un token di reimpostazione della password anziché la password corrente.

Nel suddetto commento, Tobias Kienzler ha raccomandato di "calcolare tutte le mutazioni della nuova password entro l'inaccettabile distanza di modifica, calcolare i loro hash e confrontarli con gli hash delle password precedenti (con i rispettivi sali)." In una risposta a "Sicurezza della password" , un rispondi a" Facebook memorizza le password in testo semplice? " e una risposta a "Come può un sistema imporre un numero minimo di caratteri modificati nelle password, senza memorizzare o elaborare vecchie password in chiaro?" , apsillers, Michał Šrajer e Ori hanno suggerito qualcosa di simile.

Ma non vedo come sia trattabile sull'hardware attuale per calcolare l'insieme di tutte le stringhe con la distanza 2 di Levenshtein da una passphrase di 20 caratteri oltre e tutte le stringhe, specialmente con un hash intenzionalmente lento come PBKDF2 e un set di caratteri grandi come Unicode. Sembrerebbe richiedere intorno agli hash h ( nc ) ^s, dove h è la lunghezza della cronologia (qui 5), n è il numero di caratteri in una password (e quindi il numero di posizioni in cui può avvenire una sostituzione o un inserimento), c è il numero di caratteri nel set di caratteri (95 per ASCII stampabile o molto più grande per Unicode stampabile), e s è la distanza di modifica massima per chiamare due password "simili".

Quindi, qual è questo modo computazionalmente fattibile per testare una password per la somiglianza con le password precedenti senza memorizzare le password precedenti con crittografia reversibile? Richiederebbe l'applicazione di alcune o tutte le seguenti semplificazioni alla definizione di somiglianza e, in caso affermativo, tali semplificazioni comprometterebbero la sicurezza del sistema di password nella pratica?

Richiede che tutti i caratteri nelle password siano stampabili ASCII (spazio a ~).
Riduci la distanza di Levenshtein di una "password simile" a 1.
Confronta solo la password corrente per somiglianza e le password precedenti solo per identità.
Sacrifica volontariamente la disponibilità per proteggere la riservatezza delle password. Quando un utente richiede una modifica della password, blocca l'utente per il resto della giornata, mentre il sistema enumera tutte le possibili password simili e impedisce ad altri utenti di modificare le proprie password se vengono inserite in coda troppe ricerche di similarità.

password-management hash

posta Damian Yerrick 10.01.2015 - 23:01

fonte

3 risposte

Leggi altre domande sui tag password-management hash

crack di protezione password Office A cosa si riferisce questo certificato SSL non corrispondente?

score 2 · Answer 1

Vorrei suggerire di considerare perché le persone cambiano le password. Potrebbe essere perché l'utente ritiene che la password sia compromessa o "perché la sicurezza"; il sistema sta forzando cambiamenti regolari nella convinzione che tali cambiamenti in qualche modo migliorino la sicurezza. Direi che una password complessa deve essere cambiata solo nel caso di un compromesso. Inoltre, ci sono migliaia di password deboli con una distanza di Levenshtein > 2. Potrei alternare attraverso: loveyou1, hateit2, scroomall3, Shannon4 e dammit5 ed essere completamente dentro le regole che hai messo avanti. Tuttavia, tutti questi elementi si basano su ipotesi basate sul dizionario in pochi secondi.

Hai calcolato correttamente che non puoi fare ciò che viene proposto in un tempo ragionevole.

Se si limita lo spazio chiave ai caratteri ASCII stampabili, si viola uno dei principi di Shannon (lo spazio chiave non dovrebbe essere limitato artificialmente) e almeno potenzialmente rendere le password meno sicure. "Meno sicuro" è per lo meno per lo più teorico, perché le persone utilizzeranno almeno per lo più i caratteri sulla tastiera. Anche così, rifiutiamo questa alternativa perché riduce lo spazio della chiave.

Ridurre la distanza di Levenshtein a uno non ti aiuta veramente, come mostrano i miei esempi. Quindi lo rifiutiamo.

Respingiamo il blocco degli utenti come violazione della proprietà di disponibilità.

Si rimane confrontando la password corrente con la somiglianza e le password precedenti per l'identità, e questo è ciò che raccomando. Non puoi nemmeno farlo quando usi un token di reset, quindi devi confrontare tutti per identità, e questo è OK. Le persone non dovrebbero "cambiare" le loro password con i loro valori attuali.

Al di là di tutto questo, ti suggerirei di rivisitare il motivo per cui vuoi forzare le modifiche delle password in assenza di prove di compromesso. Principalmente riceverai loveyou1, hateit2, scroomall3, Shannon4 e dammit5, o cose molto simili.

Infine, potrebbe essere meglio utilizzare il tempo di programmazione per rifiutare le più frequenti password da 1.000 o 2.500 anziché preoccuparsi della cronologia delle password. In un'applicazione ad alta sicurezza, potresti rifiutare i primi 10.000, ma per gli utenti ordinari equivale a rifiutare tutto. Una lista di tali password è qui: link

score 1 · Answer 2

So what is this computationally feasible way to test a password for similarity to previous passwords without storing previous passwords with reversible encryption? Would it require applying any or all of the following simplifications to the definition of similarity, and if so, would those simplifications compromise the password system's security in practice?

Si dovrebbe essere cauti nel chiedere come fare qualcosa prima di chiedere se qualcosa dovrebbe essere fatto.

Tutto ciò che puoi fare per renderti computazionalmente fattibile per testare rapidamente una varietà di password candidate (nel tuo caso, password simili), dato solo il tuo database di hash delle password, ALSO rende ancora più fattibile dal punto di vista computazionale per un utente malintenzionato per testare rapidamente una varietà di password candidate (nel loro caso, alcuni dizionari cracking e alcuni set di regole) contro il tuo database delle password trapelato .

Ogni risposta che puoi trovare su questo problema è una debolezza che gli attaccanti possono usare contro di te, e anche gli attaccanti di fascia bassa stanno già guadagnando un vantaggio su di te usando le GPU per testare le password candidate molto più velocemente di quanto il tuo server possa gestire in primo luogo .

Per riassumere: il tuo problema è identico al 100% al problema di qualsiasi utente malintenzionato con facce di database con hash delle password trapelate.

score -1 · Answer 3

Personalmente, odio davvero tali requisiti e preferirei che il tempo speso per lo sviluppo per questo abbia speso misure di sicurezza davvero efficienti come l'autenticazione a due fattori o anche semplicemente usando OpenID dove tu non hai preoccuparsi delle password degli utenti e loro non devono preoccuparsi di trovare ancora un'altra password in base a requisiti più o meno ridicoli nonostante il sito a cui si accede sia di "minore importanza" per la loro privacy . In questo modo li motivate ad avere una una password molto sicura, magari anche cambiarla regolarmente "per davvero", perché ora non devono né ricordare quale permutazione della password predefinita che supera a malapena tale cambiano i requisiti che hanno usato questa volta solo per fare semplicemente clic sul pulsante "reset password" dopo il quinto frustrante messaggio "username / password non valido" ...