Come Facebook hash le password

Questo costrutto "Onion" può essere pericoloso e dovrebbe essere fatto solo se hai abbastanza revisori, tuttavia aggiunge più proprietà favorevoli rispetto all'hash semplice:

Il primo MD5 non salato può essere eseguito da client o server di frontend. Normalizza charset e lunghezza e nasconde le password nella fase iniziale senza richiedere troppo tempo per la CPU.

Il sale viene letto dal database dell'utente in modo che non sia presente sul client, questo è stato il primo HMAC aggiunto.

Il servizio di crittografia (o HSM migliore) difende dalla forza bruta (poiché la chiave segreta non è nota). In realtà questo precede i consigli del NIST per fare esattamente questo. Questo peppering non viene spesso eseguito in quanto richiede complicate impostazioni di sistema (HSM o isolamento del processo) - qualcosa che Facebook può permettersi.

Dato che il passaggio del pepe potrebbe essere compromesso dagli addetti ai lavori, i dati vengono quindi passati a scrypt, una funzione progettata per rendere più costoso il test di forza bruta delle password.

Il passaggio finale potrebbe non essere necessario, o forse è usato per aggiungere qualche diversificazione (SHA2 invece di SHA1).

Sembra un po 'eccessivo l'olio di serpente, ma i passaggi possono essere ragionevolmente spiegati. Se lo paragoni con il (molto più debole) glibc-SHA2 Voodoo è veramente pulito.

BTW1: gli Authenticator memorabili sono generalmente una brutta cosa, tali schemi possono solo ridurre il rischio di gestirli.

BTW2: la debolezza di collisione di SHA1 non si applica ai costrutti HMAC e la dimensione dell'hash MD5 breve non danneggia molto qui (dato che le password hanno quasi sempre meno entropia). Sarebbe più rischioso per la derivazione delle chiavi, ma non è questo il compito a portata di mano.

In uno dei commenti che hai scritto:

I'm asking if something like it makes sense now in 2018. We're going to use PBKDF2 HMAC-SHA-256 with 8 bytes salt, we're discussing what hashing schema use.

La risposta è no. L'unica parte che dovrebbe essere replicata dalla soluzione FaceBook è l'utilizzo di una funzione memory-hard e il criptaggio di cryptoservice. Le parti MD5 e HMAC non aggiungono alla sicurezza. (Sono comunque abbastanza innocui.)

Non dovresti usare PBKDF2. In ordine preferisci:

1. Utilizzo di un'associazione all'implementazione ottimizzata nativa ufficiale di Argon2
   • Consulta la sezione Argon2 spec "Parametri consigliati" per come scegliere i parametri.
   • La scelta tra Argon2d, Argon2i e Argon2id potrebbe essere in discussione. L'attuale raccomandazione ufficiale è Argon2i per le persone che non sanno quale scegliere.
2. Aggiorna il tuo software in modo da poter scegliere 1
3. Protezione dei dati crittografati utilizzando una password e non è possibile utilizzare Argon2? Utilizzare un'associazione per un'implementazione di scrypt nativa ottimizzata. Imposta il parametro costo singolo abbastanza alto da utilizzare un sacco di RAM e tempo. Se sembra sicuro di ridurre il tempo scrypt corre poi riconsiderare. Ciò riduce anche il costo basato sulla RAM.
4. Protezione di alcune password, non è possibile utilizzare Argon2 e può tollerare risposte lente? Usa lo scrypt con gli stessi parametri di costo di 4. Se stai cercando di proteggere gli account di amministrazione, dai priorità alle password e alla crittografia molto forti.
5. Proteggere le password degli account di molti utenti e non è possibile utilizzare Argon2? Utilizzare una libreria che utilizza un binding per bcrypt ottimizzato nativo. Assicurati che la libreria funzioni correttamente su tutte le stranezze dell'algoritmo di bcrypt originale. (La password verrà troncata se è troppo lunga o contiene un carattere null.)
6. Utilizza un binding a PBKDF2 nativo ottimizzato. Non utilizzare una lunghezza della chiave derivata maggiore della lunghezza di output della funzione hash sottostante.
7. Non implementare la propria funzione di hashing della password. E soprattutto non eseguire quell'implementazione in un interprete in cui sarà molto più lento. Aggiornare!

Per quanto riguarda se il metodo FaceBook è sicurezza per oscurità. No. Ma le parti HMAC e probabilmente la parte MD5 sono ridondanti. La parte cryptoservice utilizza probabilmente un HSM. Questo dovrebbe consentire agli hash delle password di essere crittografati / decrittografati senza necessariamente esporre la chiave di crittografia al tipo di hacker che può rubare un hash-database. L'uso degli algoritmi di crittografia mainstream con una chiave segreta non conta come oscurità. La password deve ancora essere con hash nel caso in cui la chiave sia mai trapelata. Ecco a cosa serve scrypt, ma ora Argon2 dovrebbe essere preferito.

Modifica: guarda i commenti. Come presentato nella diapositiva, la password non viene crittografata. HMAC è a senso unico, proprio come l'hashing. L'alternativa della crittografia dopo l'hashing è utile perché consente di sostituire la chiave. Gli utenti devono inserire la propria password se si cambia la chiave con questa configurazione di FaceBook, oltre ai parametri salt o scrypt. Se si cripta l'hash, è possibile decrittografarlo e crittografarlo nuovamente senza richiedere all'utente di inserire la propria password. (Se la tua chiave è mai trapelata ... Ma non puoi rehash una password senza l'originale.)

Utilizza anche 20 byte di sale. O almeno 16.