hashing della password: massimizza le collisioni per l'archiviazione della cronologia delle password

Question

hashing della password: massimizza le collisioni per l'archiviazione della cronologia delle password

#1 da (2 voti)

-2

Per il login attivo di un utente, è chiaro che è meglio utilizzare l'algoritmo più lento possibile con il minor numero possibile di collisioni al fine di impedire a un utente malintenzionato di accedere come un altro utente.

Quando si tratta di archiviare la cronologia delle password, la preoccupazione principale è proteggere il testo in chiaro della vecchia password dell'utente perché potrebbero ancora utilizzarlo in altri luoghi o utilizzare una password simile a quella corrente.

Penso che un hash MD5 o CRC troncato consentirebbe al sistema di controllare la cronologia delle password, anche se con occasionali falsi positivi (l'utente può solo pensare a qualcos'altro), ma renderli impossibili * da invertire. Quando dico impossibile, voglio dire che ci sarebbe stato collisione di testi in chiaro per design e che sarebbero indiscernibili dal testo in chiaro della password originale scelta dall'utente.

Se la cronologia delle password deve essere mantenuta, è un approccio pratico?

Un utente malintenzionato può cercare tra quelle collisioni cercando la password più probabile per l'input umano, forse cercando parole di dizionario o suffissi di tipo "1234".

Con collisioni abbastanza alte, quel tipo di restringimento sarebbe impraticabile? Forse hash metà della loro password?

Troppe collisioni dalla cronologia delle password potrebbero impedire troppe nuove password?

passwords password-policy hash md5

posta Jesse Adam 02.09.2016 - 19:32

fonte

1 risposta

Leggi altre domande sui tag passwords password-policy hash md5

ETSI TVRA è uno strumento di valutazione del rischio o di modellazione delle minacce? [chiuso] Come conoscere le vulnerabilità del mio sito web? [chiuso]

score 2 · Answer 1

Penso che tu stia suggerendo il seguente design

Quando l'utente crea una password, il sistema memorizza un hash lento della password completa AND un hash veloce della prima metà della password (ad esempio, i primi quattro caratteri)
Quando l'utente cambia una password, il sistema mantiene l'hash veloce nella cronologia delle password, ma elimina l'hash lento

Nota che al punto 1 devi generare e mantenere entrambi gli hash. Non è possibile generare l'hash veloce in seguito, poiché non è garantito che la password in chiaro sia disponibile in seguito, ad es. se l'utente cambia la sua password utilizzando un flusso di lavoro "Ho dimenticato la password".

Non sono sicuro di ciò che dovrebbe portare a termine.

Immagino che cosa succederà dopo è

Hacker ottiene una sospensione del database delle password
L'hacker attacca la password corrente / attiva tramite il suo hash veloce per apprendere i primi quattro caratteri della password. L'attacco è più facile perché è un hash veloce.
Hacker utilizza i primi quattro caratteri per ridurre lo spazio del problema relativo al crack dell'hash lento
Hacker incrina l'hash lento in 1 / 10.000 del tempo normale e impara la password dell'utente

Probabilmente non è una grande idea, Jesse.

Se sei preoccupato che la cronologia delle password presenti un obiettivo attraente per un hacker, non memorizzare la cronologia delle password .

Se si sta tentando di accelerare la ricerca della cronologia delle password, hash prima la nuova password, quindi confrontarla con i vecchi hash. Questo è possibile se il sale è univoco per utente e non per password ( che è perfettamente OK ). A quel punto stai facendo solo il confronto delle stringhe, quindi la velocità dell'algoritmo di hash non è un problema.

Inoltre, non gira la tua sicurezza .