security how - Il modo migliore per memorizzare la password nel database





to store (8)


Come hash salato indurito con chiave, utilizzando un algoritmo sicuro come sha-512.

Sto lavorando a un progetto che deve avere l'autenticazione (nome utente e password)

Si collega anche a un database, quindi ho pensato che avrei memorizzato il nome utente e la password lì. Tuttavia, non sembra una buona idea avere le password come solo un campo di testo in una tabella che si trova sul database.

Sto usando C # e la connessione a un server Express 2008. Qualcuno può suggerire (con più esempi possibili) quale sarebbe il modo migliore per archiviare questo tipo di dati?

PS Sono aperto all'idea che queste informazioni non vengano archiviate nel database se è possibile fornire una buona motivazione




Nel tuo scenario, puoi dare un'occhiata all'appartenenza di asp.net, è buona pratica archiviare la password dell'utente come stringa hash nel database. è possibile autenticare l'utente confrontando la password in arrivo con hash con quella memorizzata nel database.

Tutto è stato costruito per questo scopo, controlla l' appartenenza a asp.net




Background Non hai mai ... davvero ... bisogno di conoscere la password dell'utente. Vuoi solo verificare che un utente entrante conosca la password per un account.

Hash It: memorizza l'hash delle password degli utenti (crittografia unidirezionale) tramite una potente funzione di hash. Una ricerca per "c # encrypt passwords" fornisce un sacco di esempi.

Vedere il creatore di hash SHA1 online per un'idea di cosa produce una funzione di hash (ma non usare SHA1 come funzione hash, usare qualcosa di più forte come SHA256).

Ora, una password con hash significa che tu (e ladri di database) non dovresti essere in grado di reinserire l'hash nella password originale.

Come si usa: Ma, tu dici, come posso usare questa password modificata memorizzata nel database?

Quando l'utente effettua il login, ti consegnerà il nome utente e la password (nel suo testo originale). Basta usare lo stesso codice hash per cancellare la password digitata per ottenere la versione memorizzata.

Quindi, confronta le due password hash (hash del database per il nome utente e la password con hash e digitato). Si può sapere se "ciò che hanno digitato" corrisponde a "ciò che l'utente originale ha inserito per la propria password" confrontando i propri hash.

Credito extra:

Domanda: Se avessi il tuo database, non potrei semplicemente prendere un cracker come John the Ripper e iniziare a fare hash finché non troverò le corrispondenze con le tue password memorizzate e con hash? (dato che gli utenti scelgono parole brevi, comunque ... dovrebbe essere facile)

Risposta: Sì ... sì, possono.

Quindi, dovresti "salare" le tue password. Vedi l' salt

Vedi "Come hash dati con sale" C # esempio




Hai ragione nel dire che memorizzare la password in un campo di testo semplice è un'idea orribile . Tuttavia, per quanto riguarda la posizione , per la maggior parte dei casi che incontrerai (e onestamente non riesco a pensare a nessun contro-esempio) la memorizzazione della rappresentazione di una password nel database è la cosa giusta da fare. Per rappresentazione intendo che si desidera hash la password utilizzando un salt (che dovrebbe essere diverso per ogni utente) e un algoritmo sicuro a 1 via e memorizzarlo, buttando via la password originale. Quindi, quando si desidera verificare una password, si esegue l'hash del valore (utilizzando lo stesso algoritmo di hash e salt) e lo si confronta con il valore hash nel database.

Quindi, mentre è una buona cosa che stai pensando a questo ed è una buona domanda, questo è in realtà un duplicato di queste domande (almeno):

Per chiarire un po 'il bit di salatura, il pericolo con la semplice hashing di una password e la memorizzazione è che se un intruso entra in possesso del tuo database, possono comunque usare le cosiddette rainbow tables per poter "decifrare" il password (almeno quelle che compaiono nella tabella arcobaleno). Per aggirare questo problema, gli sviluppatori aggiungono una parola d'ordine alle password che, se fatte correttamente, rendono semplicemente irrealizzabili gli attacchi arcobaleno. Si noti che un comune equivoco è semplicemente quello di aggiungere la stessa stringa unica e lunga a tutte le password; mentre questo non è orribile , è meglio aggiungere sali unici a ogni password. Leggi questo per altro




Potrei essere leggermente fuori tema perché hai menzionato la necessità di un nome utente e una password, e la mia comprensione del problema non è ammessa, ma OpenID è qualcosa che vale la pena considerare?

Se si utilizza OpenID, non si finisce affatto con la memorizzazione di credenziali se si comprende correttamente la tecnologia e gli utenti possono utilizzare le credenziali già esistenti, evitando di dover creare una nuova identità specifica per la propria applicazione.

Potrebbe non essere adatto se l'applicazione in questione è puramente per uso interno

RPX offre un modo semplice per integrare il supporto di OpenID in un'applicazione.




Vorrei MD5 / SHA1 la password se non è necessario essere in grado di invertire l'hash. Quando gli utenti accedono, puoi semplicemente crittografare la password fornita e confrontarla con l'hash. Le collisioni di hash sono quasi impossibili in questo caso, a meno che qualcuno non ottenga l'accesso al database e veda un hash per il quale esiste già una collisione.







Un'altra opzione che potresti non aver considerato è consentire azioni via email. È un po 'ingombrante, ma l'ho implementato per un client che aveva bisogno di utenti "esterni" al proprio sistema per visualizzare (sola lettura) alcune parti del sistema. Per esempio:

  1. Una volta che un utente è registrato, ha pieno accesso (come un normale sito Web). La registrazione deve includere una e-mail.
  2. Se sono necessari dati o un'azione e l'utente non ricorda la propria password, può comunque eseguire l'azione facendo clic su un pulsante speciale " inviami un'e-mail per autorizzazione ", proprio accanto al normale pulsante " invia ".
  3. La richiesta viene quindi inviata all'e-mail con un collegamento ipertestuale che chiede se desidera che l'azione venga eseguita. Questo è simile a un collegamento email di reimpostazione della password, ma invece di reimpostare la password esegue l' azione una tantum .
  4. L'utente fa quindi clic su "Sì" e conferma che i dati devono essere mostrati, o che l'azione deve essere eseguita, i dati rivelati, ecc.

Come hai menzionato nei commenti, questo non funzionerà se l'e-mail è compromessa, ma indirizza il commento di @joachim sul fatto di non voler reimpostare la password. Alla fine, avrebbero dovuto usare la reimpostazione della password, ma potevano farlo in un momento più conveniente, o con l'assistenza di un amministratore o di un amico, se necessario.

Una svolta a questa soluzione sarebbe quella di inviare la richiesta di azione a un amministratore fidato di terze parti. Ciò funzionerebbe meglio in caso di utenti anziani, con problemi mentali, giovanissimi o in altro modo confusi. Ovviamente ciò richiede un amministratore fidato affinché queste persone supportino le loro azioni.





database security passwords