Qual è la pratica consigliata per la memorizzazione delle password utente in SQL Server 2008?memorizzazione delle password in SQL Server
Sto memorizzando i dettagli utente per una rete intranet e vorrei ricevere consigli sul modo migliore per archiviare i dettagli di un utente come nome, password e accesso utente, ecc. Sto pensando di creare una colonna nvarchar e quindi di crittografarla. testo prima di inserirlo nella tabella.
che è generalmente il modo per farlo.
L'applicazione gestirà la crittografia (e opzionalmente decrittografia), il database memorizzerà semplicemente la password.
mi consiglia di utilizzare qualcosa di più forte rispetto alla de facto datato - MD5
sviluppatori .net La maggior parte sembrano come utilizzare TDES
Concordo sul fatto che si desideri utilizzare qualcosa di più potente di MD5 quando è possibile –
MD5 non è un algoritmo di crittografia, è un algoritmo di hashing. http://en.wikipedia.org/wiki/MD5 –
Concordato. Immagino di non essere stato esplicito così da ottenere un aumento :) –
T-SQL include funzioni di crittografia - 4Guys aveva un aa good article on it for SQL Server 2005 po 'indietro, ma penso che tutto si applica ancora al 2008.
Questo articolo è sulla crittografia a chiave simmetrica. Le password dovrebbero essere sottoposte a hash. – Swoogan
Sono d'accordo: l'articolo a cui mi sono collegato è significativamente datato. Questo è il motivo per cui ho alzato personalmente la risposta di elazar-leibovich sopra. –
La crittografia per i dati sensibili è buona. Tuttavia, con le password, non si dovrebbe mai aver bisogno di conoscere il valore originale, e dato che tutto ciò che è criptato può anche essere decodificato, si mette a rischio di essere scoperti.
Invece, si dovrebbe mantenere un hash della password. Questo processo prende il valore e genera ciò che equivale a un checksum molto complicato. Dato il numero, non c'è modo di tornare alla password originale, il che aumenta la sicurezza di tali informazioni. Quando vuoi sapere se qualcuno ti ha dato la password corretta, hai cancellato il valore che ti hanno dato e confrontato gli hash.
La sicurezza è un argomento complicato. Anche con gli hash, si può finire per avere un sistema che ha significativi difetti di sicurezza. Ottenere l'aiuto di un consulente di sicurezza non è una cattiva idea se nessun altro nel tuo team ha già quel tipo di conoscenza.
Molto vero nella maggior parte dei casi. Dato che l'OP sta usando su una intranet, ci possono essere circostanze (l'integrazione con altre applicazioni sulla intranet che richiedono l'accesso) dove è possibile recuperare la password. Il collegamento –
Il modo consueto di memorizzare la password consiste nell'utilizzare una funzione di hash sulla password, ma su salt in precedenza. È importante "salare" la password per difendersi dagli attacchi rainbow table.
Così la vostra tabella dovrebbe essere simile a quello
._______._________________.______________.
|user_id|hash |salt |
|-------|-----------------|--------------|
|12 |[email protected]|13%!#tQ!#3t...|
| |... |... |
Quando si controlla se una determinata password corrisponde a un utente, si dovrebbe concatenare il sale per la password data, e calcolare la funzione hash della stringa di risultato. Se l'output della funzione hash corrisponde alla colonna hash, è la password corretta.
È importante capire, tuttavia, che l'idea di hash ha un motivo specifico: impedire a chiunque abbia accesso al database di conoscere qualsiasi password (è considerato un problema difficile invertire l'output di una funzione hash). Quindi, ad esempio, il DBA della banca, non sarebbe in grado di accedere al tuo conto bancario, anche se ha accesso a tutte le colonne.
Si consiglia inoltre di utilizzarlo se si ritiene che gli utenti utilizzeranno una password sensibile (ad esempio la password per il proprio account Gmail) come password per il sito Web.
IMHO non è sempre una funzione di sicurezza che è necessaria. Quindi dovresti pensare se lo vuoi o no.
Vedere this article per un buon riepilogo di questo meccanismo.
Aggiornamento: Vale la pena ricordare, che per una maggiore sicurezza contro l'attacco mirato per l'inversione di hash di password personale, si dovrebbe use bcrypt, che può essere arbitrariamente difficile da calcolare. (Ma a meno che tu non sia davvero spaventato dal misterioso uomo in nero che prende di mira il tuo database specifico, penso che sha1 sia abbastanza buono.Non introdurrei un'altra dipendenza per il mio progetto per questa ulteriore sicurezza.Questo, non c'è motivo per non usare sha1 100 volte, il che darebbe un effetto simile).
non funziona, ma [questo] (http://msdn.microsoft.com/en-us/library/ff649202.aspx) lo si fa. – JumpingJezza
@JumpingJezza, grazie, funzionava, sto aggiornando il link –
Se si tratta di un dominio AD, non è possibile consentire a AD di gestire l'autenticazione? – Rytmis
Grazie a tutti per i suggerimenti. Richard – Richard