Se correttamente hash (cioè con salt casuale e hash forte) una password con hash non è reversibile e le password con hash per account diversi differiscono anche se le password sono le stesse.

Ciò significa che quasi nessuna delle analisi che vuoi fare può essere eseguita con le password correttamente hash (cioè random salt) in primo luogo, cioè non guadagni quasi nulla dalla registrazione delle password e al massimo perdi dal momento che trapeli alcune informazioni in luoghi in cui un utente malintenzionato potrebbe ottenere un accesso più facile poiché i registri di solito non sono considerati sensibili come le password memorizzate.

Quando si utilizza invece un hash semplice (senza sale) alcune delle cose che si menzionano sono possibile al costo di un vettore di attacco aumentato poiché ora un utente malintenzionato può utilizzare tabelle hash precalcolate per invertire le password registrate.

Forse hai qualche idea sbagliata su cosa significhi l'hashing corretto della password. Ti consiglio di leggere Come eseguire l'hashing sicuro delle password? per avere un'idea di come viene eseguito correttamente l'hashing delle password e perché è fatto in questo modo, ma di seguito affronterò alcune delle idee sbagliate che sembri avere:

Controlla se è solo un errore di battitura: se un utente spesso fallisce il login la prima volta con la stessa password con hash ma successivamente accede con successo, allora forse è solo un errore di battitura

Non è possibile controllare un errore di battitura utilizzando le password con hash poiché anche un piccolo cambiamento sull'input si traduce in un enorme cambiamento nell'output. Inoltre, non è possibile controllare l'errore di battitura nelle password originali poiché non è possibile invertire l'hash per ottenere la password per il confronto. Per verificare se la password errata inserita è sempre la stessa, è possibile registrare l'hash salato con lo stesso sale della password memorizzata (corretta) come suggerito da Jon Bentley in un commento. Se i log sono protetti almeno quanto le password memorizzate, ciò aumenterebbe solo leggermente la superficie di attacco, ma come ho detto i log non sono comunemente considerati sensibili come l'archiviazione delle password.

... Alcune password comuni, proprio come 123456 e birthday, che ha un hash fisso, ...

L'hashing corretto della password usa un salt casuale per effettuare attacchi usando hash precalcolati con password comuni impossibile. Ciò significa che la stessa password risulta in un hash diverso quando viene sottoposto a hash, ovvero la tua supposizione che queste password abbiano un hash fisso è sbagliata. Ancora una volta, potresti utilizzare il metodo più semplice per invertire gli hash non salati qui al costo di una maggiore superficie di attacco.

Potrebbe invece essere meglio fare questo tipo di analisi quando la password inserita è ancora disponibile e solo log il risultato di questa analisi.

... se un utente di solito non è riuscito ad accedere con lo stesso hash e l'hash è lo stesso di un altro account ma poi effettua il login con successo, ...

Poiché gli hash per la stessa password differiscono, è necessaria la password inserita originariamente per fare questo tipo di confronto. Dal momento che non è possibile recuperarlo dall'hash registrato, non aiuta avere la password con hash registrata. Ancora una volta, potresti fare questo tipo di analisi con hash non salati, ma ciò significherebbe che tutti i tuoi account devono avere la loro password disponibile in modo non sicuro e non salato, il che è un grande aumento della superficie di attacco. Probabilmente potresti fare questo tipo di analisi anche con password salate, ma poi dovresti registrare le password appena inserite con hash salt con tutti i sali che hai attualmente in uso (cioè uno per ogni account).

Questa non è una pratica comune e va contro la sicurezza in generale. IMHO, nessuno dei motivi che elenchi è abbastanza buono per registrare le password con hash. In effetti, non riesco a pensare a una buona ragione per registrarli. Potresti incorrere in problemi di conformità / legislazione (PCI per esempio). Gli utenti tipicamente falliscono le password per errori di battitura, dimenticando quale password hanno usato per quale sito, ecc. Inoltre, queste password saranno disponibili in un luogo diverso dal database, anche un server remoto se si utilizza una sorta di registrazione tramite syslog.

Nessuno di questi è motivo per registrare le password con hash. Per rispondere direttamente alla tua domanda, è "meglio" registrare le password con hash rispetto a quelle in chiaro, ma entrambe sono pessime e non dovrebbero essere eseguite.

Esempio: parte di HIPPA si concentra sulla necessità di proteggere efficacemente le informazioni sanitarie protette elettroniche (ePHI) aderendo a buone pratiche e standard. Secondo l'auditor con cui lavoro, registrare le password (con hash o altro) ti lascerebbe incompleto perché non è una pratica raccomandata e standard.

Stai facendo molte ipotesi su:

• L'utilità di queste azioni.
• L'hashing e la memorizzazione delle password sono l'unico modo per ottenere tali azioni.
• Anche se alcune di queste azioni possono essere raccolte da una password correttamente salata e con hash.

Se un utente fallisce un login, potrebbe essere per molte ragioni. Ad esempio, potrebbe essere perché hanno più password e le stanno scorrendo, chiedendosi quale hanno usato sul sito ... ora sei passato dalla memorizzazione di un hash (salato) della password degli utenti per quel sito a potenzialmente più (salato ) password con hash che l'utente tende a utilizzare. Allo stesso modo con le e-mail, ho più e-mail che uso, potrei non ricordare quale ho usato per il sito. Ora stai archiviando le mie e-mail per correlarle (questa parte dipende dalla tua correlazione tra password e logica utente). Fondamentalmente stai facendo un compendio di nomi utente / email e combinazioni di password per un potenziale futuro avversario del tuo sito. Alcune delle tue idee:

"Controlla se è solo un errore di battitura"

Perché ti interessi? Se si tratta di un errore di battitura, l'utente ha fatto un errore di battitura e lo ha capito. Se il tuo obiettivo è sviluppare l'impronta digitale per comunicare a un aggressore la forza bruta, ci sono altri modi. Anche questo non è possibile con una password correttamente salata e con hash. Questo è l'obiettivo stesso del salting e dell'hashing, tu stesso non dovresti essere in grado di decodificare ciò che il testo in chiaro originale era senza uno sforzo considerevole. Se non hai il testo in chiaro e l'algoritmo di hashing è buono, non sarai in grado di capire se è stato fatto un errore di battitura.

"Controlla se c'è qualcuno che sta cercando di indovinare la password"

Per prima cosa, assicurati che gli utenti effettivi non abbiano queste password. In secondo luogo, ci sono altri metodi. Terzo, se lo desideri davvero, puoi eseguire l'hashing dell'input e confrontarlo con gli hash di password deboli note, in tal caso, quindi registrare che corrisponda, non è necessario registrare la password in alcuna forma.

"Controlla se un utente ha un account alternativo"

A meno che tu non abbia una ragione esplicita per farlo, qualcosa che va contro i tuoi termini, questo non è necessario dal punto di vista dell'utente. Inoltre, una password correttamente salata e con hash non sarà immediatamente paragonabile ad altri record nel tuo sistema. Questo è il punto del salting, quindi gli hash precalcolati di vari input di testo normale non possono essere abbinati. Pertanto, se qualcuno avesse la stessa password su due account diversi, quell'hash dalla nozione che il sale aggiunto a loro è casuale, non corrisponderà a prescindere. Anche se corrispondessero, potrebbe essere un utente completamente diverso con la stessa password o una password con un carattere di differenza (errore di battitura o variazione della password).

L'idea stessa viola praticamente ogni nozione di sicurezza che esistere. Non lo consiglierei.

La risposta di Steffen è perfetta, ma penso sia importante sapere che hai altre opzioni senza registrare le password con hash. Le mie risposte presumono che tu stia gestendo un sito web esterno con un accesso. Se è interno, puoi memorizzare praticamente tutto ciò che riguarda il computer / dispositivo su cui ha effettuato l'accesso.

Controlla se è solo un errore di battitura: se un utente spesso non riesce ad accedere la prima volta con lo stesso hash password ma in seguito accede con successo, quindi è possibile che sia solo un errore di battitura

Effettua il login quando un utente fallisce e riesce. Puoi eseguire rapporti e vedere se un utente spesso fallisce il primo accesso.

Controlla se c'è qualcuno che sta cercando di indovinare la password: alcune password comuni, proprio come 123456 e compleanno, che ha hash corretto, se questi tentativi esistono, il login fallito può essere fatto da chi cerca la password.

Registra gli indirizzi IP dei tentativi di login. Sebbene questa sia una pratica comune, dovrai assicurarti di farlo in modo legale nei luoghi in cui operi. Molti siti richiedono informazioni aggiuntive se accedi in un luogo sconosciuto.

Controlla se un utente ha un account alternativo: alcuni utenti potrebbero avere un account alternativo ma con password diverse, se un utente solitamente non è riuscito ad accedere con lo stesso hash e l'hash è lo stesso di un altro account ma poi effettua il login con successo, quindi potrebbe essere un utente che sta tentando di accedere con un account alternativo ma ha dimenticato di cambiare la password.

Questo sembra come una combinazione delle altre due risposte.

Puoi ottenere ciò che desideri senza dover registrare la password. Ma è anche importante chiedersi "perché?" Perché questi controlli? Cosa farai realisticamente con queste informazioni? Possono essere realizzati con mezzi passivi?

Controlla se è solo un errore di battitura: se un utente spesso fallisce il login la prima volta con la stessa password con hash ma in seguito accede con successo, allora è possibile solo un errore di battitura

Controlla se qualcuno sta cercando di indovinare la password: alcune password comuni, proprio come 123456 e birthday, che ha un hash corretto, se questi tentativi esistono, il login fallito può essere fatto da chi cerca la password.

La registrazione dell'account, del timestamp, dell'IP e se sono riusciti è sufficiente. Puoi dedurre molto da queste informazioni.

Se vedi uno schema di fallire, fallire, fallire, passare in rapida successione per lo stesso account, probabilmente è stato un errore di battitura. Se vedi un gran numero di fallimenti di seguito e molto rapidamente, è probabile che si tratti di un attacco a quell'account.

Ma un aggressore intelligente giocherà al gioco dei numeri e distribuirà i suoi attacchi su più account. Se l'aggressore non ha informazioni sui tuoi account, è probabile che qualsiasi ipotesi sulla password funzioni su qualsiasi account. Se hanno 100 password da provare, non importa se le provano tutte su 1 account o le distribuiscono su 100 account, le probabilità sono le stesse.

Allo stesso modo potrebbero utilizzare più indirizzi IP. Se vedi un gruppo di quasi tutti i guasti da molti account ma un singolo IP potrebbe essere un attacco distribuito o potrebbe essere un gruppo di utenti reali dietro lo stesso NAT o VPN. È difficile da dire.

Realisticamente c'è un modo molto più semplice. Questi attacchi sono resi più costosi dalla limitazione della velocità e dai soft lockout. Indovinare una password si basa sulla capacità di eseguire molti tentativi di accesso molto rapidamente. Gli accessi dovrebbero già essere limitati in base all'account, non c'è motivo per cui un utente reale tenterà di accedere più volte al secondo. Scegli il limite di frequenza più alto possibile che non è ancora visibile ai tuoi utenti. Questo sventerà i tentativi di accesso automatizzati a fuoco rapido. Se ci sono comunque tentativi persistenti, aumenta automaticamente ed esponenzialmente il limite di velocità per quell'account (e possibilmente IP), riducilo una volta che i presunti sondaggi si sono attenuati.

Inoltre, puoi fornire un buon feedback sulla sicurezza della password quando gli utenti stanno creando i loro account per evitare password facilmente indovinate.

In questo modo puoi sventare sonde automatiche a scatto rapido senza infastidire gli utenti legittimi che hanno solo difficoltà a digitare oggi.

Controlla se un utente ha un account alternativo: alcuni utenti potrebbero avere un account alternativo ma con password diverse, se un utente di solito non è riuscito ad accedere con lo stesso hash e l'hash è lo stesso di un altro account ma poi effettua il login con successo, allora potrebbe essere un utente che tenta di accedere con un account alternativo ma si è dimenticato di cambiare la password.

Questo sembra più un requisito aziendale che un problema di sicurezza. Stai essenzialmente cercando di rilevare la persona unica dietro un account, ed è abbastanza difficile da capire: Internet non vuole che tu abbia quelle informazioni. Il costo per farlo bene è alto e man mano che ottieni sempre più utenti è sempre più probabile che si verifichino molti falsi positivi che infastidiscono i tuoi utenti reali.

A meno che non sia la tua attività, se lo sei una società di data mining per esempio, considera perché hai questo requisito: qual è il suo reale effetto sul tuo sistema? Quali metriche hai per supportarlo?

Se decidi di dover davvero prevenire gli alt, utilizza vari ID semiunivoci del mondo reale per aggiungere un costo agli account alt e ridurne la frequenza. L'indirizzo e-mail è il più comune. Fare conti costare denaro o richiedere un numero di carta di credito è un altro. Anche i numeri di identificazione fiscale se sei un sito di grandi aziende. Tutto dipende da cosa stai facendo.

È questa una pratica comune, certamente no ; è una buona pratica, probabilmente no . Comunque l'ho visto una volta, e per avere una discussione completa sull'argomento desidero andare controcorrente qui e dire per cosa può essere utile, e quali precauzioni sono state prese per evitare i problemi rilevati da altri.

In un contesto di incessanti attacchi esterni ad accessi ben noti, utilizzando la forza bruta, attacchi a dizionario, attacchi con una sola password, qualsiasi utente, spearphishing e malware che rilevava la password, l'organizzazione aveva gravi problemi con telefoni cellulari, tablet e modifica della password.

Quando la sessione mobile veniva reimpostata a seguito di una modifica della password, i telefoni cellulari in genere provavano il vecchio password diverse volte prima di rinunciare, di solito più di tre (forse posta, calendario, attività o qualcosa del genere), prima di chiedere all'utente una nuova password. Ciò ha bloccato l'account dell'utente a causa di una regola dei tre avvertimenti non negoziabile dal punto di vista amministrativo e tecnico sul back-end di autenticazione.

È assolutamente possibile che questo comportamento dei dispositivi mobili sia stato corretto da allora (sono passati alcuni anni fa), e sarei interessato a sapere se è così.

In breve, gli utenti ricevevano un "cambio di password" sul desktop ogni mese e quelli che non lo facevano immediatamente cambia la password su tutti i loro dispositivi mobili sono stati bloccati su tutti i dispositivi, anche quelli connessi alla rete interna (più) sicura, il che era un problema più grave del "semplice" blocco proveniente da Internet. A volte, immediatamente non era abbastanza, e c'era una procedura con una danza complicata che coinvolgeva la modalità aereo per evitare di essere bloccati. Ovviamente gli utenti che avevano sia un telefono cellulare che un tablet avevano ancora più problemi.

L'organizzazione ha implementato la registrazione della password con hash nel modo seguente:

• inserita come livello tra i l'applicazione e il backend di autenticazione.
• hashing utilizzando PBKDF2.
• un salt da mezzanotte a mezzanotte, un salt da mezzogiorno a mezzogiorno, due hash memorizzati per ogni accesso. Il sale era mantenuto nello strato e non immagazzinato altrove (un riavvio dello strato significava un nuovo sale, e quando il sale veniva rigenerato andava perso, poiché non era immagazzinato nell'hash, come farebbe bcrypt fatto).
• pepe con login (il che significa che password identiche per account diversi non erano rilevabili).
• archiviate in un database specifico (non accessibile all'helpdesk) e (facoltativamente) registrato in un datastore specifico nel formato fallimento (data, utente, IP di origine, hash1, hash2, useragent ...) e successo (data, utente, IP di origine, useragent ...).
• database ha utilizzato un'API che vietava qualsiasi azione non specificatamente elencata qui (ad esempio, elencare gli hash per tutti gli utenti).
• al ricevimento di una richiesta di autenticazione:
  • controlla nel database se una password con il lo stesso hash per quell'utente è stato rifiutato (nelle 24 ore precedenti) e, in tal caso, rifiuta il login senza presentare la richiesta di autenticazione al back-end e registra quel motivo nel file accessibile dell'helpdesk ogs (senza hash).
  • controlla nel database se lo stesso IP di origine ha fallito l'autenticazione per più account utente nelle ultime n ore, senza alcun login riuscito e, in tal caso, rifiuta il login senza presentare la richiesta di autenticazione al backend e registrare tale motivo nei log accessibili all'helpdesk (sempre senza hash).
  • altrimenti, passare la richiesta al backend e registrare / memorizzare il risultato.
• quando la password dell'utente viene modificata, il backend di autenticazione attiva la rimozione di tutti i record per quell'utente dal database (che registra il fatto che la password è stata modificata). Questa era l'unica modifica al backend di autenticazione.
• i record più vecchi di 24 ore sono stati eliminati definitivamente dal database.
• i log erano accessibili solo ai revisori della sicurezza.
• nel caso in cui si accedesse ai log, l'API per accedervi rimuove gli hash, presentando solo i nomi nella forma PASS1, PASS2. . . PASSN al revisore della sicurezza. L'accesso al database grezzo era estremamente limitato, fondamentalmente solo sulla presentazione delle credenziali di uno sviluppatore senior e di un responsabile della sicurezza. Ciò non era proprio per la presenza degli hash, ma per la natura sensibile dei log in generale ed era (è) una procedura standard nell'organizzazione per l'accesso a database non elaborati al di fuori dell'API approvata.
• si è discusso se fosse necessario memorizzare effettivamente il nome utente. Le stesse funzionalità desiderate avrebbero probabilmente potuto essere ottenute senza farlo, e ciò avrebbe evitato un monitoraggio utente non necessario. Alla fine è stato ritenuto importante sapere se un utente malintenzionato prende di mira un utente in modo specifico o ha accesso a un elenco di utenti.
• c'era anche una funzione che registrava utenti inesistenti in modo sicuro (hash) (reso possibile dal backend di autenticazione che restituisce un motivo dettagliato per qualsiasi rifiuto), in modo che anche un agente esterno che prova molti utenti inesistenti venga inserito nella lista nera per un periodo di tempo considerevole.

In In breve, il concetto alla base di questa implementazione era che gli attacchi al dizionario sono un problema, ma ripetuti tentativi della stessa password (sbagliata) non costituiscono un attacco al dizionario .

Questa implementazione:

• ha evitato con successo di bloccare gli utenti quando uno dei loro dispositivi ha provato ripetutamente la stessa password, che era l'obiettivo desiderato ed estremamente urgente
• ha impedito bruto -Forza attacchi mirati a password comuni contro più account, che non era una funzione che il backend di autenticazione co potrebbe fornire
• autenticazione disaccoppiata da Internet dal sistema interno, in modo che gli attacchi da Internet non influiscano sull'accesso dell'utente sulla propria stazione di lavoro
• riduce notevolmente le chiamate all'help desk sul oggetto
• ha ridotto notevolmente le escalation al livello 3 perché il livello 2 ora aveva accesso al motivo dell'autenticazione rifiutata per un determinato account (con lo user-agent ma senza hash).

Per rispondere alla domanda. . . si presentano diversi motivi per registrare gli hash delle password rifiutate, ma come si vede questo esempio concreto della scelta effettiva di registrare gli hash delle password rifiutate non si applica a questi motivi. Personalmente penso che le ragioni che fornite non siano valide.

1. Controlla se è solo un errore di battitura: finché un utente accede effettivamente dopo un numero limitato di tentativi, lo fai non hai problemi. Può essere un errore di battitura o una vecchia password o la password di un altro account, ma dovrebbe interessarti?

2. Controlla se qualcuno sta cercando di indovinare la password: sì, ma lo fai non e non deve essere paragonato agli hash di password note. Se vuoi impedire l'utilizzo di password comuni, dovresti applicare le regole quando l'utente sceglie una password, non in seguito.

3. Controlla se un utente ha un account alternativo: il collegamento degli account può possibilmente essere fatto dall'IP sorgente, ma non credo che sapere che un utente sta provando prima la password di un altro utente prima della propria sia qualcosa che ti aiuterà a prevenire accessi non autorizzati. Se hai qualche motivo pressante e legale per impedire agli utenti di avere più account, faresti meglio a monitorare gli IP di origine, i dispositivi e i tempi di accesso che monitorando gli errori nelle password.

Si sarebbe potuto fare di più identificando il dispositivo mobile, ma la vera soluzione in questo caso era la gestione dei dispositivi mobili e un dispositivo MFA hardware per gli accessi desktop e, una volta stabilizzata la situazione, questa è stata la scelta dell'organizzazione in questione.

Spero che questo aiuti.

Come indicato da diverse risposte in questo post, potrebbe non essere pratico analizzare le password non riuscite con password memorizzate (con hash) per analizzare i casi d'uso come hai indicato a causa di funzionalità di sicurezza avanzate come 'Salting', ecc.

L'unico requisito del mondo reale che posso vedere è, di seguito, dallo standard HIPAA (Health Insurance Portability and Accountability Act) ma non c'è nemmeno insistenza per registrare le password non riuscite ma per registrare / monitorare le altre informazioni come evidenziato di seguito:

Secondo lo standard HIPAA [164.308 (a) (5)] - Procedure per la registrazione dell'attività di accesso inclusi i tentativi di accesso non riusciti

Secondo questa procedura per registrare gli accessi e le disconnessioni che si verificano all'interno dei tuoi sistemi. È necessario tenere traccia dei tentativi di accesso non riusciti, inclusi quelli che utilizzano una password errata e quelli che tentano con un account inesistente. La registrazione dovrebbe includere indirizzo IP, nome di accesso, tipo di errore e nome di sistema non riusciti.

Spero che questo sia utile ...