Quali sono i pro e i contro dell'uso di sha256 per hash una password prima di passarla a bcrypt?

Question

Quali sono i pro e i contro dell'uso di sha256 per hash una password prima di passarla a bcrypt?

#1 da (2 voti)
#2 da (1 voti)
#3 da (-2 voti)

12

Recentemente mi sono reso conto del fatto che bcrypt tronca le password a 72 caratteri. In pratica, la mia intuizione è che questo non pone problemi di sicurezza importanti. Tuttavia, capisco che ciò significa che qualsiasi libreria di software che utilizza bcrypt potenzialmente soffre di un "bug" in cui due password ultra lunghe che iniziano con gli stessi 72 caratteri saranno equivalenti.

Gli autori del framework web Django hanno scritto qualcosa chiamato BCryptSHA256PasswordHasher per risolvere questo problema; ciò che fa è prima le password degli utenti hash con SHA256 prima di passarle a bcrypt.

Alcuni sviluppatori della mia squadra stavano discutendo i vantaggi di questo approccio e volevo solo raccogliere pensieri dalla comunità generale. Da un lato, non è questo in un certo senso ridurre la sicurezza riducendo lo spazio totale dei valori possibili che vengono inseriti in bcrypt? SHA256 emetterà sempre 32 byte, molto meno dei 72 (significativi) byte che avremmo altrimenti. D'altra parte, senza le password di hashing prima abbiamo essenzialmente uno spazio distribuito in modo non uniforme dove per ogni prefisso di 72 caratteri, tutte le password che iniziano con quel prefisso si scontrano.

Il mio istinto è che il problema di distribuzione oltre 72 byte non è importante e che BCryptSHA256PasswordHasher non è davvero utile. Detto questo, riconosco anche che, in generale, i framework che sono così popolari e ampiamente utilizzati come Django tendono a prendere sul serio queste cose e hanno buone ragioni dietro le loro decisioni. Quindi non ho molta fiducia nel mio intestino su questo, se questo ha senso.

Mi sbaglio? Le password di hashing con SHA256 prima che bcrypt non riduca la sicurezza, anche teoricamente? Il problema di distribuzione è più grave di quanto immaginassi? C'è qualcos'altro a cui non penso completamente?

python passwords django sha256 bcrypt

posta Dan Tao 22.06.2015 - 16:48

fonte

3 risposte

Leggi altre domande sui tag python passwords django sha256 bcrypt

Ignora il filtraggio dell'ora su Internet dell'indirizzo MAC? [chiuso] È un reindirizzamento HTTP 301 a HTTPS, non sicuro?

score 2 · Answer 1

Bcrypt come indicato nel link è limitato a 72 caratteri.

SHA256 può avere una dimensione OUTPUT di soli 32 byte, l'input del messaggio è ((2 ^ 64) -1) \ 8 o approssimativamente

2305843009213693952 Byte (supponendo che un carattere sia 8 bit)

A Bcrypt sta ricevendo una passphrase da 32 byte per crittografare, per SHA256 che potrebbe essere un flusso di dati 400 Char (password IE).

Quindi no, non stai perdendo entropia su questo, stai superando una limitazione nel design di Bcrypts (se vuoi chiamarlo una limitazione.

Il link su SHA2 che discute è dimensioni: link

score 1 · Answer 2

Secondo documentazione di Django è perché

password are truncated on the first NULL byte (if any) and only the first 72 bytes of a password are hashed... all the rest are ignored.

Riconoscono che non si tratta di un problema di sicurezza:

While not a security issue per-se, bcrypt does have one major limitation (see previous)

Inoltre, notano che la fine delle password 72C non è "importante" come il resto:

Furthermore, bytes 55-72 are not fully mixed into the resulting hash (citation needed!).

Potrei tradurlo con "la fine della password è più facile da decifrare rispetto all'inizio".

Ecco perché fanno prima un (che non è un carattere NULL, e ha meno di 72 caratteri e non ha 55-72 caratteri):

To work around both these issues, many applications first run the password through a message digest such as SHA2-256. Passlib offers the premade passlib.hash.bcrypt_sha256 - BCrypt+SHA256 to take care of this issue.

Migliora la sicurezza se hai una password lunga da gestire. Questo potrebbe ridurlo leggermente se si hanno solo password corte (A-Za-z0-9 & speciali speciali da tastiera) brevi a causa di potenziali collisioni (meh, non così importante). Quindi per una biblioteca generica ha senso l'hash. Per un sito / applicazione lambda che gestisce la password dell'utente, sembra inutile (hai più rischi se sbagli o non lo fai affatto).

score -2 · Answer 3

Penso che l'uso di hashing della password prima di inviarlo a bcrypt sia quello di superare le cattive abitudini della password. Finché stai generando password casuali, usare l'hash sarà un danno.

Diciamo che la tua password è. Così ora posso avere i miei 72 caratteri salvati in un documento e copiarlo / incollarlo, quindi aggiungere il nome del computer su cui è attivo (o qualche altro calcolo che è facile per un essere umano). Come vediamo, in pratica tutti saranno la stessa password. Mediante l'hashing è possibile prevenirlo, ma al costo dello spazio delle chiavi perché il particolare algoritmo che utilizziamo genera 32 caratteri.

Ora, supponiamo che ogni volta che imposti una password venga generato casualmente, il tutto. Una password di 72 caratteri ha (95 ⁷²) combinazioni . La tua possibilità di collisione è 1/95 ⁷².

Se modifichiamo questo valore casuale otterremo 1 di 95 valori ³² e quindi la nostra possibilità di collusione è 1/95 ³². Quindi già possiamo vedere che l'hashing ci costa un po 'di sicurezza.

C'è di più però. Se consideriamo che l'hash eseguirà sempre una stringa di 32 caratteri, anche se l'input è inferiore a 32 caratteri, allora abbiamo esattamente 95 ³² possibili password. Ma bcrypt prenderà le password in un intervallo di lunghezze (31, 55, ecc.). Così puoi contare anche quelli (95 ⁷² +95 ⁷¹ +95 ⁷⁰ +95 ⁶⁹ ... ) che si sommano rapidamente, con conseguente ulteriore disparità tra i due metodi.

Questo è il teorico, ma per quanto riguarda la pratica. Di quanti personaggi abbiamo bisogno per una sicurezza adeguata? Se ci vorrà più del tempo necessario alla morte termica dell'universo per trovare una collisione in un hash di 32 caratteri (non so che per essere un fatto, solo facendo un esempio), abbiamo spremuto tutta la sicurezza possiamo uscire da quello. Non otteniamo nient'altro che caldi sentimenti confusi rendendo più lunghe le password. Tuttavia, possiamo aggiungere sicurezza tramite hashing che aiuta a mitigare le pratiche di password errate (quando sono più lunghe di 72 caratteri).