Perché la gente non ha hash e sale nomi utente prima di memorizzarli

Mentre quello che Terry sta dicendo è vero, a volte i sistemi di login in realtà cancellano il nome utente (ma senza sale). Hanno scelto un nome di accesso e un nome visualizzato. Il nome di accesso viene memorizzato come hash (senza sale perché è necessario essere in grado di cercarlo) e la password viene salata. Il nome visualizzato è diverso dal tuo nome di accesso (perché anche questo dovrebbe essere tenuto segreto) e viene mostrato dove necessario.

Anche quando un utente malintenzionato vede il tuo nome, non sarà in grado di collegarlo al tuo nome di accesso. Mentre dico che può essere salato, in realtà non c'è bisogno di questo. La parte più importante è solo per tenerlo segreto. Se il database viene compromesso, elementi come il tuo indirizzo e-mail o il nome saranno ancora lì per l'aggressore da utilizzare se vuole mettere in scena nuovi attacchi sugli altri account.

Vedi quella cosa lassù dove mostra il tuo nome utente? Non possono farlo se il nome utente è memorizzato come hash ora?

Una parola, usabilità.

Generalmente i nomi utente non sono considerati sicuri, sono identità, non autenticazione. È bene non rivelare quali nomi utente sono validi, ma sarebbe peggio se ti capita di avere una collisione. Puoi ancora risolvere il problema osservando tutti i nomi utente corrispondenti per un hash della password che corrisponde, ma è un po 'disordinato.

Realisticamente, se altrimenti hai una buona sicurezza della password e limiti ai tentativi di accesso, un elenco completo di nomi utente offre un piccolo valore pratico per un utente malintenzionato. Il vantaggio principale sarebbe il phishing, ma se la tua corrispondenza ufficiale contiene informazioni in esso, allora tali informazioni non possono essere sottoposte a hash e lo otterrebbero se compromettessero comunque il tuo DB.

Inoltre, usabilità come ha detto Terry. È molto più facile trovare il tuo account se possono vedere i nomi utente. Non guadagni abbastanza provando a proteggere un identificatore per giustificarlo nella maggior parte dei contesti.

Mentre altri hanno ben evidenziato che ci sono pochi (se non nessuno) vantaggi, vorrei prendere in considerazione la tua affermazione che non ci sono degli inconvenienti. Se memorizzi solo il nome utente con hash, cercare il nome utente è facile. Se memorizzi un nome utente hash salato, la ricerca diventa un po 'più problematica.

Supponiamo che se costruiamo una tabella SQL contenente nomi utente e password (hash) e dica al server SQL di indicizzare la colonna username che farà una sorta di ricerca binaria o altra magia. Potremmo avere una tabella simile a:

Username  |  Password
test      |  j9lnvqjAuhNJs

(Questo è l'hash di unix crypt (3) vecchia scuola solo per semplicità e brevità.)

Se si memorizzano i nomi utente in testo semplice, il recupero della password (con hash) per un utente è una semplice chiamata SQL. Supponiamo che tu voglia convalidare le credenziali per un utente che ha digitato il nome utente test :

SELECT password FROM users WHERE username='test';

Semplice abbastanza. Ora, se dovessimo memorizzare i nomi utente nello stesso formato delle password, la nostra tabella risulterebbe così:

Username       |  Password
M1CAtvzDdJDGU  |  j9lnvqjAuhNJs

Ora, quando un utente digita il proprio nome utente di test , come si convalida la password? Una ricerca binaria è inutile qui, dal momento che non conosci nemmeno il sale che hai usato per memorizzare il nome utente. Invece, è necessario scorrere su ogni nome utente nel database, crypt ing il nome utente indicato con il sale per quel nome utente e confrontarlo con il nome utente memorizzato (hash) per vedere se corrisponde. Youch!

Supponi di aver preso alcune buone precauzioni e hai usato un bel hash lento come bcrypt invece della buona vecchia critto Unix? Double youch!

Come puoi immaginare, ci sono alcuni seri svantaggi nell'archiviazione di un nome utente con hash salato invece di solo testo in chiaro.

Penso che la ragione più probabile sia che l'hashing dei nomi utente insieme alla password non fornisce alcuna protezione aggiuntiva.

Incoraggiamo gli utenti a creare password difficili e complesse, rendendole più difficili da decifrare. Qualsiasi database di nomi utente con hash potrebbe essere violato in pochi minuti con un dizionario di base ... a meno che tu non richieda che i tuoi nomi utente contengano almeno 6 caratteri alfanumerici;)

Se hai hashed e salato il nome utente, in che modo il sistema saprebbe che i nuovi account hanno un nome utente univoco, senza scorrere tutti i record esistenti e hashing il nuovo nome utente con ogni singolo salt esistente?

La tua idea è nobile e la domanda interessante. Ora, credo che o non abbia pensato all'utilizzabilità mentre ha sollevato la domanda o hai perso il punto di hashing (o forse tu ho appena scritto "crittografia" errata).

L'hashing è irreversibile, a meno che tu non abbia dei supercomputer che fanno brute force o rainbow tables per cercare la ricerca di hash. Quindi l'usabilità andrebbe in discesa se si dovessero hash i nomi utente / e-mail utilizzati per i login. Se, tuttavia, si dovesse "cifrare" lo stesso usando una chiave predefinita nel programma (quella che controlla il nome utente), allora potrebbe essere un po 'sicuro. Tuttavia, ancora una volta - una chiave di crittografia memorizzata direttamente in un programma è altrettanto valida di nessun tasto. Questi sono i motivi principali per cui i nomi utente non sono hash o crittografati.

Questa idea rientra in linea con due tattiche: 1) Sicurezza per oscurità, 2) Mitigazione extra degli attacchi temporali (se si utilizza una funzione di confronto sicuro temporizzazione). Non è possibile utilizzare un sale unico per farlo in modo efficace, ma è una buona idea. Ciò consentirebbe di separare la tabella che contiene le informazioni di accesso da quella che contiene le informazioni sulla "persona". Due tabelle quindi, persona (potrebbe contenere indirizzi e-mail di testo normale) e utente (potrebbe contenere un nome utente con hash {sito salato} e una password con hash e password salata univoca). Cercare l'utente con il nome utente hash non è un problema.

Penso che questa sia un'ottima idea. Come espresso da Anthony Rutledge; questo può fornire sicurezza attraverso l'oscuramento / offuscamento e se si utilizza una funzione di derivazione della chiave, come PBKDF2, c'è, presumo, una maggiore difficoltà, in ordini di grandezza, per un potenziale aggressore che tenta di compromettere un database rubato.

Ad esempio, un attacco di forza bruta non in linea tentato su un database rubato richiederebbe la ricerca di collisioni hash per nome utente e password, nonostante il fatto che la salatura del nome utente nel metodo, come accennato in precedenza, renderebbe identificato qualsiasi nome utente collisioni moot.

Ciò significa che gli aggressori dovrebbero requisire la tua macchina e anche identificare e comprendere il tuo codice sorgente, dal momento che il sale non esisterebbe da nessuna parte all'interno del tuo database. Aggiunge livelli multipli di difesa aggiuntiva, senza aggiungere molto, se non addirittura alcuno, aumento significativo del carico computazionale per l'applicazione Web.

Riguardo ai problemi con l'hashing: il nome utente può essere salato con un hash proprietario sul lato server, in base al nome utente / email effettivo.

Ciò significherebbe che il sale è noto, anche se a livello di programmazione. E lo script che calcola e restituisce il sale può risiedere sulla macchina in un modo fuori banda, relativo al servizio Web - in modo tale che qualsiasi metodo per generare il sale potrebbe essere inaccessibile da qualsiasi punto di ingresso diretto al Web.