Vedi quella cosa lassù dove mostra il tuo nome utente? Non possono farlo se il nome utente è archiviato con hash ora, vero?

Una parola, usabilità.

Anche se quello che sta dicendo Terry è vero, a volte i sistemi di login hanno effettivamente l'hash del nome utente (ma senza salt). Ti fanno scegliere un nome di accesso e un nome visualizzato. Il nome di accesso viene memorizzato con hash (senza sale perché è necessario essere in grado di cercarlo) e la password è 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 allegarlo al tuo accesso nome. Anche se dico che può essere salato, in realtà non ce n'è bisogno. La parte più importante è solo tenerlo segreto. Se il database viene compromesso, elementi come il tuo indirizzo e-mail o il tuo nome saranno ancora a disposizione dell'autore dell'attacco se desidera organizzare nuovi attacchi sugli altri tuoi account.

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 capitasse di avere una collisione. Puoi ancora aggirare questo problema esaminando tutti i nomi utente corrispondenti per un hash della password che corrisponda, ma è un po 'complicato.

Realisticamente, se hai una buona sicurezza della password e limiti ai tentativi di accesso, un elenco completo dei nomi utente offre poco valore pratico a un utente malintenzionato. Il vantaggio principale sarebbe il phishing, ma se la tua corrispondenza ufficiale contiene informazioni, tali informazioni non possono essere sottoposte ad hashing e le otterrebbero comunque se compromettessero il tuo database.

Inoltre, usabilità come Ha detto Terry. È molto più facile trovare il tuo account se possono vedere i nomi utente. Non si guadagna abbastanza cercando di proteggere un identificatore per giustificarlo nella maggior parte dei contesti.

Mentre altri hanno ben sottolineato che ci sono pochi (se del caso) vantaggi, vorrei contestare la tua affermazione secondo cui non ci sono svantaggi. Se memorizzi solo il nome utente con hash, la ricerca del nome utente è facile. Se si memorizza un nome utente salato e con hash, la ricerca diventa un po 'più problematica.

Supponiamo che se creiamo una tabella SQL contenente nomi utente e password (con hash) e diciamo al server SQL di indicizzare la colonna del nome utente che farà una sorta di ricerca binaria o qualche altra magia. Potremmo avere una tabella che assomiglia a:

  Username | Passwordtest | j9lnvqjAuhNJs  

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

Se memorizzi i tuoi nomi utente in testo normale, recuperando il ( hash) per un utente è una semplice chiamata SQL. Supponiamo che tu voglia convalidare le credenziali di un utente che ha digitato il nome utente test:

  SELEZIONA la password DAGLI utenti WHERE username = 'test`;  

Abbastanza semplice. Ora, se dovessimo memorizzare i nomi utente nello stesso formato delle password, la nostra tabella finirebbe per avere questo aspetto:

  Nome utente | PasswordM1CAtvzDdJDGU | j9lnvqjAuhNJs  

Ora, quando un utente digita il proprio nome utente di test , come convalidi 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 iterare su ogni nome utente nel database, crypt inserendo il nome utente fornito con il salt per quel nome utente e confrontandolo con il nome utente memorizzato (con hash) per vedere se corrisponde. Youch!

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

Come puoi immaginare, ci sono alcuni seri inconvenienti nell'archiviare un nome utente con hash salato invece del semplice testo.

Se hai sottoposto ad hashing e salato il nome utente, come potrebbe il sistema sapere che i nuovi account hanno un nome utente univoco, senza iterare tutti i record esistenti e l'hashing del nuovo nome utente con ogni singolo salt esistente?

La tua idea è nobile e la domanda interessante. Ora, credo che o non pensavi affatto all'usabilità mentre sollevavi la domanda o ti sei perso il punto dell ' hashing (o forse tu solo errore di ortografia "crittografia").

L'hashing è irreversibile, a meno che tu non abbia supercomputer per le cose a forza bruta o tabelle arcobaleno per provare a cercare hash. Quindi l'usabilità andrebbe in discesa se si dovessero eseguire l'hash dei nomi utente / e-mail utilizzati per gli accessi. Se, tuttavia, si dovesse "crittografare" lo stesso utilizzando una chiave predefinita nel programma stesso (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 quanto nessuna chiave. Questi sono i motivi principali per cui i nomi utente non sono sottoposti ad hashing o crittografati.

Penso che la ragione più probabile sia che l'hashing dei nomi utente insieme alla password in realtà 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 abbiano almeno 6 caratteri alfanumerici;)

Questa idea è in linea con due tattiche: 1) Protezione dall'oscurità, 2) Ulteriore mitigazione degli attacchi temporali (se si utilizza una funzione di confronto sicuro del tempo). Non puoi usare 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 in testo semplice) e utente (potrebbe contenere un nome utente con hash {site wide salted} e una password con hash e univocamente salted). Cercare l'utente in base al nome utente con hash non è un problema.

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

Ad esempio, un attacco di forza bruta offline tentato su un database rubato richiederebbe la ricerca di collisioni hash sia per nome utente che per password, nonostante il fatto che il salting del nome utente nel metodo, come ho menzionato sopra, renderebbe discutibile qualsiasi collisione di nome utente identificato.

Ciò significa che gli aggressori dovrebbero requisire la tua macchina e anche identificare e comprendere il tuo codice sorgente, poiché il sale non esisterebbe da nessuna parte nel tuo database. Aggiunge più livelli di difesa aggiuntiva, senza aggiungere molto - se del caso - aumento significativo del carico di calcolo per l'applicazione web.

Per quanto riguarda i problemi con l'hashing: il nome utente può essere salato con un lato server proprietario hash, in base al nome utente / email effettivo.

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