Che ne dici di combinare pkdf2 con lo scrypt? [duplicare]

Combinare diluisce il tuo vantaggio. Questo business dell'isolamento lento consiste nel combattere l'attaccante su basi uguali, la tua CPU contro la sua CPU; scrypt eguaglia ulteriormente le cose ottimizzando l'hashing delle password per il tipo di hardware che si utilizza (un PC) invece di lasciare che l'hacker ottimizzi le cose dalla sua parte con hardware non PC. Se spendi metà del tuo budget CPU su PBKDF2, allora la metà di quella è un po 'sprecata, poiché l'hacker può ottimizzare completamente PBKDF2 con una GPU.

Vedi questa risposta per ulteriori analisi sull'argomento.

L'articolo che citi sembra di dubbia qualità. Ad esempio, borbotta su base di presunte debolezze su 3DES - ma bcrypt non è affatto su 3DES, e non c'è nessun attacco noto di costo accademico "80 bit" su 3DES. Ti suggerisco di non fidarti troppo di quell'articolo.

Non vedo alcun punto nell'utilizzo di scypt con pkdf2. scrypt ti permette di definire la quantità di CPU e memoria necessaria per produrre un particolare hash. Per fare ciò, scrypt si comporta in modo molto simile a pbkdf2, nel senso che sta eseguendo un ciclo su una funzione hash per produrre questo output.

pkdf2 + bcrypt è un ottimo metodo di memorizzazione delle password, ma penso che scrypt migliori di così, perché puoi anche aumentare l'utilizzo della memoria!

Bene, per cominciare, ti manca un argomento per pbkdf2, cioè la lunghezza dell'output. Questo è letteralmente controllato troncando n blocchi della funzione di input dopo che è passato attraverso l'algoritmo pbkdf2

Il motivo per cui ho sollevato questa questione è che la combinazione delle due funzioni come questa potrebbe essere la tua rovina. Se, diciamo ipoteticamente, hai deciso di generare solo un byte di output da pbkdf2. Bene, ora hai 2 ^ 8 possibili input per scriverti. Anche con requisiti costosi, 256 possibili input non sono difficili da forzare. Quindi, da qualsiasi hash della password, puoi tornare allo stato post-pbkdf2.

Il fatto che la richiesta di un byte di output da pbkdf2 tronca l'hmac presenta un'interessante possibilità: non è più necessario trovare una collisione su 2 ^ 160 (per pkcs # 5 con hmac-sha1) ma solo per 2 ^ 8. In inglese, non hai bisogno di trovare la password , devi trovare la una password che funziona.

Ovviamente, questo particolare esempio si verifica solo se si decide di generare un output molto piccolo da pbkdf2, ma è un esempio di come, mentre le primitive che si usano siano ben controllate, ciò che si sta facendo con loro può essere negativo. Per ulteriori informazioni sul troncamento hash, leggere Troncare l'hash crittografico rende impossibile craccare? .

Personalmente andrei con pbkdf2 o scrypt, e non con entrambi.

Questo non offre molti vantaggi come si potrebbe pensare. Sei vulnerabile a qualsiasi tipo di attacco all'hash interiore che riduce significativamente la sua sicurezza, perché consente la manipolazione dei dati in un modo che rende l'hash interno anormale. Una soluzione migliore è xor l'output dei due hash.

h1 = M_a(m, salt1, params_a)
h2 = M_b(m, salt2, params_b)
hash = h1 ^ h2
save(username, hash, salt1, salt2, params_a, params_b)

Ciò garantisce di avere la sicurezza almeno dell'hash più strong, senza gli svantaggi associati. Tieni presente che questo è vero solo per gli hash con costruzioni completamente diverse, il che si traduce in una "prova" di sicurezza non definita (o nella sua mancanza).

In ogni caso, probabilmente non è una buona idea per combinare le funzioni, perché non c'è garanzia che interagirà nel modo in cui ti aspetti. Le funzioni crittografiche sono per lo più un castello di carte e, come ha detto Thomas Pornin in modo così eloquente, una preghiera a $DEITY . Mescolandoli insieme fa apparire sconosciute. Mentre è difficile dire che è imperfetto o più strong, in genere è il caso di sperare per il meglio.

Tuttavia , tutto presuppone che la tua premessa sia valida. Stai meglio usando scrypt, che offre la stessa forza di PBKDF2 e bcrypt combinati, con funzionalità extra progettate per rendere l'accelerazione GPU e FPGA molto inefficiente e difficile.

Per quanto riguarda PBKDF2 vs bcrypt: bcrypt è più difficile da attaccare tramite hardware dedicato, quindi dovrebbe essere significativamente più strong. È possibile che bcrypt abbia problemi, ma si basa su una funzione ben nota e non sembra avere problemi nei 13 anni in cui è stato intorno.

PBKDF2 è uno standard con più controllo, ma è anche molto più facile da attaccare tramite hardware dedicato, in modo da poter dimostrare che la sua sicurezza è conosciuta per essere infranta in modo tale che bcrypt isn ' t (ancora).

Allo stesso modo, bcrypt è molto più facile da attaccare tramite hardware dedicato piuttosto che scrypt. La differenza è che lo scrypt è stato presentato 3 anni fa, rispetto a 13 per bcrypt.

Inoltre, scrypt è apparentemente considerato uno standard IETF , quindi spero che sia Presto un esame molto più approfondito.

Per quanto riguarda la necessità di concatenare due funzioni, queste domande rispondilo meglio di quanto potrei (il secondo riguarda bcrypt + PBKDF2 ma non importa quali siano le funzioni in questione):

So you do not get something stronger that way; instead, you get a security level which is an average of what you would have got with Bcrypt alone, or with PBKDF2 alone.

Combining two hash functions or similar functions together is good to avoid a catastrophic failure, if one turns out to be broken; but, assuming that both Bcrypt and PBKDF2 are strong, and the question is mostly about performance (both bcrypt and PBKDF2 are about making exhaustive search slower, so this is all about performance). For optimal slowness, combining bcrypt and PBKDF2 is not a good idea.

Vale la pena notare che "il fallimento catastrofico" sembra piuttosto improbabile. Voglio dire - MD5 è noto per essere rotto, ma PBKDF2 usando MD5 è ancora "abbastanza buono". Certo è troppo veloce, ma puoi attivare le iterazioni. Certo, non è buono per la resistenza alle collisioni, ma è improbabile che si tratti di un problema con password di lunghezza ragionevole (meno di un centinaio di caratteri).