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

Question

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

#1 da (37 voti)
#2 da (14 voti)

62

È buona norma non limitare inutilmente la lunghezza della password, in modo che possano essere utilizzate passphrase di lunghezza appropriata (forse 35-45 caratteri per 6/7 dicewords). (Vedi ad esempio Dovrei avere una lunghezza massima della password? dove è suggerito un massimo di 1K, per proteggere contro la DoS senza limitare la possibilità per gli utenti di impostare password lunghe.)

bcrypt è anche comunemente raccomandato (vedi ad esempio Do alcuni esperti di sicurezza consigliano bcrypt per l'archiviazione delle password? , link )

Si raccomanda anche di usare un salt (random e memorizzato con l'hash della password) - credo che spesso siano raccomandati 32 bit (4 caratteri). (Capisco che la logica della dimensione del sale sia "abbastanza che il numero di combinazioni sia molto più grande del numero di record utente E sia sufficiente a rendere le tabelle dell'arcobaleno infettibilmente grandi" - 16 bit sono sufficienti per la seconda parte ma potrebbero non essere abbastanza per il primo.)

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

Suppongo 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 sicuramente abbastanza)?

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

Lo scrypt o il PBKDF2 hanno restrizioni di lunghezza simili?

(L'ultima domanda è solo per interesse, davvero - mi rendo conto che la resistenza spazio-durezza / 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 usare.)

cryptography passwords hash passphrase

posta Misha 26.08.2011 - 00:35

fonte

2 risposte

14

Bcrypt utilizza una password di 128 bit bit e una password di 55 caratteri (massima). Non è necessario aggiungere altri valori di sale; bcrypt lo gestisce.

I progettisti di bcrypt ritenevano 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 è superiore a 55 caratteri, i progettisti ritengono che tu stia già fornendo più di 128 bit di entropia, quindi questo non è un problema. Al contrario, le linee guida del NIST conterebbero questo come solo 77 bit di entropia. Le linee guida del NIST si basano sul fatto che le frasi di passaggio hanno meno entropia per carattere rispetto alle password casuali e presuppongono che gli utenti utilizzino frasi di passaggio per password più lunghe. Per assicurarti di ottenere una piena entropia di 128 bit, puoi consentire password più lunghe e cancellarle usando SHA-256 o SHA-384 per comprimerle a una lunghezza accettabile. Potresti anche solo semplificare le cose usando scrypt o PBKDF2 che non hanno limitazioni di lunghezza. Scrypt è progettato per essere "hard disk" oltre ad essere molto dispendioso dal punto di vista computazionale; questa sarebbe la mia scelta di algoritmi.

risposta data 28.06.2012 - 08:17

fonte

Leggi altre domande sui tag cryptography passwords hash passphrase

Quanto è importante l'ora locale per la sicurezza? Servizio Web HTTPS passato a HTTP. Cosa può andare storto?

score 37 · Accepted Answer

L'uso di una funzione di hash sicura per il preprocesso della password è sicuro; può essere mostrato 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 c'è bisogno di giocherellare con il sale a quel livello; basta cancellare la password, quindi utilizzare bcrypt sul risultato (con il sale, come richiesto da bcrypt). SHA-256 è considerato una funzione di hash sicura.

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