BCrypt è un buon algoritmo di hashing da utilizzare in C#?Dove posso trovarlo?[Chiuso]

Question

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 conosce una buona implementazione per BCrypt?ho trovato questa pagina, ma non so davvero se sia fasullo o no.

A cosa devo prestare attenzione quando scelgo uno schema di hashing della password?BCrypt è una "buona" implementazione?

Answer 1

Innanzitutto, alcuni termini importanti:

Hashing - L'atto di prendere una stringa e produrre una sequenza di caratteri che non può essere ripristinata nella stringa originale.

Crittografia simmetrica - (Di solito chiamata semplicemente "crittografia") - L'atto di prendere una stringa e produrre una sequenza di caratteri che Potere essere decrittografato nella stringa originale attraverso l'uso della stessa chiave di crittografia che lo ha crittografato.

Tavolo Arcobaleno - una tabella di ricerca che contiene tutte le variazioni dei caratteri sottoposti a hashing in uno specifico algoritmo di hashing.

Sale - una stringa casuale nota aggiunta alla stringa originale prima che venga sottoposta ad hashing.

Per .NET Framework, Bcrypt non ha ancora un file verificato implementazione di riferimento.Questo è importante perché non c'è modo di sapere se ci sono gravi difetti in un'implementazione esistente.È possibile ottenere un'implementazione di BCrypt per .NET qui.Non ne so abbastanza di 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 intendi implementare la sicurezza della tua password (sigh), devi fare diverse cose:

1. Usare un algoritmo hash relativamente sicuro.
2. Salare ogni password prima che venga sottoposta ad hashing.
3. Usare un sale unico e lungo per ogni password, e conservare il sale con la password.
4. Richiedi password complesse.

Sfortunatamente, anche se si facesse tutto questo, un hacker determinato potrebbe comunque riuscire a capire le password, ma gli ci vorrebbe davvero molto tempo.Questo è il tuo principale nemico: Tempo.

IL L'algoritmo bcrypt funziona perché richiede cinque ordini di grandezza più lunghi per eseguire l'hashing di una password rispetto a MD5;(e comunque molto più lungo di AES o SHA-512).Costringe l'hacker a dedicare molto più tempo alla creazione di una tabella arcobaleno per cercare le tue password, rendendo molto meno probabile che le tue password siano a rischio di essere violate.

Se stai effettuando il salting e l'hashing delle tue password e ogni salt è diverso, quindi un potenziale hacker dovrebbe creare una tabella arcobaleno per ogni variazione di salt, solo per avere una tabella arcobaleno per una password con sale+hash.Ciò significa che se hai 1 milione di utenti, un hacker deve generare 1 milione di tabelle arcobaleno.Se utilizzi lo stesso salt per ogni utente, l'hacker dovrà generare solo 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 è aprire una tabella Rainbow esistente per ogni implementazione disponibile (AES, SHA-512, MD5) e vedere se una corrisponde all'hash.Questo è già stato fatto, un aggressore non ha bisogno di calcolare da solo queste tabelle Rainbow.

Anche con tutto questo, devi utilizzare buone pratiche di sicurezza.Se riescono a utilizzare con successo un altro vettore di attacco (XSS, SQL Injection, CSRF, et.al.) sul tuo sito, una buona sicurezza della password non ha importanza.Sembra un’affermazione controversa, ma pensaci:Se riesco a ottenere tutte le informazioni sui tuoi utenti tramite un attacco SQL injection, o posso convincere i tuoi utenti a fornirmi i loro cookie tramite XSS, quindi non importa quanto sia buona la sicurezza della tua password.

Altre risorse:

1. Jeff Atwood: Crittografia .NET semplificata (ottimo per una panoramica dell'hashing)
2. Jeff Atwood: Ho appena effettuato l'accesso come te
3. Jeff Atwood: Probabilmente stai memorizzando le password in modo errato
4. Jeff Atwood: Hashing veloce

Nota: Si prega di consigliare altre buone risorse.Devo aver letto una dozzina di articoli di dozzine di autori, ma pochi scrivono sull'argomento in modo così chiaro come fa Jeff.Modifica gli articoli man mano che li trovi.

Answer 2

Non devi usare 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 la algoritmo raccomandato da NIST .

StackId precedentemente utilizzava BCrypt e si spostava su PBKDF2 proprio per questo motivo:

  

Per chi è curioso, & # 8217; rielaborando le password con PBKDF2. 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, noi   stavano usando BCrypt; ma spostato in PBKDF2 come è incorporato in .NET   framework, mentre BCrypt ci richiederebbe di verificare un'implementazione   (non piccola impresa).

Kevin Montrose, 27 maggio 2011

(collegamento aggiornato su GitHub)

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 delle 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 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 né errori intenzionali dannosi 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 da hack heartbleed 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 di raccomandazione rimossa e sostituita con assoluti. Commento originale incorporato di Kevin Montrose per i posteri.