HMAC - Perché non HMAC per l'archiviazione delle password?

Il punto del sale è prevenire la condivisione dei costi degli attacchi: se un utente malintenzionato vuole attaccare due password, dovrebbe essere due volte più costoso dell'attacco di una password.

Con la tua proposta (la tua "domanda 1"), due utenti con la stessa password finiranno per utilizzare lo stesso MAC. Se un utente malintenzionato ha accesso in lettura al database, può "provare" le password (ricalcando il MAC) e cercare il database per una corrispondenza. Può quindi attaccare tutte le password in parallelo, al costo di attaccarne una. Se long_string è una costante hardcoded nel codice sorgente dell'applicazione, tutte le istanze installate dell'applicazione condividono questa costante e diventa utile (per l'utente malintenzionato) precomporre un grande dizionario di coppie password-to-MAC, note anche come "un tavolo arcobaleno".

Con un nonce (la tua "domanda 2") eviti la condivisione dei costi. Il nonce è generalmente noto come "sale". Il tuo long_string e l'uso di HMAC non ti compri molto qui (e non stai usando HMAC per quello per cui è stato progettato, a proposito, quindi sei su fondamenta traballanti, in termini crittografici). Usare una salina è un'ottima idea (beh, non usare una salina è una pessima idea, almeno) ma fa solo metà del lavoro. Devi anche avere una procedura di hashing slow . Il punto qui è che il sale previene la condivisione dei costi, ma non impedisce di attaccare una singola password. Attaccare una password significa provare le password possibili fino a una corrispondenza (è l'attacco del dizionario), e, data l'immaginazione dell'utente medio, gli attacchi al dizionario tendono a funzionare: le persone semplicemente amano usando password che possono essere indovinato. La soluzione alternativa consiste nell'utilizzare un processo di hashing che è intrinsecamente lento, di solito ripetendo la funzione di hash alcune migliaia di volte. L'idea è di rendere la verifica della password più costosa: avere un utente che aspetta 1 ms invece di 1μs non è un problema (l'utente non lo noterà), ma renderà anche il dizionario un attacco 1000 volte più costoso. Il tuo long_string può essere usato per quello, a condizione che sia molto lungo (non 2 kilobyte, piuttosto 20 megabyte).

È possibile utilizzare HMAC al posto di una funzione di hash raw per rafforzare un sistema di verifica della password, ma in una configurazione diversa. Dato un sistema che controlla le password con sali e funzioni hash iterate, è possibile sostituire la funzione hash con HMAC, usando una chiave segreta K . Questo impedisce attacchi di dizionario offline finché puoi mantenere K segreto. Mantenere un valore segreto non è facile, ma è ancora più semplice mantenere un K segreto a 128 bit di un database completo.

HMAC non ti compra molto qui, anche se suppongo che agisca come una funzione di hash sostituibile (sostituibile cambiando la chiave). Comunque sembra proprio eccessivo qui.

Tuttavia, il primo schema che proponi sopra fallisce in modo catastrofico se $ long_string diventa noto a un utente malintenzionato, cosa che probabilmente succederà dal momento che probabilmente il codice non è considerato segreto (ed è generalmente una cattiva pratica affidarsi alla segretezza del codice comunque ).

Dovresti utilizzare il secondo schema dato che $ nonce è necessario per proteggere dagli attacchi precomputi