it-swarm.dev

Perché le persone non cancellano e salano i nomi utente prima di memorizzarli

Tutti sanno che se hanno un sistema che richiede una password per accedere, dovrebbero archiviare una copia con hash e salata della password richiesta, piuttosto che la password in chiaro.

Quello che ho iniziato a chiedermi oggi è perché non memorizzano anche l'ID utente in una password con hash e salata simile?

A me questo sembrerebbe logico perché non vedo alcun inconveniente e se il db fosse compromesso, gli aggressori avrebbero bisogno di "crackare" la password e l'hash del nome utente prima di poter compromettere quell'account. Significherebbe anche che se i nomi utente fossero hash e indirizzi email salati, sarebbero più protetti dall'essere venduti a SPAMmers.

39
Grezzo

Mentre ciò che Terry sta dicendo è vero, a volte i sistemi di login hanno effettivamente il nome utente (ma senza sale). Ti fanno scegliere un nome di accesso e un nome visualizzato. Il nome di accesso viene archiviato con hash (senza sale perché è necessario poterlo cercare) e la password viene salata. Il nome visualizzato è diverso dal nome di accesso (perché anche questo deve 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 è necessario. La parte più importante è solo per tenerlo segreto. Se il database viene compromesso, elementi come il tuo indirizzo e-mail o il tuo nome rimarranno comunque disponibili per l'attaccante se desidera eseguire nuovi attacchi su altri tuoi account.

37
Lucas Kauffman

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

Una sola parola, usabilità.

71
user10211

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 aspetto guardando tutti i nomi utente corrispondenti per un hash password che corrisponda, 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 poco valore pratico a un utente malintenzionato. Il vantaggio principale sarebbe il phishing, ma se la corrispondenza ufficiale contiene delle informazioni, tali informazioni non possono essere codificate e le otterrebbero se compromettessero comunque il DB.

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

15
AJ Henderson

Mentre altri hanno ben sottolineato che ci sono pochi (se presenti) vantaggi, metterei in discussione la tua affermazione che non ci sono svantaggi. Se memorizzi solo il nome utente con hash, la ricerca del nome utente è semplice. Se memorizzi un nome utente con hash salato, la ricerca diventa un po 'più problematica.

Supponiamo che se costruiamo una tabella SQL contenente nomi utente e (hash) password 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 un tavolo che assomiglia a:

Username  |  Password
test      |  j9lnvqjAuhNJs

(Questa è la vecchia scuola unix crypt (3) hash solo per semplicità e brevità.)

Se si memorizzano i nomi utente in testo normale, recuperare la 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`;

Abbastanza semplice. Ora, se dovessimo memorizzare i nomi utente nello stesso formato delle password, la nostra tabella finisce per apparire così:

Username       |  Password
M1CAtvzDdJDGU  |  j9lnvqjAuhNJs

Ora quando un utente digita il suo nome utente di test, come convalidi la password? Una ricerca binaria è inutile qui, poiché non conosci nemmeno il sale che hai usato per memorizzare il nome utente. Invece, devi scorrere su ogni nome utente nel database, crypt mettendo il nome utente specificato con il sale per quel nome utente e confrontandolo con il nome utente memorizzato (con hash) per vedere se corrisponde. Youch!

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

Come puoi immaginare, ci sono alcuni gravi inconvenienti nella memorizzazione di un nome utente con hash salato anziché solo in chiaro.

7
Edward Thomson

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

L'hashing è irreversibile, a meno che non si disponga di supercomputer per forzare le cose o tavoli Rainbow per provare a cercare hash. Quindi l'usabilità andrebbe in discesa se dovessi eseguire l'hashing dei nomi utente/e-mail utilizzati per gli accessi. Se, tuttavia, si dovesse "crittografare" lo stesso usando una chiave predefinita nel programma (quella che controlla lo stesso nome utente), allora potrebbe essere un po 'sicuro. Tuttavia, ancora una volta: una chiave di crittografia memorizzata direttamente in un programma è altrettanto valida come nessuna chiave. Questi sono i motivi principali per cui i nomi utente non sono sottoposti a hash o crittografati.

3
Vaibhav Kaushal

Penso che il motivo più probabile sia che l'hashing dei nomi utente insieme alla password non fornisca in realtà alcuna protezione aggiuntiva.

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

3
devel

Se si esegue l'hashing e la salatura del nome utente, come farebbe il sistema a sapere che i nuovi account avevano un nome utente univoco, senza scorrere tutti i record esistenti e eseguire l'hashing del nuovo nome utente con ogni singolo sale esistente?

3
SilverlightFox

Questa idea è in linea con due tattiche: 1) Sicurezza per oscurità, 2) Mitigazione aggiuntiva degli attacchi di temporizzazione (se si utilizza una funzione di confronto sicuro di temporizzazione). Non puoi usare un sale unico per farlo efficacemente, ma è una buona idea. Ciò consentirebbe di separare la tabella che contiene le informazioni di accesso da quella che contiene le informazioni "persona". Due tabelle quindi, persona (potrebbe contenere indirizzi e-mail di testo semplice) e utente (potrebbe contenere un nome utente con hash {site wide salted} e una password con hash e salata in modo univoco). Cercare l'utente per nome utente con hash non è un problema.

1

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

Ad esempio, un attacco di forza bruta offline tentato su un database rubato richiederebbe di trovare collisioni di hash sia per nome utente che password, nonostante il fatto che il salting del nome utente nel metodo, come ho menzionato sopra, renderebbe discutibili eventuali collisioni di nome utente identificate .

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

Per quanto riguarda i problemi con l'hash: il nome utente può essere salato con un hash proprietario sul lato server, basato sul nome utente/e-mail effettivo.

Ciò significherebbe che il sale è noto, sebbene programmaticamente. 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 accesso rivolto al web.

1
James