Schema di verifica della password (utilizzato ad esempio in MS Office) - più sicuro di un semplice hash?

Question

Schema di verifica della password (utilizzato ad esempio in MS Office) - più sicuro di un semplice hash?

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

2

Gli schemi di verifica della password usuali memorizzano un hash della password salata e il sale. Se l'hash è buono e computazionale costoso, è considerato sicuro.

Tuttavia una versione alternativa (utilizzata in Microsoft Office e probabilmente in altri posti) genera N byte casuali (ad esempio 16 byte) e un hash di byte M dei byte N (ad esempio 16 byte aggiuntivi), li concatena e crittografa il N concatenato + M byte utilizzando un algoritmo di crittografia e una chiave derivata dalla password.

Per verificare la password, i byte N + M vengono decodificati, i primi N byte vengono sottoposti a hashing e confrontati con i byte M decrittografati. Se corrispondono, la password è considerata verificata.

Per i miei occhi inesperti, l'introduzione di dati casuali (di lunghezza sufficiente) rende questo sistema sicuro contro qualsiasi schema di ricerca tabella anche se l'hash è debole. Sembra solo dipendere dalla forza della crittografia e dalla lunghezza della chiave.

Mi sbaglio? Dove?

authentication storage passwords

posta Moose 23.09.2014 - 17:33

fonte

2 risposte

Leggi altre domande sui tag authentication storage passwords

hash troncato per l'autenticazione dei messaggi? Script XSS riflesso che passa attraverso l'URL come farlo funzionare e quali sono i presupposti per il suo funzionamento?

score 3 · Answer 1

Questo schema è ok , ma in pratica è solo una variante di un hash salato. Queste sono generalmente considerate vecchie pratiche. Inoltre, questo schema è più complicato (più superficie per potenziali bug) e si basa su più algoritmi di crittografia non interrotti.

La buona pratica moderna è che le password dovrebbero essere archiviate usando un algoritmo di derivazione a chiave lenta come PBKDF2 o bcrypt. Questi assicurano che le tabelle di ricerca siano irrealizzabili, e che crackare tutte tranne le password più deboli e comuni è estremamente costoso.

I hanno scritto una risposta qualche tempo fa spiegando un po 'della storia della password hashing e perché ora usiamo KDF lenti.

score 0 · Answer 2

L'attaccante non forza bruta l'intero spazio di ricerca per rompere le password. L'autore dell'attacco inizia provando il dizionario che è la raccolta delle password più probabili.

Consideriamo 3 attacchi, in base alla strategia utilizzata per proteggere il database delle password.

caso 1: password protette con hash .
Per ogni parola "w" nel dizionario
io. Calcola l'hash di "w".
ii. Confronta l'hash con le voci nel database delle password.
In questo caso è possibile utilizzare lo stesso dizionario per interrompere l'intero database delle password.

caso 2: password protette con hash salato .
Per ogni parola "w" nel dizionario
io. Aggiungi il sale 's' a 'w'.
ii. Calcola l'hash di 'w' + 's'.
iii. Confronta l'hash con la password da spezzare.
In questo caso, l'utente malintenzionato deve modificare il suo dizionario in base al sale utilizzato per l'hashing della password. Pertanto lo stesso dizionario non può essere utilizzato per rompere le password. Il sale non è noto in anticipo e se la dimensione del sale è di 32 bit, è anche possibile prevenire il precalcolo del dizionario.

caso 3: password protette con lo schema Microsoft .
Per ogni parola "w" nel dizionario
io. Decifra i byte 'N + M' usando 'w'.
ii. Hash N byte.
iii. Confronta l'hash con i byte "M".
In questo caso il valore di N non è noto all'avanzato e l'attaccante può calcolare la versione crittografata di "N" + "M" usando ogni parola nel dizionario e per ogni possibilità di "N". Tuttavia, se la dimensione di "N" è ampia, è possibile prevenire il precalcolo del dizionario.

Analogamente, la 'N' casuale nel Microsoft Scheme ha lo stesso scopo di quella del salt casuale 'nell'hash salato. Tuttavia, se viene utilizzato lo stesso valore di' N ' per proteggere ogni password nel database, la sua sicurezza è equivalente alle password protette con hash (caso 1).