it-swarm.dev

Password pre-hash prima di applicare bcrypt per evitare di limitare la lunghezza della password

La buona pratica non è quella di limitare inutilmente la lunghezza della password, in modo da poter utilizzare passphrase opportunamente lunghe (forse 35-45 caratteri per parole chiave 6/7). (Vedi ad esempio Devo avere una lunghezza massima della password? dove viene suggerito un massimo di 1K, per proteggere da DoS senza limitare la capacità degli utenti di impostare password lunghe.

bcrypt è anche comunemente raccomandato (vedi ad es. Alcuni esperti di sicurezza raccomandano bcrypt per l'archiviazione della password? , http://chargen.matasano.com/chargen/2007/9/7/enough- con-le-Rainbow-tavoli-what-you-need-to-know-about-s.html )

Si consiglia inoltre di utilizzare un salt (casuale e memorizzato con l'hash della password) - credo che spesso si consigliano 32 bit (4 caratteri). (Comprendo che la logica delle dimensioni del sale è "sufficiente per il numero di combinazioni è molto più grande del numero di record dell'utente ED è sufficiente per rendere le tabelle Rainbow inaccessibilmente grandi" - 16 bit sono sufficienti per la seconda parte ma potrebbero non essere abbastanza per il primo.)

Ma AIUI bcrypt ha solo 55 byte di hash - con 4 caratteri per il sale che lascia 51 per la password.

Immagino che non dovremmo semplicemente bcrypt (left (password, 51)) e ignorare gli ultimi caratteri.

Dovremmo limitare gli utenti a 50 caratteri nella loro password (abbastanza per quasi tutti, ma non decisamente abbastanza)?

Dovremmo usare invece qualcosa come bcrypt (sha256 (salt + password)) e consentire fino a 1K caratteri? O l'aggiunta del passaggio sha256 (o sha512?) Riduce in qualche modo la sicurezza complessiva?

Scrypt o PBKDF2 hanno restrizioni di lunghezza simili?

(L'ultima domanda è solo per interesse, davvero - mi rendo conto che la durezza spaziale/resistenza FPGA e la relativa novità di scrypt e la resistenza GPGPU di bcrypt rispetto a PBKDF2 sono considerazioni molto più importanti nel decidere quale hash uso.)

65
Misha

L'uso di una funzione hash sicura per preelaborare la password è sicuro; si può dimostrare che se bcrypt (SHA-256 (password)) è rotto, allora la password è stata indovinata o alcune caratteristiche di sicurezza di SHA-256 sono state dimostrate false. Non è necessario giocherellare con il sale a quel livello; basta hash la password, quindi utilizzare bcrypt sul risultato (con il sale, come mandati bcrypt). SHA-256 è considerata una funzione hash sicura.

Il punto di un salt è di essere univoco, il più unico possibile, in modo tale che nessuna password con hash usi lo stesso valore di salt. 32 bit sono un po 'bassi per quello; dovresti usare un sale più lungo. Se hai n bit di sale, allora incontrerai collisioni (due password con hash usando lo stesso sale) non appena ne avrai più di circa 2n/2 password con hash: sono circa 65000 con n = 32, un valore non troppo elevato. Faresti meglio a usare 64 bit o più di sale (usa 128 bit e puoi smettere di preoccupartene).

39
Thomas Pornin

Bcrypt utilizza un salt a 128 bit E una password (max) di 55 caratteri. Non è necessario aggiungere altri valori di sale; bcrypt lo gestisce.

I progettisti di bcrypt hanno ritenuto che il limite di 55 caratteri sulla password non fosse un problema poiché l'hash ha un output a 128 bit. Se la tua password è più grande di 55 caratteri, i progettisti hanno ipotizzato che tu stia già fornendo più di 128 bit di entropia, quindi questo non è un problema. Al contrario, le linee guida del NIST considererebbero questo come solo 77 bit di entropia. Le linee guida del NIST si basano sul fatto che le passphrase hanno meno entropia per carattere rispetto alle password casuali e sul presupposto che gli utenti useranno passphrase per password più lunghe. Per essere sicuri di ottenere 128 bit completi di entropia, è possibile consentire password più lunghe e cancellarle usando SHA-256 o SHA-384 per comprimerle a una lunghezza accettabile. Puoi anche semplificare le cose usando scrypt o PBKDF2 che non hanno limiti di lunghezza. Scrypt è progettato per essere "memoria dura" oltre a richiedere tempo in termini di calcolo; sarebbe la mia scelta di algoritmi.

14
Steven Alexander