Domanda:
Perché le persone non eseguono hashing e salt nomi utente prima di archiviarli
Grezzo
2012-12-13 17:48:03 UTC
view on stackexchange narkive permalink

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

Cosa ho iniziato chiedersi oggi è perché non memorizzano anche l'ID utente in una password salata & con hash simile?

A me questo sembrerebbe logico perché non riesco a vedere alcun inconveniente e se il db fosse compromesso, gli aggressori dovrebbero "crackare" la password e l'hash del nome utente prima di poter compromettere l'account. Significherebbe anche che se i nomi utente fossero indirizzi e-mail con hash e salati, sarebbero più protetti dalla vendita agli SPAMmers.

Perché probabilmente dovresti conservare il sale? Cosa succede quando dimentichi il tuo nome utente e / o la password che sarebbe orribile usabilità. C'è una ragione per cui questo non viene fatto.
I nomi utente non servono per l'autenticazione, ma solo per l'identificazione. Trattarli con qualsiasi tipo di protocollo sicuro in mente significa creare problemi: è altrettanto importante identificare ciò che * non * deve essere mantenuto privato quanto identificare cosa * fa *. È importante una chiara distinzione.
"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." * no *, *** non fanno ***. Niente di tutto ciò è ovvio per chi è nuovo nel campo della sicurezza. Anche la differenza tra crittografia e hashing va oltre ciò che alcune persone possono capire.
@zzzzBov OK, forse intendevo "chiunque capisca la sicurezza"
@lynks ma non sarebbe bello se quando un database venisse compromesso, non ricevessero tutti gli indirizzi email degli utenti. Non solo possono SPAM questi indirizzi, ma possono anche bersagliarli con attacchi di phishing specifici del sito
@Ramhound Sono sicuro che hai ragione sul fatto che c'è una ragione per cui questo non viene fatto. Voglio solo sapere perché. Se usassimo un sale a livello di sito per i nomi utente (so che questo significherebbe che sarebbe possibile attaccare tutti gli hash in una sola scansione usando la forza bruta), potresti comunque cercare il nome utente hashing prima di eseguire la query
Per un secondo ho pensato che potesse essere una buona idea, ma quale azienda non ha mai bisogno di inviare un'email ai propri utenti?
in genere, quando si archiviano i dati in un database, i dati non vengono sottoposti a hashing e salati. l'hashing viene eseguito solo quando è necessario (ad esempio per proteggere una password). quale sarebbe la necessità di hashing nomi utente? in altre parole, la premessa della tua domanda è errata ... stai assumendo che dovrebbe esserci un motivo per NON eseguire l'hash dei nomi utente, quando non eseguire l'hashing dei dati è il comportamento predefinito.
La ragione potrebbe essere quella di scoraggiare ulteriormente il tempismo degli attacchi?Poiché il nome utente viene tipicamente eseguito con il confronto delle stringhe, si potrebbe teoricamente dissuadere le persone dal misurare anche i nomi utente (in microsecondi) (che tendono ad essere indirizzi e-mail)?Ad esempio, se qualcuno vuole hackerare nomi utente di indirizzi e-mail 10.000.000 di password indovina ciascuno, l'utilizzo di qualcosa come password_verfify () in PHP per il nome utente potrebbe rendere il tempo restituito degli errori ancora più irregolare, quindi più difficile da analizzare?Le persone vogliono ancora inviare e-mail alla loro comunità, ma questo non significa che l'indirizzo e-mail debba essere in ...
... la tabella utilizzata per l'accesso.
Ma ogni nome utente dovrebbe avere un sale univoco ...
Fondamentalmente, il motivo per cui vedo la maggior parte delle persone che cacca questa idea è "perché non è così che è stato fatto in passato. Inoltre, ecco le ragioni e le ipotesi su cui si basa il passato".Esiste un costo per l'accesso e questa tecnica, indipendentemente dalla visualizzazione, è in media più costosa in termini di calcolo.
Le collisioni sono una possibile, ma probabilmente non data una buona logica di programmazione in termini di quando memorizzare il nome utente con hash.
molti siti (come stackexchange) mostrano i nomi degli utenti al pubblico in cose come commenti e post.allora qual è lo scopo nell'hashing dei nomi utente?
Nove risposte:
#1
+71
user10211
2012-12-13 17:49:37 UTC
view on stackexchange narkive permalink

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à.

Lo snark è forte in questo;)
Benvenuto, 21840c1a3e3db69e01445c8782a99f9b.
Ma potrebbero farlo se avessi un nome di accesso e un nome visualizzato, come fai su Facebook e molti altri servizi. Infatti non accediamo allo stack exchange utilizzando un indirizzo email, ma viene visualizzato un Nickname
@Thomas, sì, mi hai preso.
AilimqkqwiCMT buono!
In realtà potresti. Dopo un accesso riuscito, memorizzare il nome utente non sottoposto ad hashing nella sessione.
... Ma se la sicurezza del nome utente è un problema, non vuoi trasmetterlo da client a server in testo normale. Il doppio hashing è all'ordine del giorno; l'hash sul lato client, quindi invialo al server che esegue nuovamente l'hash. Ora, il resto delle informazioni sull'utente, inclusa una copia del nome utente o del nome visualizzato, potrebbe essere crittografato con un PBKDF basato su tutto o parte dell'hash passato dal client; quindi è sufficiente decrittografarlo dopo aver verificato la password e inserire il nome visualizzato nella sessione per l'utilizzo da parte delle pagine web.
Non sono convinto che il nome utente non possa essere visualizzato solo dal lato client.
@KeithS Non sembra essere eccessivamente complicato per qualcosa che comunque non dovrebbe essere un segreto?
Si è ipotizzato che se il nome utente fosse un indirizzo e-mail, il dumping del DB avrebbe fornito a qualcuno un lungo elenco di indirizzi e-mail validi. Ne consegue che il nome utente in quel caso sarebbe sensibile.
@KeithS Il mio primo pensiero è stato "L'indirizzo e-mail deve comunque essere memorizzato in qualche modo per far funzionare un meccanismo di reimpostazione della password", ma poi mi sono reso conto che poiché detto meccanismo richiede di inserire il tuo indirizzo potresti anche usare il suo hash ... un'idea interessante. Ovviamente allora non sarai in grado di inviare spam ai tuoi utenti con le newsletter
@TobiasKienzler invece di un sistema `` push '' per le newsletter, in cui l'operatore del sito o il produttore di contenuti istiga la consegna, potrebbero utilizzare più di un meccanismo di `` pull '', in cui gli utenti si iscrivono a un `` feed '' sia esso RSSish o qualche altro formato / meccanismo .
@JustinC Sarebbe davvero meglio. Vorrei solo che quei produttori di "contenuti" fossero d'accordo ...
Per coloro che erano curiosi, `echo -n" gotcha "| md5` `21840c1a3e3db69e01445c8782a99f9b`
Ecco un'altra parola.Immaginazione.
Questa risposta è chiaramente errata, poiché non esiste una regola che costringa i nomi visualizzati e i nomi utente a essere gli stessi, come altri prima di me hanno sottolineato in precedenza.Per favore, smettila di votare.
#2
+38
Lucas Kauffman
2012-12-13 18:33:25 UTC
view on stackexchange narkive permalink

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.

Sì, l'ho visto fare. È più un meccanismo di oscurità in realtà, perché se la password è fortemente hash, non dovrebbe essere affatto necessaria.
@Polynomial Potrebbe non essere necessario, ma se i nomi di accesso fossero qualcosa come gli indirizzi e-mail, potrebbe essere un buon modo per cercare di nascondere l'indirizzo e-mail di un utente se il database dovesse essere scaricato, no?
mmm buon punto, puoi anche l'hash dell'email se non prevedi di inviare email ai tuoi utenti. Immagino che la reimpostazione della password via e-mail possa ancora essere eseguita.
@LucasKauffman Immagino che questo sia un buon punto, aiuta essere in grado di inviare email ai tuoi utenti. Questo certamente significherebbe che l'hashing prima di archiviarlo non può essere fatto!
Penso che questa risposta e i suoi commenti siano i migliori per me. Grazie.
"Il nome di registrazione è memorizzato in hash (senza sale perché è necessario essere in grado di cercarlo)" Come lo cercheresti? Tavoli arcobaleno? O mi sta sfuggendo qualcosa?
memorizzare l'hash del nome utente, quando qualcuno effettua il login, l'hash del nome utente e cercarlo nel db per trovare l'hash della password corrispondente.
Non puoi cercare il nome utente se è sottoposto a hashing (questo è per definizione). Puoi solo verificare se il nome utente / password forniti (entrambi con hash, salato o meno) sono presenti nel database e sono correlati tra loro. L'unica cosa che puoi cercare è il nome visualizzato.
-1
@LucasKauffman quale parte del mio commento pensi sia sbagliata? Per favore, approfondisci, forse impareremo tutti qualcosa di nuovo qui. Grazie.
Puoi cercare un nome utente in un database anche se è sottoposto ad hashing. Una volta che l'utente ha introdotto il suo nome utente, devi solo cancellarlo. Una volta eseguito l'hashing, puoi cercarlo nel database. Se si utilizzasse un sale, ciò non sarebbe possibile in quanto è necessario prima cercare il sale, cosa che non sarebbe possibile poiché l'hash che è necessario cercare contiene già il sale.
Sembra che diciamo entrambi la stessa cosa ma usando una terminologia diversa. Quando dico ricerca intendo ottenere il nome utente e visualizzarlo quando intendi semplicemente controllare se è fornito correttamente o meno. Saluti.
Questo non ha molto senso per me. Significa fondamentalmente usare il nome utente come "estensione password". Utilizza invece una password più complessa ed evita campi confusi.
@Grezzo: In realtà, potresti ancora inviare messaggi di posta elettronica agli utenti dopo aver eseguito l'hashing del loro indirizzo di posta elettronica.Richiedi semplicemente che forniscano il loro indirizzo e-mail quando si richiede una reimpostazione della password o altra richiesta, hash quell'e-mail rispetto all'hash memorizzato per confermare la loro identità, quindi inviare la reimpostazione della password o rispondere all'indirizzo e-mail che ti hanno appena fornito.Dal momento che non hai memorizzato la loro e-mail, puoi inviare loro e-mail solo con la loro collaborazione, ma a meno che tu non abbia intenzione di inviarle spam con offerte di vendita, non lo vedo come una cosa negativa.
L'hash di un nome utente impedisce gli exploit dell'enumerazione del sistema di accesso.Fondamentalmente, la maggior parte degli attacchi di forza bruta front-end fallisce se non hanno un nome utente valido con cui iniziare, quindi l'hashing con un salt a livello di sito significa che un attacco riuscito contro il tuo database non enumererà i tuoi account utente.Una persona avrebbe bisogno di hackerare il file system della tua applicazione per ottenere il tuo sale, che spesso è molto più difficile.Se non si esegue l'hashing dei nomi utente, un attacco di enumerazione potrebbe essere seguito da una raffica di controlli front-end per le password deboli contro quei nomi utente.
#3
+15
AJ Henderson
2012-12-13 20:15:05 UTC
view on stackexchange narkive permalink

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.

La ricerca tramite password ha un problema: cosa fare se sono uguali (anche - come resettare)? Se proibisci tale situazione, divulgherai effettivamente la password.
@MaciejPiechotka - Sì, se si verifica una doppia collisione, anche questo è un problema, sebbene le possibilità di una doppia collisione siano piuttosto ridotte. Inoltre, se evitassi una doppia collisione, non riveleresti il ​​nome utente a cui corrispondeva, quindi avresti ancora difficoltà a utilizzare le informazioni, ma è comunque un'osservazione valida che sarebbe dire loro che qualche utente ha una password che si risolverebbe con la loro password, ma le possibilità che un utente malintenzionato riesca a colpire quel caso sono abbastanza remote (crittograficamente sicure).
FWIW se ci fosse una collisione, il secondo utente verrebbe accolto con un messaggio "quel nome utente esiste già" durante il tentativo di registrazione.
@MaciejPiechotka Ecco perché prima cerchi l'identificatore.Ne consegue che se l'identificatore è presente, deve essere associata ad esso solo una password (hash).Se si stesse cercando l'hash di un identificatore di accesso e si utilizza un modo sicuro per effettuare il confronto con un attacco a tempo, come potrebbe far male?
#4
+7
Edward Thomson
2012-12-13 22:30:30 UTC
view on stackexchange narkive permalink

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.

ma se non lo salate, o usate un salt a livello di sito per il nome utente potete usare lo stesso comando di selezione, ma invece di cercare il nome utente in testo normale, potete cercare l'hash di esso. O mi sta sfuggendo qualcosa?
Se usi un sale a livello di sito, potresti anche non salarlo affatto. http://crypto.stackexchange.com/questions/1855/passwords-with-same-salt-what-does-this-mean
Non è vero. È vero che con un sale specifico del sito potrebbero attaccare tutti gli hash contemporaneamente usando la forza bruta, ma senza un sale gli attaccanti potrebbero usare una tavola arcobaleno non salata che sarebbe molto meno impegnativa. E dopotutto, la sicurezza non sta nel fare troppi sforzi per attaccare, non nel renderlo davvero impossibile?
Se presumi che il mio indirizzo email esista in qualche tabella arcobaleno di `bcrypt` non salato da qualche parte, allora sì, hai ragione.
Questo è un punto giusto, suppongo. Dubito che il mio indirizzo e-mail sia in qualsiasi tabella arcobaleno in quanto è un numero piuttosto elevato di caratteri. Immagino sia probabilmente vero per la maggior parte delle persone, compresa la tua. Detto questo, devono esserci tonnellate di indirizzi email che sono [a-zA-z0-9] {8} @hotmail.com. Ciò non richiederebbe un enorme tavolo arcobaleno, anche se non ho idea (e dubbio) se qualcuno ne abbia mai fatto uno così
Mi piace questo post.Vorrei che più persone parlassero delle minacce che ostacolano l'hashing del nome utente.Senza utilizzare un metodo di confronto sicuro per gli attacchi a tempo, l'hashing del nome utente è un guadagno a somma zero.
#5
+4
SilverlightFox
2012-12-14 15:15:48 UTC
view on stackexchange narkive permalink

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?

Forse usando un sale a livello di sito (o pepe come penso sia noto)
#6
+3
Vaibhav Kaushal
2012-12-13 23:19:15 UTC
view on stackexchange narkive permalink

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.

Intendevo sicuramente hashing, non crittografarlo. Se abbiamo anche un nome visualizzato, non c'è alcun sacrificio per l'usabilità, vero?
@Grezzo - Se hai un nome visualizzato memorizzato separatamente, la maggior parte delle persone renderà il nome visualizzato molto simile al nome utente. Se generi il loro nome utente, riduce l'usabilità.
Cerchiamo di [continuare questa discussione in chat] (http://chat.stackexchange.com/rooms/52884/discussion-between-aj-henderson-and-anthony-rutledge).
#7
+3
devel
2012-12-14 04:38:00 UTC
view on stackexchange narkive permalink

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;)

Darebbe una piccola quantità di protezione extra, ma certamente non molto. Tuttavia, potrebbe dare il vantaggio di nascondere i nomi utente degli utenti, che probabilmente sono indirizzi e-mail che potrebbero essere utilizzati per attacchi di phishing mirati.
#8
+1
Anthony Rutledge
2017-02-01 19:37:22 UTC
view on stackexchange narkive permalink

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.

#9
+1
James
2018-08-12 21:22:11 UTC
view on stackexchange narkive permalink

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.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...