Quali sono le implicazioni per la sicurezza di memorizzare più hash per password simili? [duplicare]

Se c'è qualche impatto sugli aspetti tecnici della sicurezza, sia positivi che negativi, sembra essere molto marginale. Mi qualifico "tecnico" perché gli elementi umani / psicologici giocano spesso un ruolo significativo.

L'impatto reale è solo il vero utente - la cui vita è resa marginalmente difficile e forse dai più positivi, più consapevole della sicurezza.

Dal lato server, vedo questo come un lavoro extra (sia durante lo sviluppo che le operazioni) che non offre abbastanza benefici per giustificarlo. Per difendersi da qualsiasi attacco del dizionario dell'attaccante di moderato talento, il numero di hash che devono essere memorizzati in questo modo è troppo grande per avere un senso su larga scala.

Perché? Il fattore di lavoro dell'attaccante non è cambiato molto, nonostante tu abbia eliminato "alcune" combinazioni.

OTOH, la consapevolezza degli utenti può essere gestita meglio sul lato client valutando la forza della password mentre l'utente la digita. Questo può includere sia i test entropici (lunghezza, varietà, ecc.) che test di unicità (variazione della password precedente). Non è necessario memorizzarlo sul lato server, IMHO.

Ricorda che non è necessario memorizzare le varianti.

Nel caso in cui si desideri che la nuova password corrisponda alla password precedente one , è possibile chiedere all'utente di inserire entrambi quando lo si cambia e misurare minimum modifica distanza tra la coppia.

Ovviamente, molti consiglierebbero di non fare nulla con le password ad eccezione di hashing. In tal caso, potresti semplicemente generare tutte le varianti della nuova password e confrontare gli hash con quelli di tutte le vecchie password (senza dover memorizzare tutte le vecchie varianti).

In nessun momento memorizzerai varianti di password, o dei loro hash, mentre esegui ancora controlli di similarità di base.

I'm curious what the implications of this is on security. These hashes would give more opportunity for a brute forcer, wouldn't they?

Penso di no, il sistema controllerà la password che hanno scelto. Il forzante bruto attaccherà solo quello. Le versioni alternative verranno utilizzate solo quando un utente modifica la propria password.

Anche se l'attaccante potesse condurre un attacco offline contro tutte le varianti a loro piacimento, probabilmente continuerebbe ad attaccare quello mentre non ottengono nulla forzando brutalmente contro ogni hash con ogni testo in chiaro.

They're essentially collisions. Although on the other hand, you'd expect that if someone is brute forcing, they'd probably try the varitions around a similar time, so it seems like it wouldn't necessarily save much brute forcing time.

Non sono affatto collisioni - sono quando due testi semplici hanno lo stesso hash . Ogni variante avrà un hash totalmente diverso dall'altro. Nessuno sarebbe in grado di dire che il testo in chiaro era simile in ogni caso.

I'm also unsure how much even collisions would matter if the password is secure enough. Eg, if we have 10 variations hashed, that theoretically means that it would take 10x fewer attempts to brute force the password, right?

Spiacente ma sbagliato, come detto il protocollo di autenticazione controllerà solo la password scelta dall'utente, e in secondo luogo un 10x non sarebbe il caso anche se avesse verificato tutte le varianti come non dieci volte meno tentativi.

So yeah, does hashing these variations significantly weaken security? Is it small enough that it doesn't matter (particularly compared to the benefits of avoiding similar password reuse)?

Quindi per riassumere. Se il protocollo di autenticazione verifica solo la password scelta dall'utente, quindi no. Anche se avesse verificato tutte le varianti, avrebbe comunque abbassato l'entropia solo di una quantità relativamente piccola. Gli hash non condividono nemmeno una struttura comune l'uno con l'altro, quindi anche con l'accesso agli hash non sei il più saggio.

Posso anche aggiungere che quanto sopra si basa esclusivamente sulla domanda che l'OP ha posto. Ma sappiamo che le password di hashing non sono ovviamente buone, quindi per la pienezza anche se le password fossero "hash" usando una funzione di derivazione della chiave basata su password adatta, la risposta sarebbe ancora valida.

I'm curious what the implications of this is on security. These hashes would give more opportunity for a brute forcer, wouldn't they? They're essentially collisions.

Non vedo come siano "collisioni" in alcun senso del termine.

Although on the other hand, you'd expect that if someone is brute forcing, they'd probably try the varitions around a similar time, so it seems like it wouldn't necessarily save much brute forcing time.

E questa tua osservazione, mi sembra, risponde alla domanda. Possiamo fare appello alla legge di Kerckhoff per ragionevolmente presumere che il cracker conoscerà la tua tecnica di multi-hash, quali mutazioni applichi alle password degli utenti, quali voci sono tali mutazioni per le quali è vero l'ingresso, ecc. Quindi la soluzione più semplice per il cracker è quello di ignorare tutti gli hash per le varianti mutate e concentrarsi sulle password reali.

Quindi nel peggiore dei casi, dove massimizziamo la conoscenza dell'attaccante, gli hash aggiuntivi hanno un effetto zero sulla sicurezza.

NIST ha pubblicato di recente un nuovo DRAFT delle linee guida sulle password. Il blog di Sopho fa un buon lavoro di spiegare i cambiamenti in termini chiari.

In breve, non è necessario memorizzare più HASH, perché:

• Il tuo HASH dovrebbe essere salato usando un strong algoritmo e ogni istanza di quell'HASH dovrebbe essere completamente diversa, rendendo il confronto moot.
• I consigli NIST hanno lo sviluppatore che confronta le password con un dizionario conosciuto.

Lunghezza password

Quello che sappiamo è che la lunghezza della password diventa più importante delle regole di complessità arbitraria. Il motivo è che la quantità di entropia della password non è definita dalla password di un utente, ma dal set di simboli consentito uno sviluppatore fornisce all'utente la creazione di una password.

Un set di simboli più grande aumenta il bit di entropia.

Password del dizionario

La grande mossa è mettere la sicurezza sugli sviluppatori. Ciò include la verifica della password di un utente rispetto ai set di password comuni da un dizionario. Questo fa due cose, riduce drasticamente la superficie di attacco. Gli aggressori sarebbero limitati ai dizionari più grandi (potenza di calcolo) e la bruta forzatura di oltre 8 password di caratteri non è ragionevole per la maggior parte degli aggressori.

L'annuncio a cui è possibile sviluppare in modo pragmatico set di regole di password per cercare qualsiasi password del dizionario. per esempio. Se hai una password IAmTheWalrus, la tua dizione potrebbe individuare Walrus e dire all'utente che la password contiene una parola del dizionario. Potrebbero entrare in IAmTheWa! Rus, ma una password di 12 caratteri del genere è di gran lunga migliore rispetto agli attacchi di dizionario comuni.