Come crittografare tutte le password dei clienti esistenti [chiuso]

Le password dovrebbero essere salate e sottoposte a hash, non crittografate. Dovresti usare un hash lento per mitigare gli attacchi di precomputazione. C'è il codice .NET qui: link

Modificato per aggiungere: se il numero di account è basso, potresti semplicemente bloccare i tentativi di accesso mentre viene eseguito il codice di hashing. Tuttavia, è progettato per essere lento, quindi potrebbe essere necessario consentire l'accesso mentre le password vengono sottoposte a hash. Non c'è problema. Confronta prima la password in chiaro; se non c'è corrispondenza, cancella la password offerta e confronta di nuovo.

Non dimenticare che devi conservare il sale e l'hash. Se non si modifica lo schema del database, questi possono essere concatenati e archiviati nel campo della password esistente, assumendo che sia varchar. In caso contrario, potrebbe essere necessario aggiungere colonne al database e cancellare la colonna di testo in chiaro dopo che il calcolo dell'hash è completo e impegnato.

Controlla il meccanismo di recupero della password. Quando hai fatto questo, non sarai in grado di dire agli utenti quali sono le loro password. Avrai bisogno di un altro meccanismo di recupero.

Non pertinente alla domanda, ma se non stai utilizzando TLS per il login, è necessario.

L'opzione migliore per l'hashing della password è fornita immediatamente. Net è PBKDF2, che come CodesInChaos commentato è implementato come System.Security.Cryptography.Rfc2898DeriveBytes .

La vera scelta che devi fare è se questo è il solo che modifica le esigenze del codice di gestione dell'account / password. In tal caso, è possibile implementarlo direttamente, sostituendo la gestione della password corrente e utilizzandola.

Se, tuttavia, ci sono altri problemi con il modo in cui gestisci le credenziali (e con la memorizzazione di password in testo normale, sospetto che sia probabile), potrebbe essere un'idea migliore astrarre completamente la gestione degli account e ridimensionare il applicazione per utilizzare ASP.NET Identity invece. Ciò fornirà per impostazione predefinita l'hashing delle password basato su PBKDF2 e fornirà anche soluzioni pronte per cose come la reimpostazione della password, i meccanismi di blocco dell'account per impedire la forzatura della password e molti altri vantaggi per la sicurezza.

È preferibile eseguire l'hash di una password anziché crittografarla. Fondamentalmente, l'hashing è un meccanismo a senso unico mentre la crittografia è reversibile.

Perché è così importante? Bene, se un'entità malvagia (che potrebbe essere un dipendente) scopre come hai crittografato i dati (sia con la forza bruta o semplicemente rubando la chiave, ecc.) Che possono decifrarli - e poi (male) usare le password dei tuoi clienti, la maggior parte di cui sarà stato riutilizzato altrove (altri siti, email, banche ecc.). Una violazione del genere danneggerebbe la reputazione del tuo sito / azienda.

Con un hash, puoi sapere come è stato generato un valore hash, ma non conoscerai il valore (la loro password) che lo ha generato. A meno che, naturalmente, non si stia proteggendo la comunicazione tra il server al momento dell'accesso (HTTP invece delle pagine Web HTTPS, ad esempio). *

Come parte di questo processo, anche la password dovrebbe essere salata:

In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes a password or passphrase.[1] The primary function of salts is to defend against dictionary attacks versus a list of password hashes

Fonte: link

Ancora una volta, in pratica, questo sarebbe il punto in cui un utente malintenzionato prende una lista di parole conosciute / comuni (passate), pronuncia "letmein" e lo blocca. Sapere che conosceranno l'hash che corrisponde alla password "letmein" e possono cercare rapidamente se qualcuno dei tuoi utenti ha lo stesso hash della password. Ovviamente, questo è molto facile da automatizzare con un "dizionario" di parole possibili / comuni (pass). Salting aiuta a prevenire questo scenario.

Per quanto riguarda come implementarlo in .NET, vedi questa domanda (e le risposte) da Stack Overflow:

link

Non ho molta familiarità con lo sviluppo di .NET, ma secondo la risposta di @jd4u l'implementazione di default usa un salt in aggiunta alla password dell'utente quando si produce un hash.

* Se le pagine del tuo sito (almeno il log on) non sono già servite su una connessione protetta, fai anche questo.