Sostituzione della password in testo normale per l'app

Question

Attualmente stiamo memorizzando password in testo semplice per un'app Web di cui disponiamo.

Continuo a sostenere il passaggio a un hash della password, ma un altro sviluppatore ha affermato che sarebbe meno sicuro: più password potrebbero corrispondere all'hash e un attacco dizionario/hash sarebbe più veloce.

C’è qualche verità in questo argomento?

Answer 1

Assolutamente nessuno.Ma non importa.Ho già postato una risposta simile:

È un peccato, ma le persone, anche i programmatori, sono semplicemente troppo emotive per lasciarsi influenzare facilmente dalle discussioni.Una volta che ha investito nella sua posizione (e, se stai postando qui, lo è) difficilmente lo convincerai solo con i fatti.Quello che devi fare è invertire l'onere della prova.Devi portarlo fuori alla ricerca di dati che spera possano convincerti e, così facendo, scoprire la verità.Sfortunatamente, ha il vantaggio dello status quo, quindi la strada è dura lì.

Answer 2

Da Wikipedia

Alcuni sistemi informatici archiviano le password utente, rispetto ai quali confrontare i tentativi di accesso utente, come ClearText.Se un utente malintenzionato ottiene l'accesso a tale archivio di password interne, tutte le password e quindi tutti gli account utente saranno compromessi.Se alcuni utenti utilizzano la stessa password per gli account su sistemi diversi, saranno anche compromessi.

Sistemi più sicuri archiviano ogni password in un modulo crittograficamente protetto, quindi l'accesso alla password effettiva sarà comunque difficile per uno snooper che ottiene l'accesso interno al sistema, mentre rimane possibile la convalida dei tentativi di accesso utente.

Un approccio comune memorizza solo una forma "hashed" della password in chiaro.Quando un utente digita una password su tale sistema, il software di gestione della password viene eseguito attraverso un algoritmo hash crittografico e se il valore di hash generato dalla voce dell'utente corrisponde all'hash memorizzato nel database della password, l'utente è consentito l'accesso.Il valore hash viene creato applicando una funzione hash crittografica a una stringa costituita dalla password presentata e, di solito, un altro valore noto come sale.Il sale impedisce agli aggressori di costruire un elenco di valori di hash per password comuni.MD5 e Sha1 sono spesso funzioni di hash crittografiche.

C'è molto altro che puoi leggere sull'argomento in quella pagina.A mio parere, e in tutto ciò che ho letto e con cui ho lavorato, l'hashing è uno scenario migliore a meno che non si utilizzi un algoritmo molto piccolo (<256 bit).

Answer 3

Non ci sono assolutamente scuse per mantenere password in testo semplice sull'app Web.Utilizza un algoritmo di hashing standard (SHA-1, non MD5!) con un valore salt, in modo che gli attacchi arcobaleno siano impossibili.

Answer 4

Non capisco come gli altri tuoi sviluppatori pensino che "più password potrebbero corrispondere all'hash".

Si sostiene che un "attacco hash sarebbe più veloce", ma solo se non si salano le password mentre vengono sottoposte ad hashing.Normalmente, le funzioni di hashing consentono di fornire un sale che rende l'uso della tabella hash conosciuta una perdita di tempo.

Personalmente direi di no.Sulla base di quanto sopra, nonché del fatto che se in qualche modo si ottiene l'esposizione di testo in chiaro, un valore con hash salato ha poco valore per qualcuno che tenta di entrare.L'hashing offre anche il vantaggio di far sì che tutte le password "sembrino" della stessa lunghezza.

cioè, se l'hashing di una stringa dà sempre come risultato un hash di 20 caratteri, se hai solo l'hash da guardare, non puoi dire se la password originale era di otto o sedici caratteri, ad esempio.

Answer 5

Ho riscontrato esattamente lo stesso problema sul posto di lavoro.Ciò che ho fatto per convincerlo che l'hashing era più sicuro è stato scrivere un'iniezione SQL che restituisse l'elenco di utenti e password dalla sezione pubblica del nostro sito.È stato immediatamente segnalato come un grave problema di sicurezza :)

Per evitare attacchi con dizionario/hash, assicurati di eseguire l'hash contro un token univoco per ciascun utente e statico (nome utente/data di iscrizione/guida utente funziona bene)

Answer 6

Se non salti la tua password, sei sospettato di attacchi Rainbow Table (dizionari precompilati che hanno input validi per un determinato hash)

L'altro sviluppatore dovrebbe smettere di parlare di sicurezza se memorizzi le password in testo normale e iniziare a leggere sulla sicurezza.

Le collisioni sono possibili, ma di solito non sono un grosso problema per le app per password (sono principalmente un problema nelle aree in cui gli hash vengono utilizzati come modo per verificare l'integrità dei file).

COSÌ:Saltate le vostre password (aggiungendo Salt sul lato destro della password*) e usate un buon algoritmo di hashing come SHA-1 o preferibilmente SHA-256 o SHA-512.

PS:Un po' più di dettagli sugli hash Qui.

*Non sono sicuro se il sale debba essere posizionato all'inizio o alla fine della stringa.Il problema è che se si verificano collisioni (due input con lo stesso hash), l'aggiunta di Salt al lato "sbagliato" non modificherà l'hash risultante.In ogni caso non avrai grossi problemi con Rainbow Tables, solo con le collisioni

Answer 7

C'è un vecchio detto sui programmatori che fingono di essere crittografi :)

Jeff Atwood ha un buon post sull'argomento: Probabilmente stai memorizzando le password in modo errato

Per rispondere in modo più ampio, sono d'accordo con tutto quanto sopra, l'hash lo rende più semplice in teoria per ottenere la password dell'utente poiché più password corrispondono allo stesso hash.Tuttavia, questo è molto meno probabile che accada rispetto a qualcuno che ottiene l'accesso al tuo database.

Answer 8

È vero che se esegui l'hashing di qualcosa, sì, ci saranno collisioni, quindi sarebbe possibile che due password diverse sblocchino lo stesso account.

Da un punto di vista pratico, però, questo è un argomento scarso: una buona funzione di hashing (md5 o sha1 andrebbe bene) può praticamente garantire che per tutte le stringhe significative, specialmente quelle corte, non ci saranno collisioni.Anche se ci fossero, avere due password corrispondenti per un account non è un grosso problema: se qualcuno è in grado di indovinare casualmente le password abbastanza velocemente da riuscire ad entrare, hai problemi più grandi.

Direi che archiviare le password in testo semplice rappresenta un rischio per la sicurezza molto maggiore rispetto alle collisioni di hash nella corrispondenza delle password.

Answer 9

Non sono un esperto di sicurezza, ma ho la sensazione che se il testo semplice fosse più sicuro, l'hashing non esisterebbe in primo luogo.

Answer 10

In teoria sì.Le password possono essere più lunghe (più informazioni) di un hash, quindi esiste la possibilità di collisioni di hash.Tuttavia, la maggior parte degli attacchi sono basati su dizionario e la probabilità di collisioni è infinitamente inferiore rispetto a una corrispondenza diretta riuscita.

Answer 11

Dipende da cosa ti stai difendendo.Se si tratta di un utente malintenzionato che sta distruggendo il tuo database (o inducendo la tua applicazione a visualizzare il database), le password in chiaro sono inutili.Esistono molti attacchi che si basano sul convincere l'applicazione a rilasciare i propri dati privati: iniezione SQL, dirottamento della sessione, ecc.Spesso è meglio non conservare affatto i dati, ma mantenere la versione con hash in modo che i malintenzionati non possano usarla facilmente.

Come suggerisce il tuo collega, questo può essere banalmente risolto eseguendo lo stesso algoritmo di hash su un dizionario e utilizzando le tabelle arcobaleno per estrarre le informazioni.La soluzione usuale è utilizzare un sale segreto più informazioni aggiuntive sull'utente per rendere unici i risultati con hash, qualcosa come:

String hashedPass=CryptUtils.MD5("alsdl;ksahglhkjfsdkjhkjhkfsdlsdf" + user.getCreateDate().toString() +  user.getPassword);

Finché il tuo sale è segreto o il tuo aggressore non conosce la data precisa di creazione del record dell'utente, un attacco con dizionario fallirà, anche nel caso in cui sia in grado di eliminare il campo della password.

Answer 12

Niente è meno sicuro della memorizzazione di password in testo semplice.Se stai utilizzando un algoritmo di hashing decente (almeno SHA-256, ma anche SHA-1 è meglio di niente) allora sì, le collisioni sono possibili, ma non importa perché dato un hash, è impossibile* calcolare cosa stringhe hash ad esso.Se esegui l'hashing del nome utente CON la password, anche questa possibilità scompare dalla finestra.

* - tecnicamente non impossibile, ma "computazionalmente irrealizzabile"

Se il nome utente è "graeme" e la password è "stackoverflow", crea una stringa "graeme-stackoverflow-1234" dove 1234 è un numero casuale, quindi esegui l'hashing e memorizza "hashoutput1234" nel database.Quando si tratta di convalidare una password, prendi il nome utente, la password fornita e il numero alla fine del valore memorizzato (l'hash ha una lunghezza fissa, quindi puoi sempre farlo) e sottoponili ad hash insieme e confrontalo con l'hash parte del valore memorizzato.

Answer 13

più password potrebbero corrispondere all'hash e un attacco dizionario/hash sarebbe più veloce.

Sì e no.Usa un moderno algoritmo di hashing, come una variante SHA, e quell'argomento diventa molto, molto settimana.C’è davvero bisogno di preoccuparsi se quell’attacco di forza bruta richiederà solo 352 anni invece di 467 anni?(Scherzo aneddotico lì.) Il valore da ottenere (non avere la password memorizzata in testo semplice nel sistema) supera di gran lunga le preoccupazioni del tuo collega.

Answer 14

Spero che mi perdoni per aver inserito una soluzione che ho scritto su questo, utilizzando JavaScript lato client per eseguire l'hashing della password prima che venga trasmessa: http://blog.asgeirnilsen.com/2005/11/password-authentication-without.html