Ho letto che quando si esegue l'hashing di una password, molti programmatori consigliano di utilizzare l'algoritmo BCrypt.
Sto programmando in C # e mi chiedo se qualcuno sia a conoscenza di una buona implementazione per BCrypt? Ho trovato questa pagina , ma non so se sia falsa o meno.
Cosa devo sapere quando scelgo uno schema di hashing della password? BCrypt è un'implementazione "buona"?
Risposte:
Innanzitutto, alcuni termini importanti:
Hashing - L'atto di prendere una stringa e produrre una sequenza di caratteri che non può essere ripristinata alla stringa originale.
Crittografia simmetrica - (di solito chiamata semplicemente "crittografia"): l'atto di prendere una stringa e produrre una sequenza di caratteri che può essere decrittografata nella stringa originale attraverso l'uso della stessa chiave di crittografia che l'ha crittografata.
Rainbow Table : una tabella di ricerca che contiene tutte le varianti di caratteri con hash in un algoritmo di hashing specifico.
Salt : una stringa casuale nota aggiunta alla stringa originale prima che venga hash.
Per .NET Framework, Bcrypt non ha ancora un'implementazione di riferimento verificata . Questo è importante perché non c'è modo di sapere se ci sono gravi difetti in un'implementazione esistente. Puoi ottenere un'implementazione di BCrypt per .NET qui . Non so abbastanza sulla crittografia per dire se si tratta di un'implementazione buona o cattiva. La crittografia è un campo molto profondo. Non tentare di creare il tuo algoritmo di crittografia . Sul serio.
Se hai intenzione di implementare la tua sicurezza della password (sospiro), allora devi fare diverse cose:
Sfortunatamente, anche se fai tutto questo, un determinato hacker potrebbe ancora potenzialmente scoprire le password, ci vorrebbe solo molto tempo. Questo è il tuo principale nemico: il tempo .
L' algoritmo bcrypt funziona perché impiega cinque ordini di grandezza in più per eseguire l'hashing di una password rispetto a MD5 ; (e ancora molto più lungo di AES o SHA-512). Obbliga l'hacker a dedicare molto più tempo alla creazione di una tabella arcobaleno per la ricerca delle password, rendendo molto meno probabile che le password siano a rischio di essere violate.
Se stai salando e cancellando le tue password, e ogni sale è diverso, un potenziale hacker dovrebbe creare una tabella arcobaleno per ogni variante di sale , solo per avere una tabella arcobaleno per una password salata + con hash. Ciò significa che se hai 1 milione di utenti, un hacker deve generare 1 milione di tabelle arcobaleno. Se stai usando lo stesso sale per ogni utente, l'hacker deve solo generare 1 tabella arcobaleno per hackerare con successo il tuo sistema.
Se non stai salando le tue password, tutto ciò che un utente malintenzionato deve fare è estrarre una tabella Rainbow esistente per ogni implementazione (AES, SHA-512, MD5) e vedere se una corrisponde all'hash. Questo è già stato fatto , un attaccante non ha bisogno di calcolare da soli queste tabelle Rainbow .
Anche con tutto ciò, devi usare buone pratiche di sicurezza . Se riescono a utilizzare correttamente un altro vettore di attacco (XSS, SQL Injection, CSRF, ecc. ) Sul tuo sito, la buona sicurezza della password non ha importanza. Sembra un'affermazione controversa, ma pensaci: se riesco a ottenere tutte le tue informazioni utente attraverso un attacco di iniezione SQL o posso convincere i tuoi utenti a fornirmi i loro cookie tramite XSS, non importa quanto sia buona la tua password la sicurezza è .
Altre risorse:
Nota: si prega di raccomandare altre buone risorse. Devo aver letto una dozzina di articoli di dozzine di autori, ma pochi scrivono chiaramente sull'argomento come fa Jeff. Modifica gli articoli quando li trovi.
Non è necessario utilizzare BCrypt in .NET. È necessario utilizzare PBKDF2 come nell'implementazione del framework .NET integrata. È l'unica implementazione crittografica verificata liberamente disponibile in .NET oltre ad essere l' algoritmo raccomandato da NIST .
StackId ha precedentemente utilizzato BCrypt e si è spostato su PBKDF2 proprio per questo motivo:
Per i curiosi, stiamo eseguendo l'hashing delle password con PBKDF2. Il codice Relavent è qui ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ), attraverso alcuni livelli di riferimento indiretto. In una precedente iterazione, stavamo usando BCrypt; ma è passato a PBKDF2 poiché è integrato nel framework .NET, mentre BCrypt ci richiederebbe di verificare un'implementazione (non di piccola impresa).
Kevin Montrose, 27 maggio 2011
Modifica: il significato di verificato in termini crittografici sembra non essere facilmente compreso, un'implementazione verificata significa che è stato dimostrato crittograficamente di essere implementato senza errori. Il costo di questo può facilmente raggiungere $ 20.000 o superiore. Ricordo questo quando stavo facendo ricerche su OpenSSL e ho letto dove hanno dichiarato di non aver completato l'intero processo di verifica, ma se hai bisogno di una verifica completa che possono indicarti la strada giusta per esso e menzionare i costi associati. Alcuni requisiti governativi includono mandati per algoritmi di crittografia verificati.
Le implementazioni di bcrypt in .NET non sono state verificate. Utilizzando un'implementazione di crittografia non verificata non si può essere assolutamente certi che non vi siano errori dannosi intenzionali in esso, come consentire una backdoor in ciò che è crittografato o errori di implementazione non intenzionali che si traducono in dati crittograficamente non sicuri.
Modifica 2014: per chiunque abbia messo in dubbio l'imperatività dell'uso di algoritmi crittografici verificati, guarda la devastazione che è stata provocata dall'hack sincero sfruttato in OpenSSL. Questo è il costo dell'utilizzo di un'implementazione non verificata. È sicuro .... finché non scopri che qualsiasi persona può semplicemente leggere l'intero contenuto della memoria del tuo server.
L'autore della modifica che ha introdotto Heartbleed, Robin Seggelmann, ha dichiarato che "ha perso la convalida di una variabile contenente una lunghezza" e ha negato qualsiasi intenzione di presentare un'implementazione errata. In seguito alla divulgazione di Heartbleed, Seggelmann ha suggerito di concentrarsi sul secondo aspetto, affermando che OpenSSL non è stato recensito da un numero sufficiente di persone.
Questa è la definizione di un'implementazione non verificata. Anche il più piccolo difetto può causare paralizzare l'intera sicurezza.
Modifica 2015: lingua basata su raccomandazioni rimossa e sostituita con assoluti. Commento originale incorporato di Kevin Montrose per i posteri.