Gold Standard per l'hashing della password

Mi piacerebbe avere il% co_de in-built, con un numero elevato di iterazioni: più alto è il numero, meglio è, ma raccomanderei 5000 come minimo assoluto. SHA1 è considerato non funzionante per alcuni usi, ma non nel modo in cui è utilizzato in PBKDF2 e probabilmente non sarà mai nella vita del prodotto.

L'implementazione del proprio PBKDF2 con SHA512 non dovrebbe essere difficile. Infatti, Microsoft fornisce un'implementazione di riferimento che utilizza SHA256.

Bcrypt è marginalmente "migliore "rispetto a PBKDF2 . Tuttavia, PBKDF2 è già abbastanza buono: usato correttamente, cessa di essere il punto più debole del tuo sistema.

Ricorda che il punto delle iterazioni in PBKDF2 è di rendere l'hashing della password lento per l'attaccante. Sfortunatamente, lo rende lento anche per te. Devi quindi evitare di renderlo indebitamente lento per te. In particolare, considera SHA-512: SHA-512 utilizza molte operazioni aritmetiche a 64 bit. L'hacker può acquistare PC che funziona bene con le operazioni a 64 bit (la CPU x86 recente ha una modalità a 64 bit, mentre i processori più vecchi potrebbero utilizzare gli opcode SSE2). Il tuo server, d'altra parte, potrebbe essere un po 'più limitato: se il tuo server funziona in modalità a 32-bit, allora SHA-512 sarà abbastanza lento per te (perché usi .NET e in .NET non giochi con SSE2 opcodes), dando all'aggressore un vantaggio di calcolo (di un fattore di circa 6).

Utilizzando l'implementazione PBKDF2 fornita dal sistema si massimizzano le probabilità che non si verifichi un tale rallentamento artificiale (in particolare potrebbe utilizzare un'implementazione del codice nativo di SHA-1). Le carenze note di SHA-1 non influiscono sulla sua sicurezza se utilizzate in PBKDF2.

Se fai qualcosa "da solo", allora devi capire questi problemi di prestazioni con tutti i loro dettagli; e, se qualcosa va storto, probabilmente avrai la colpa.

Personalmente, vorrei andare avanti e usare BCrypt. L'algoritmo potrebbe non essere elencato in NIST, ma è stato utilizzato abbastanza a lungo (13 anni fa, e il codice Blowfish stesso a circa 20) di cui mi fiderei. In confronto, MD5 si è dimostrato vulnerabile a soli 5 anni dalla sua introduzione ed è stato considerato completamente rotto in 18 anni.

L'unico attacco noto al codice Blowfish nei suoi 20 anni è un attacco di testo in chiaro noto, che richiede un numero esponenziale di messaggi di input noti e codici cifrati risultanti (2 ^ 8n + 1 dove n è il numero di round della cifra Feistel per Blowfish a 16 round standard che è 2 ^ 129) per ricavare la chiave. Per BCrypt, questo stesso attacco è irrealizzabile; primo, c'è sempre un solo testo che è "valido" per BCrypt (la stringa ASCII "OrpheanBeholderScryDoubt"), e in secondo luogo, la chiave che sarebbe decodificata inserendo altri testi in chiaro è il risultato della funzione di derivazione della chiave esponenzialmente complessa che offusca la password in primo luogo. C'è stata una vulnerabilità mostrata in un'implementazione C di esso per i sistemi Unix, che ha rotto l'algoritmo se fosse stata alimentata una password contenente caratteri ASCII non di base; di conseguenza, i nuovi algoritmi che non hanno la vulnerabilità dovrebbero essere preceduti dalla variante BCrypt "$ 2y $" (sebbene la maggior parte usi ancora il vecchio "$ 2a $" che è ambiguo, l'algoritmo che ha generato l'hash potrebbe essere sicuro, ma forse no).

Ora, anche se preferisco BCrypt, PBKDF2 non è un problema. Sebbene SHA-1 sia considerato vulnerabile a causa della sua costante, relativamente bassa complessità, il costo stimato per rompere un singolo hash affittando una CPU sufficiente da un provider cloud per eseguire quell'attacco sarebbe di circa $ 2,77 milioni. In PBKDF2, SHA-1 viene utilizzato come HMAC, ovvero l'hashing SHA-1 viene eseguito almeno due volte per l'iterazione della funzione di derivazione. Con 5.000 iterazioni e una lunghezza della chiave di 320 bit (che richiede due serie di 5.000 iterazioni, una per ciascuna metà della chiave derivata), qualsiasi vulnerabilità nello spezzare un singolo hash è compensata dal fatto che dovresti eseguire il reverse-engineer migliaia di loro (aggiungendo complessità nell'ordine di 2 ^ 14.3, rendendo l'attacco completo qualcosa come 2 ^ 175).

Moltiplicando il costo di $ 2,7 milioni per craccare un hash SHA con l'aumento della complessità si ottiene ... un prezzo di circa $ 55,4 miliardi per rompere un hash PBKDF2 "lungo" (non conoscendo la password di input). Chiunque abbia questo tipo di graffio, e vuole il tuo segreto, trova un modo più economico .

Se ti interessa la sicurezza della password di qualcuno, dovresti spostarti da PBDKF2 e meno a BCrypt. Guarda lo stato dell'arte nel cracking dell'hardware.

Per BCrypt cracking nell'hardware, guarda Implementazione ad alta velocità della password bcrypt Cerca utilizzando l'hardware per scopi speciali .

| Algorithm  | hashes/sec | hashes/sec/Watt |
|------------|------------|-----------------|
| BCrypt(12) |      410.4 |           20.52 |
| BCrypt(5)  |   51,437   |        2,572    |

Crea un ASIC personalizzato (il "Virtex-7" ), che è 10 volte più veloce di una CPU (e 30 volte più veloce di una scheda video) e utilizza il 6% della potenza di entrambi .

Questo è lo stato dell'arte del cracking della password di BCrypt. Ora confrontalo con PBKDF2 . Ho una chiavetta USB da 2,5 W che calcola 350 M hash al secondo . Puoi provare 1.000 iterazioni, 5.000 iterazioni e persino iOS 10.000 iterazioni standard:

| Algorithm   | hashes/sec | hashes/sec/Watt |
|-------------|------------|-----------------|
| BCrypt(12)  |      410.4 |           20.52 |
| BCrypt(5)   |   51,437   |        2,572    |
| PBKDF2(10k) |   35,000   |       14,000    |
| PBKDF2(5k)  |   70,000   |       28,000    |
| PBKDF2(1k)  |  350,000   |      140,000    |

Ciascuno stick USB da 2,5 W costa circa $ 8 (ne ho 14 collegati al mio server).

• Virtex-7 ASIC personalizzato: $ 3,495
• Chiavetta USB : $ 8

Utilizzo dei costi

| Algorithm   | hashes/sec | hashes/sec/Watt | hashes/sec/$ |
|-------------|------------|-----------------|--------------|
| BCrypt(12)  |      410.4 |           20.52 |       0.1174 |
| BCrypt(5)   |   51,437   |        2,572    |      14.717  |
| PBKDF2(10k) |   35,000   |       14,000    |   4,375      |
| PBKDF2(5k)  |   70,000   |       28,000    |   8,750      |
| PBKDF2(1k)  |  350,000   |      140,000    |  43,750      |

Per quanto ne so, tutte le funzioni di derivazione chiave citate sono a posto. Puoi anche usare BCrypt.net , perché è l'algoritmo che decide sulla debolezza / forza dei valori hash e non sul implementazione della libreria. Finché la libreria calcola i valori corretti, dovresti stare bene.