Memoria password con hash: iterazioni vs entropy [duplicato]

Supponiamo che il tuo sistema sia completamente compromesso. Un utente malintenzionato ha tutti i tuoi peperoni, tutti i sali necessari e la conoscenza di come li stai combinando. Questa è la situazione equivalente per un utente malintenzionato che ottiene una tabella di password briptate.

A questo punto, per il tuo schema, rompere le password è veloce. SHA-512 può essere calcolato a milioni di hash al secondo. Per l'attuale consiglio generale, bcrypt, rompere le password è ancora lento. Sintonizzandolo, l'hardware standard potrebbe essere limitato a 100 secondi al secondo, con l'hardware specializzato che fornisce ancora solo 10.000 secondi al secondo.

Ora, se puoi essere assolutamente sicuro che nessuno può rubare i tuoi dati di pepe, va bene. Tuttavia, se li perdi, le tue password sono quasi istantaneamente vulnerabili: l'hashing rapido consente a un utente malintenzionato di provare facilmente le password comuni. D'altra parte, le iterazioni non hanno questo problema.

Anche le iterazioni sono facili da implementare - una, solitamente incorporata, funzione. Questo è un piccolo sforzo per gli sviluppatori, che lo rende facile da implementare correttamente. D'altra parte, lo schema richiede codice di hash in più posizioni, su server diversi. È necessario assicurarsi che gli hash intermedi non siano esposti in nessun punto. È necessario assicurarsi che il codice di ogni livello sia corretto. Potrebbe essere necessario eseguire software aggiuntivo su alcuni sistemi (i DBMS supportano nativamente il metodo di hashing?). Ci sono molte parti mobili. È molto più facile fare un errore da qualche parte.

In breve, le iterazioni mantengono la sicurezza in caso di compromesso completo e sono più facili da sviluppare. In un mondo ideale, il pepe multistrato potrebbe aiutare contro la modalità di errore in cui il database è compromesso e nessun altro sistema lo è. Sarebbe adatto per l'aggiunta a un sistema con elevati requisiti di sicurezza, oltre a utilizzare l'hashing lento (alta iterazione), ma non invece, a meno che non si abbia la certezza assoluta che i peperoni non possano mai essere compromessi.

Un codice di autenticazione dei messaggi con una chiave segreta non disponibile per l'attaccante resisterà davvero molti attacchi che l'hash della password a uso intensivo di risorse non lo farà. Non c'è dubbio là. Non hai nemmeno bisogno dell'architettura della chiave a tre livelli eccessivamente complessa; solo una chiave segreta a 128 bit sarebbe sufficiente.

(Nota a margine: evidenzio il "codice di autenticazione del messaggio" perché questo è il costrutto crittografico appropriato per la tua proposta. Il tuo "SHA512 (password + segreto)" tradisce che non sembri sapere quale costrutto è appropriato per ciò che 'ha proposto; HMAC-SHA512 (chiave, password) sarebbe la scelta migliore.)

Ma ecco l'argomento grande e difficile che la tua domanda ignora completamente: come proteggi quelle chiavi segrete? Dici questo:

Of course the implementation would need to be secure (handmade vs more standard scrypt) and the secrets must remain unknown.

... ma quei due sono precisamente dove i laici che tentano di implementare la tua proposta falliranno, ancora e ancora! Hai già una crittografia discutibile nella tua proposta (hash con chiave cancellata a mano anziché HMAC, tre livelli di computazione MAC quando ne avresti uno solo), e dici nulla su come assicurerai che le tue chiavi segrete non siano essere divulgati, che è il punto su cui si basa la sicurezza dello schema!

Moreover if a secret is revealed and must be changed, the update process would be a pain.

Questo può essere risolto con un approccio hash-encrypt, come Dropbox ha adottato (con bcrypt, comunque). L'equivalente nel tuo approccio di no-iteration sarebbe qualcosa come encrypt(key, hash(password)) , o (poco) migliore encrypt(key, hmac(salt, password)) , che ti permetterebbe di reimpostare in seguito gli hash crittografati.

I do not see such scheme rolled out on production very often though, in general the consensus is "iterations+salt or get shamed", so maybe I am missing something.

L'archiviazione insicura di chiavi segrete a lungo termine è davvero molto comune e quasi tutti coloro che suggeriscono di usare un peperone non hanno davvero pensato al problema della gestione delle chiavi. Questo è ciò che rende gli schemi senza chiavi come l'hashing delle password ad alta intensità di risorse così prezioso e una raccomandazione così strong; se possiamo evitare o ridurre la dipendenza dalle chiavi segrete, questo è generalmente un vantaggio. Fondamentalmente, la gestione delle chiavi è difficile , quindi meno chiavi di crittografia a lungo termine dobbiamo archiviare e difendere meglio e più saremo in grado di mitigare le conseguenze dei fallimenti, meglio è.

Le chiavi segrete dovrebbero quindi essere considerate solo per l'hashing della password dopo:

1. Hai adottato un hashing delle password a uso intensivo delle risorse, che funge almeno da linea di difesa per la difesa in caso di divulgazione delle chiavi.
2. Hai un sistema ben progettato e ben progettato per proteggere e gestire le chiavi segrete dei tuoi sistemi, idealmente in cui le chiavi sono memorizzate in un uno sistema di gestione delle chiavi sicuro il cui unico scopo è quello di memorizzare le chiavi segrete a lungo termine e di non inviarle mai a nessun sistema esterno. Un KMS non dovrebbe rivelare le chiavi nemmeno ai propri clienti, che invece devono ricorrere al chiedere al KMS di eseguire operazioni crittografiche per loro conto. Qualche esempio:
   • Un modulo di sicurezza hardware
   • Strumenti di gestione segreti come Amazon KMS o HashiCorp Vault 's back-end Transit .