Non sono un esperto di sicurezza e non pretendo di essere per quello che sto chiedendo qui. Scrivo molte applicazioni basate su PHP e fino ad ora ho usato bcrypt per cancellare le mie password.
Il sito web di scrypt dichiara di essere 4000 volte più lento di bcrypt, questa affermazione può davvero essere corretta? In caso affermativo sarebbe "migliore" per uno sviluppatore attento alla sicurezza passare a utilizzare scrypt invece di bcrypt?
Scrypt dovrebbe essere "migliore" di bcrypt, ma è anche molto più recente, e questo è male (perché "più recente" implica implicitamente "ha ricevuto meno scrutinio").
Tutti questi schemi di hashing delle password cercano di rendere l'elaborazione di una singola password più costosa per l'attaccante , senza renderla troppo costosa per il tuo server . Poiché il server è, in pratica, un PC e l'utente malintenzionato può scegliere l'hardware più efficiente per la sua attività, gli schemi di hashing delle password tentano di essere tali che la piattaforma migliore per loro sia un PC. PBKDF2 può essere completamente ottimizzato con GPU, mentre bcrypt e scrypt sono molto meno compatibili con la GPU. Bcrypt e scrypt richiedono entrambi RAM veloce , che è una risorsa scarsa in una GPU (una GPU può avere un sacco di RAM, ma non sarà in grado di accedervi contemporaneamente da tutti i core).
Accade così che il moderno FPGA incorpori molti piccoli blocchi RAM che sono molto utili per ottimizzare un attacco di dizionario parallelo con bcrypt: questo significa che un utente malintenzionato otterrà un enorme incremento utilizzando 1000 $ di FPGA anziché 1000 $ di PC generico. Questo è il tipo di spinta che vogliamo evitare. Quindi scrypt, che richiede molta più RAM; non troppo per un PC (stiamo parlando solo di un paio di megabyte qui), ma abbastanza per rendere la vita dura per un FPGA (vedi questa risposta per un trattamento dettagliato della domanda).
Quindi teoricamente , scrypt dovrebbe essere migliore di bcrypt. Tuttavia , questo è tutto soggetto al fatto che lo scrypt sia all'altezza delle sue promesse crittografiche. Questo tipo di garanzia di robustezza può essere raggiunta solo nel tempo: lo schema sarà considerato sicuro se sopravvive a anni di implacabili assalti dei crittografi. Quanto tempo è necessario, è ovviamente un po 'soggettivo, e dipende anche molto da esposizione (più uno schema è distribuito, più "interessante" diventa un bersaglio, in quanto spezzandolo aumenterebbe la fama accademica del perpetratore, attirando così più controllo). La mia regola generale è di aspettare circa 5 anni dopo la pubblicazione, quindi 2014 nel caso di scrypt.
C'è anche la domanda di disponibilità : se vuoi usare una funzione, allora hai bisogno di un'implementazione che possa essere inserita nel framework di programmazione che usi.
Prenderò la frase "Scrypt è 4000 volte più lenta di BCrypt" con un grano di sale. Primo, entrambi questi algoritmi sono variabilmente complessi; anche se questa cifra "4000x" è valida, puoi rendere BCrypt altrettanto lento aggiungendo altri 11 round alla derivazione della chiave. In secondo luogo, a un certo punto sia SCrypt che BCrypt sono limitati dal tempo necessario per calcolare un hash in modo legittimo sul computer dell'utente medio (o sul server se lo si sta facendo lato server per un'app Web). SCrypt essendo più lento di 4000x potrebbe aumentare la frequenza di rimbalzo del tuo sito web di un livello superiore alla maggiore sicurezza.
Motivi per scegliere BCrypt:
BCrypt ha 14 anni, basato su un codice che ha più di 20 anni, e nessuno dei due ha mostrato alcuna debolezza teorica possibile (esiste una vulnerabilità in chiaro in Blowfish che non influisce minimamente su BCrypt, ma c'è un bug in un'implementazione UNIX di BCrypt che potrebbe causare errori dell'applicazione se fosse alimentato con determinati codici di caratteri).
SCrypt ha solo 3-4 anni, quindi non ha il pedigree crittoanalitico necessario per ottenere la fiducia della maggior parte dei crittografi. Ciò non significa che sia vulnerabile; significa che gli esperti di sicurezza di Mopst non sono abbastanza sicuri di non essere ancora vulnerabili ancora .
C'è davvero una sola ragione per scegliere SCrypt su BCrypt e questo è il motivo per cui SCrypt è stato progettato: il principale punto debole di BCrypt rispetto a un sistema di cracking distribuito è l'utilizzo di memoria basso e costante. Ciò rende BCrypt vulnerabile a forzanti brute a costi contenuti utilizzando array di gate programmabili sul campo o FPGA relativamente poco costosi. Questi array hanno una quantità relativamente piccola di SRAM integrata nei loro blocchi logici, che è ancora sufficiente per contenere i dati di stato di BCrypt. Come ha detto Thomas, questi array sono meno costosi da acquistare e configurare rispetto a una rete distribuita di crackbots tradizionali basati su CPU o GPU, quindi in modo equivalente, il tuo aggressore ottiene di più per i suoi soldi.
SCrypt, al contrario, usa non solo il tempo esponenziale, ma la memoria esponenziale; man mano che aumenta il numero di cicli di derivazione, SCrypt richiede l'archiviazione di una serie di "snapshot" di dati di stato intermedio, che vengono utilizzati in ulteriori operazioni di derivazione. Questo non è un problema per il computer di un utente legittimo che genera un hash (probabilmente stai usando al massimo qualche MB), ma la memoria limitata di un blocco FPGA diventa rapidamente insufficiente. Ora, tutto ciò che potreste memorizzare, potreste invece calcolare "on-demand", ma perché ciascuno di questi stati intermedi è il risultato della sua serie di operazioni esponenzialmente complesse (ognuna delle quali è meno complessa dell'hash finale, ma deve essere calcolato più volte per l'uso su richiesta), l'attaccante è ora sulle corna di un dilemma; o hanno bisogno di esponenziali più FPGA per stare al passo con l'aumento del tempo di calcolo del modello on-demand, o hanno bisogno di aggiornare gli FPGA a qualcosa con sufficiente memoria per fare il lavoro (in pratica si sta considerando la CPU / FSB ad alto clock) / Architetture RAM a questo punto, che è ciò che c'è dietro i cluster distribuiti di diversi milioni di dollari petaflop). In ogni caso, gli FPGA non sono più fattibili come lo sono per BCrypt (o PBKDF2).
Con scrypt oltre ad aumentare il calcolo puoi aumentare la quantità di memoria necessaria per calcolare l'hash. Questo non infastidisce molto le implementazioni del software, ma è molto più difficile da implementare con l'hardware - che è ciò che è probabile che un attaccante dedicato sviluppi e utilizzi. bcrypt (e PBKDF2) usano quantità di memoria costanti e piccole.
- Orip
Per link