L'associazione bcrypt-ruby potrebbe essere vulnerabile?

Question

L'associazione bcrypt-ruby potrebbe essere vulnerabile?

#1 da (6 voti)
#2 da (5 voti)

5

Durante lo sviluppo di un'applicazione Ruby on Rails utilizzando una libreria di autenticazione di uso comune chiamata devise , ho notato dal prefisso $2a$ degli hash delle password prodotte nel database dell'applicazione che sta usando una variante di bcrypt.

Ho letto su crypt e bcrypt su Wikipedia e ho notato che le varianti più recenti di bcrypt dovrebbe produrre un prefisso di $2y$ perché un'implementazione non OpenBSD da parte di qualcuno di nome Solar Designer ha avuto un "grave difetto di sicurezza" nel 2011 e quindi non è chiaro se gli hash $2a$ siano stati prodotti da una implementazione sicura.

Ho scoperto che escogitare utilizza un legame C e Java denominato bcrypt-ruby che raggruppa in effetti un Implementazione C copiata da John the Ripper che viene dichiarata scritta da un progettista solare. Ora mi chiedo se questa implementazione potrebbe essere ancora vulnerabile a questo "grave difetto di sicurezza".

Qualcuno può illuminare questo argomento?

Aggiornamento:

La cronologia delle versioni del file nella cripta Il repository del progetto John the Ripper , da cui il file sembra aver avuto origine, può aiutare a rispondere alla mia domanda.

cryptography ruby appsec known-vulnerabilities

posta aef 24.02.2012 - 16:09

fonte

2 risposte

5

Come annunciato su openwall , questo bug era correlato a caratteri non ASCII con l'8 ° bit impostato:

What's worse, in some cases (but not in all) one, two, or three characters immediately preceding the 8-bit characters were ignored by the password hash computation. Thus, many passwords containing characters with the 8th bit set are significantly easier to crack than it was previously expected.

Se leggi il README di bcrypt-ruby c'è una nota che risolve questo problema.

Note: JRuby versions of bcrypt-ruby <= 2.1.3 had a security vulnerability that was fixed in >= 2.1.4. If you used a vulnerable version to hash passwords with international characters in them, you will need to re-hash those passwords. This vulernability only affected the JRuby gem.

Questo è chiarito qui :

Versions of jBCrypt before 0.3 suffered from a bug related to character encoding that substantially reduced the entropy of hashed passwords containing non US-ASCII characters. An incorrect encoding step transparently replaced such characters by '?' prior to hashing. In the worst case of a password consisting solely of non-US-ASCII characters, this would cause its hash to be equivalent to all other such passwords of the same length.

Quindi, poiché è stato corretto nella versione jRuby della libreria, credo che sia stato corretto anche nella versione MRI.

risposta data 24.02.2012 - 17:09

fonte

Leggi altre domande sui tag cryptography ruby appsec known-vulnerabilities

quando uscire dall'input dell'utente Come si cerca una botnet in natura?

score 6 · Accepted Answer

Il codice a cui fai riferimento è stato corretto. Se controlli la fonte su Github rispetto a Differenza di pubblicazione postata da Solar Designer , è possibile notare che l'estensione del segno è stata annotata e corretta (righe da 553 a 556).

Tieni presente che anche se il prefisso $ 2a $ non è raccomandato, nessuno dei due è $ 2x $, il che indica semplicemente che viene utilizzata l'implementazione del buggy, anche se ora lo sai. Secondo la voce di Wikipedia, si desidera assicurarsi che gli hash siano preceduti da $ 2y $. Tuttavia, questa non era la correzione originale in base alla email di Solar Designer che notava il problema . Quella correzione semplicemente assicurava che per RICHIEDERE il comportamento del buggy (per compatibilità con le versioni precedenti), si usasse esplicitamente il prefisso della versione $ 2x $. L'originale $ 2a $ è stato mantenuto per produrre un comportamento NUOVO, CORRETTO (vedere la riga 609). Pertanto, il codice in ruby-bcrypt è corretto, ma non lo conosci esplicitamente secondo le raccomandazioni nell'articolo di Wikipedia.