Per le credenziali ad alta entropia, l'hashing SHA256 è abbastanza buono?

3

Diciamo che ho un database di credenziali ad alta entropia (ad esempio valori casuali a 256 bit) usati come chiavi API dai client. Mi piacerebbe averli nel mio database in modo che un compromesso del database non consenta a un utente malintenzionato di accedere alla mia API con credenziali rubate.

Ora, dato che ho garantito valori di alta entropia (nessuna "password" breve o facile da indovinare), c'è davvero un vantaggio per qualcosa come bcrypt? Potrei fare altrettanto bene con, ad esempio, SHA256 non salato?

    
posta Bosh 05.05.2016 - 05:46
fonte

2 risposte

3

Voglio fare alcuni punti oltre all'eccellente risposta di @ NeilSmithline.

Prendendo un valore casuale a 256 bit e tagliandolo con SHA-256, l'output avrà ancora (approssimativamente) 256 bit di entropia. Dico "all'incirca" perché è un problema aperto se SHA256 esegue effettivamente il mapping su ogni stringa possibile su 256 bit, ma per tutti gli scopi pratici è abbastanza vicino.

Bcrypt: il vantaggio di bcrypt è che richiede che l'attaccante esegua molti giri di hash su ogni ipotesi, rallentandoli e aumentando i costi dell'elettricità.

Forza brutale: Diciamo che un pazzo voleva provare brute-forzando le stringhe casuali 256 bit di SHA256. In media dovrebbero fare 2 supposizioni 255 . Supponendo che ogni ipotesi richieda 1 nanosecondo e consuma un valore di energia di un elettrone, ci vorrebbe 10 60 anni (che è 10 50 * ageOfUniverse) e richiederebbe un gruppo motopropulsore che consumi l'equivalente di energia di 9.000 galassie della Via Lattea . 2 256 è un numero grande.

Bottom line: Quindi sì, nessuno andrà bruto-forzando i valori casuali a 256-bit che hai eseguito attraverso SHA256 non salato, non c'è motivo di aggiungere calcoli extra sotto forma di bcrypt. Buon per te per aver pensato alla sicurezza e aver fatto delle belle domande: -)

(In realtà, il link debole è il generatore di numeri casuali, non l'hashing: se un utente malintenzionato può restringere l'elenco di possibili semi per l'RNG che ha generato quei valori casuali, potrebbe essere possibile un attacco di dizionario. caso bcrypt potrebbe aggiungere qualche rallentamento utile.)

    
risposta data 05.05.2016 - 07:56
fonte
4

Sì. Salt è usato per prevenire gli attacchi di precomputazione, ma le stringhe a 256 bit casuali sono troppo grandi per la precomputazione. Funzioni di hash lente con molte iterazioni hanno lo scopo di rallentare gli attacchi del dizionario, ma le stringhe a 256 bit casuali sono troppo grandi per un dizionario o per test esaustivi. Quindi un singolo hash SHA256 è sicuro per lunghi input casuali crittograficamente sicuri.

    
risposta data 05.05.2016 - 06:31
fonte

Leggi altre domande sui tag