BCrypt + SHA256 vs PBKDF2-SHA256

4

Da questa domanda , l'OP ha postato la password inserita dall'utente, eseguendola tramite BCrypt, quindi eseguendo tale tramite SHA256 per produrre una chiave derivata da password a 256 bit. ( EDIT: Per chiarire, queste due opzioni sono considerate come produrre un singolo valore chiave, l'hash "intermedio" di BCrypt hash deve essere hash con SHA-256 e non viene usato per altri scopi) . L'alternativa ovvia è semplicemente inserire HMAC-SHA256 come PRNG per la shell dell'algoritmo PBKDF2, con un numero equivalente di round di derivazione.

La domanda è: quali sono i punti di forza e di debolezza relativi qui? Ovviamente, entrambi gli approcci, correttamente implementati e configurati, presenterebbero una prova significativa del lavoro a un utente malintenzionato. La combinazione BCrypt + SHA256 sembra un po 'più complessa, ma se hai implementazioni già pronte di questi due e dovresti implementare la tua implementazione PBKDF2 (il PBKDF2 integrato in .NET è hardcoded per usare SHA1, non SHA256), il primo l'opzione finirebbe per essere più semplice. Vedo un vantaggio per PBKDF2 quando implementato con un HMAC a 256 bit; L'attuale hash BCrypt ha solo 192 bit, quindi, e non 256 bit, è la quantità massima di entropia inerente al combo BCrypt + SHA256 invece di un vero massimo di 256 bit con PBKDF2-SHA256. BCrypt + SHA256 sarebbe comunque migliore dell'implementazione Rfc2898DeriveBytes di PBFDF2 in .NET a 160 bit, e anche 128 bit, prodotto troncando o ripiegando XOR uno degli hash di cui sopra, è abbastanza sicuro con una buona modalità AES AEAD. / p>

Opinioni?

    
posta KeithS 23.01.2013 - 05:35
fonte

2 risposte

2

Il semplice hashing del digest di BCrypt con SHA-256 espone banalmente le chiavi di crittografia se il database delle password è compromesso. L'utilizzo del PBKDF2 della password stessa per le chiavi di crittografia impedisce questo.

Naturalmente, ci sono degli svantaggi. Con lo schema descritto, il server può eseguire operazioni crittografiche con la chiave dell'utente in qualsiasi momento, il che può essere desiderabile o necessario. Quando viene utilizzato il PBKDF2 della password dell'utente, il server non può rigenerare questa chiave senza che l'utente abbia fornito la propria password.

    
risposta data 23.01.2013 - 10:18
fonte
0

Bcrypt conserva già il sale, quindi sembra che il problema che stiamo cercando di risolvere sia l'entropia limitata dal digest standard a 184 bit rispetto al 256 nella domanda.

Direi che cambiare l'implementazione per ottenere alcuni bit extra di entropia è un rischio che supera di gran lunga il potenziale guadagno:

La ricompensa è esagerata come la potenza computazionale coinvolta nella forzatura bruta di un hash bcrypt a 184 bit con un fattore di lavoro sostanziale ( 1 secondo o più ) è fondamentalmente proibitivo, anche con buoni elenchi di parole. Sicuramente 256 bit è anche fondamentalmente proibitivo, ma è alla fine di ordini di grandezza in cui non si ottiene alcuna protezione aggiuntiva e considerati i rischi che non ne vale la pena.

La cosa migliore da fare è seguire l'implementazione bcrypt di borsa e scegliere un fattore di lavoro più ampio, il più grande fattore di lavoro che la UX del tuo sistema possa tollerare. Ciò garantirà il rischio più basso con la pianificazione anticipata ed eviterà errori con il modo in cui le password sono state sottoposte a hash.

    
risposta data 08.03.2017 - 03:13
fonte

Leggi altre domande sui tag