Lunghezza di hash per la memorizzazione della password

Una lunghezza di uscita maggiore lo rende più strong, fino a un certo punto che è già stato raggiunto, con un ampio margine, quando si dispone di un output a 128 bit. Ingrandendolo ulteriormente non cambia la sicurezza.

Dettagli: a esclusione di qualsiasi debolezza strutturale, la sicurezza di una funzione hash dipende dalla sua resistenza agli attacchi generici (aka "fortuna": l'utente malintenzionato prova input casuali fino a quando viene trovata una corrispondenza) e tale resistenza dipende dalla dimensione dell'output dell'hash. Per una funzione di hash con un output di n bit, ci vuole sforzo 2 ⁿ perché l'attaccante possa trovare un preimage (cioè una password, non necessariamente il "vero", che corrisponde all'output). Gli sforzi al di là di 2 ⁸⁰ sono troppo lontani nel tecnologicamente non fattibile per essere immaginati da un aggressore. A 128 bit, hai già un margine 2 ⁴⁸ , vale a dire un fattore di quasi 300 migliaia di miliardi rispetto a quello che era già troppo costoso. Sarebbe come vantarsi di rimborsare il debito nazionale USA senza avere più di 0,01 $ in contanti.

Le dimensioni di output più grandi aiutano anche contro le collisioni; ancora una volta, gli attacchi generici basati sulla fortuna sono costati 2 ^{n / 2} (e qui si vede perché SHA-1 ha un output a 160 bit: per rendere il costo della collisione di 2 ⁸⁰ non raggiungibile). Tuttavia, le collisioni non rappresentano un problema per l'hashing della password. La capacità di calcolare le collisioni non dà alcun vantaggio all'attaccante. Accade così che le collisioni siano anche non fattibili con le solite funzioni di hash, ma se fossero fattibili non sarebbe un grosso problema.

La vera debolezza nell'hash della password non è l'hashing ; è la password . O, più precisamente, la mente umana dietro la password. Gli attacchi riusciti alla password hash sono attacchi che tentano potenziali password, non attacchi che funzionano sulla funzione hash debolezza strutturale, se presente. Le attenuazioni comprendono l'hashing e la salatura lente, che è ciò che fa PBKDF2.

È possibile memorizzare solo 80 bit circa di output PBKDF2 (e il sale); le cose saranno comunque al sicuro. (Per ragioni puramente estetiche, crea 128 bit: queste persone informatiche amano semplicemente i poteri di due.)

Sì, un hash a 512 bit è eccessivo. 128 bit è abbondante.

Ricorda che la sicurezza del tuo sistema è strong quanto il link più debole. L'anello più debole, in questo caso, è quasi certamente l'entropia della password dell'utente. La maggior parte degli utenti sceglie password scadenti che sono facilmente indovinabile . Aumentare la lunghezza dell'hash non fa nulla per fermare questo attacco.

Per questo motivo, la cosa più importante è utilizzare uno schema di hashing delle password progettato per rallentare gli attacchi di indovinamento sulle password degli utenti, come ad esempio bcrypt , PBKDF2 o scrypt. Scegli un numero di iterazioni che rende l'hashing della password lento come puoi tollerare . Assicurati di usare anche un sale casuale. Assicurati di utilizzare SSL per proteggere la trasmissione delle password dall'utente al tuo sito ; Ti consiglio di utilizzare SSL in tutto il sito . Altrove ho offerto altri suggerimenti su come migliorare la sicurezza dell'autenticazione basata su password .

Ci sono molte informazioni aggiuntive su questo sito sulla protezione dell'archiviazione delle password. Prova la barra di ricerca: dovresti trovare tutti i tipi di buoni consigli e consigli utili.

Sebbene la sicurezza di due schemi di hashing sia funzionalmente equivalente, supera i 100 ~ bit a meno che non ci sia un grosso difetto - non direi che un hash a 512 bit è eccessivo . La lunghezza di un hash purché sia superiore a 128 bit è in gran parte irrilevante.

Avete abbastanza password nel vostro database che memorizzano un extra (512 bit = 64 byte, 128 bit = 16 byte) 48 byte per utente è significativo?

Dannazione, molti sistemi memorizzeranno gli hash come stringhe esadecimali ASCII (ciò significa che ogni byte prende due caratteri ASCII tra 0-9a-f per memorizzare), che quindi puoi spesso ottimizzare la dimensione degli hash andando a un blob binario se vuoi. Tuttavia, raramente non ti importa di salvare dozzine di byte su un sistema moderno. Se si dispone di un milione di utenti è ancora solo un ulteriore 48 MB, che è ancora banale da lanciare hardware. E raccomandiamo l'uso di hash lenti (ad es., Bcrypt / scrypt), i problemi di rendimento del recupero / confronto dell'hash sono irrilevanti (in effetti gli hash più grandi sono leggermente migliori in quanto saranno leggermente più lenti).

Uso la cripta SHA-512 sui miei sistemi Linux. (Questo non è un semplice hash sha-512, ma essenzialmente di 5000 round (predefiniti) di SHA- 512 .) Non lo uso perché ho bisogno di più della cripta SHA-256, ma era il default con la mia distro (e gli extra 43 byte per utente sono completamente irrilevanti (è in una codifica base64) )). Ha il piccolo vantaggio aggiunto se un attacco futuro su SHA viene mai trovato che riduce significativamente la sua complessità, ho iniziato da una posizione di partenza molto più sicura. Ad esempio, se trovi un attacco pre-immagine che lo rende più semplice di un fattore 2 ⁶⁴ , gli hash a 128 bit sono compromessi mentre gli hash 256/512 bit andrebbero bene).