it-swarm-eu.dev

Quali sono i rischi per la sicurezza della registrazione dell'hash delle password rifiutate?

Secondo È pratica comune registrare password rifiutate? , so che la registrazione di password di testo normale rifiutate è una cattiva idea, ma che ne dite se memorizzo la forma con hash delle password rifiutate? Voglio avere maggiori informazioni sul login fallito per l'analisi, ad esempio:

  1. Verifica se si tratta solo di un errore di battitura: se un utente spesso non riesce ad accedere per la prima volta con la stessa password con hash ma successivamente accede correttamente, allora è probabilmente solo un errore di battitura

  2. Controlla se c'è qualcuno che sta provando a indovinare la password: alcune password comuni, proprio come 123456 e la data di nascita, che ha risolto l'hash, se tali tentativi esistono, il login non riuscito può essere eseguito da chi indovina la password.

  3. Verifica se un utente ha un account alternativo: alcuni utenti potrebbero avere un account alternativo ma con password diverse, se un utente di solito non riesce ad accedere con lo stesso hash e l'hash è lo stesso di un altro account ma quindi effettua l'accesso correttamente, quindi potrebbe essere un utente che sta tentando di accedere con un account alternativo ma ha dimenticato di cambiare la password.

La mia domanda è: la registrazione della forma hash delle password rifiutate ha lo stesso problema della registrazione delle password rifiutate in testo normale?

36
ocomfd

Se con hash corretto (ovvero 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 uguali.

Ciò significa che quasi nessuna delle analisi che si desidera eseguire può essere eseguita in primo luogo con le password correttamente hash (ovvero salt saltuali), ovvero non si ottiene quasi nulla dalla registrazione delle password e al massimo si perde poiché si perde qualche informazione in luoghi dove un utente malintenzionato potrebbe ottenere un accesso più semplice poiché i registri non sono generalmente considerati sensibili come le password memorizzate.

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

Forse hai delle idee sbagliate sul significato dell'hash della password. Ti consiglio di leggere Come hash in modo sicuro le password? per avere un'idea di come viene eseguito l'hashing della password corretto e perché viene fatto in questo modo, ma di seguito affronterò alcune delle idee sbagliate che sembra avere:

Verifica se si tratta solo di un errore di battitura: se un utente spesso non riesce ad accedere per la prima volta con la stessa password con hash ma successivamente accede correttamente, allora è probabilmente solo un errore di battitura

Non è possibile verificare un errore di battitura utilizzando le password con hash poiché anche una piccola modifica sull'input comporta un enorme cambiamento nell'output. Inoltre, non è possibile verificare 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 registri sono protetti almeno quanto le password archiviate, ciò aumenterebbe solo leggermente la superficie di attacco, ma come ho già detto, i registri non sono comunemente considerati sensibili come l'archiviazione delle password.

... Alcune password comuni, proprio come 123456 e compleanni, che ha corretto l'hash, ...

L'hash delle password corretto utilizza un salt casuale per rendere impossibili gli attacchi usando hash pre-calcolati con password comuni. Ciò significa che la stessa password si traduce in un hash diverso quando viene hash, ovvero la tua assunzione di queste password con un hash fisso è errata. Ancora una volta, potresti usare gli hash non salati più facili da invertire qui a costo di una maggiore superficie di attacco.

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

... se un utente di solito non riesce ad accedere con lo stesso hash e l'hash è lo stesso di un altro account ma poi accede correttamente, ...

Poiché gli hash per la stessa password differiscono, per fare questo tipo di confronto è necessaria la password immessa originariamente. Poiché non è possibile recuperarlo dall'hash registrato, non è utile registrare la password con hash. 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 non salato - che è un grande aumento della superficie di attacco. Probabilmente potresti fare questo tipo di analisi anche con password salate, ma dovrai quindi registrare le password appena inserite con hash salt con tutti i sali che hai attualmente in uso (cioè uno per ogni account).

100
Steffen Ullrich

Questa non è una pratica comune e va contro la sicurezza in generale. IMHO, nessuno dei motivi elencati è abbastanza buono per registrare le password con hash. In effetti, non riesco a pensare a una buona ragione per registrarli. Potrebbero verificarsi problemi di conformità/legislazione (ad esempio PCI). Gli utenti in genere falliscono le password per errori di battitura, dimenticando quale password hanno usato per quale sito, ecc. Avrai anche queste password in un posto diverso dal tuo database, anche da un server remoto se stai usando una sorta di registrazione tramite syslog.

Nessuno di questi sono motivi 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 fatte.

Esempio: parte di HIPPA si concentra sulla necessità di proteggere in modo adeguato ed efficace le informazioni sulla salute elettronica protetta (ePHI) aderendo a buone pratiche e standard. Secondo il revisore con cui lavoro, la registrazione delle password (con hash o altro) ti lascerebbe incompleto perché non è una pratica raccomandata e standard.

17
pm1391

Stai facendo molte ipotesi su:

  • L'utilità di queste azioni.
  • L'hash e l'archiviazione delle password sono l'unico modo per raggiungere tali azioni.
  • Anche che alcune di queste azioni possono essere raccolte da una password correttamente salata e con hash.

Se un utente non riesce ad accedere, potrebbe essere per molti motivi. Ad esempio, potrebbe essere perché hanno più password e le stanno scorrendo ciclicamente, chiedendosi quale hanno usato sul sito ... ora sei passato dalla memorizzazione di un hash (salato) della password degli utenti per quel sito a potenzialmente multiplo (salato ) ha eseguito l'hashing delle password 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 memorizzando le mie e-mail per correlarle (questa parte dipende dalla tua correlazione della password con la logica dell'utente). Fondamentalmente stai facendo un compendio di nomi utente/e-mail e combinazioni di password per un potenziale avversario futuro del tuo sito. Alcune delle tue idee:

"Controlla se è solo un errore di battitura"

Perché ti interessi? Se è un refuso, l'utente ha fatto un refuso e l'ha capito. Se il tuo obiettivo è sviluppare l'impronta digitale per dire alla forza bruta di un aggressore, ci sono altri modi. Anche questo non è possibile con una password correttamente salata e con hash. Questo è il vero obiettivo della salatura e dell'hashish, tu stesso non dovresti essere in grado di decodificare quale fosse il testo normale originale senza un notevole sforzo. Se non hai il testo semplice e l'algoritmo di hash è buono, non sarai in grado di dire se è stato fatto un refuso.

"Controlla se c'è qualcuno che sta provando a indovinare la password"

Innanzitutto, assicurati che gli utenti effettivi non abbiano queste password. Secondo, ci sono altri metodi. In terzo luogo, se lo si desidera, è possibile inviare in streaming l'hash dell'input e confrontarlo con hash di password deboli note, in tal caso, quindi registrare che corrisponda, non è necessario registrare la password in qualsiasi forma stessa.

"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 sistema. Questo è il punto della salatura, quindi non è possibile abbinare gli hash pre-calcolati di vari input di testo semplice. Pertanto, se qualcuno avesse la stessa password su due account diversi, quell'hash dall'idea che il sale aggiunto a loro sia casuale, non corrisponderà a prescindere. Anche se corrispondessero, potrebbe trattarsi di un utente completamente diverso con la stessa password o una password con un carattere disattivato (errore di battitura o variazione della password).

L'idea stessa viola praticamente ogni nozione di sicurezza esistente. Non lo raccomanderei.

13

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

Verifica se si tratta solo di un errore di battitura: se un utente spesso non riesce ad accedere per la prima volta con la stessa password con hash ma successivamente accede correttamente, allora è probabilmente solo un errore di battitura

Accedi solo quando un utente fallisce e ha esito positivo. È possibile eseguire report e vedere se un utente non riesce spesso al primo accesso.

Controlla se c'è qualcuno che sta provando a indovinare la password: alcune password comuni, proprio come 123456 e la data di nascita, che ha risolto l'hash, se tali tentativi esistono, il login non riuscito può essere eseguito da chi indovina la password.

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

Verifica se un utente ha un account alternativo: alcuni utenti potrebbero avere un account alternativo ma con password diverse, se un utente di solito non riesce ad accedere con lo stesso hash e l'hash è lo stesso di un altro account ma quindi effettua l'accesso correttamente, quindi potrebbe essere un utente che sta tentando di accedere con un account alternativo ma ha dimenticato di cambiare la password.

Sembra una combinazione delle altre due risposte.

5
MiniRagnarok

È possibile ottenere ciò che si desidera senza la registrazione della password. Ma è anche importante chiedere "perché?" Perché questi controlli? Cosa realisticamente hai intenzione di fare con queste informazioni? Possono essere realizzati con mezzi passivi?

Verifica se si tratta solo di un errore di battitura: se un utente spesso non riesce ad accedere per la prima volta con la stessa password con hash ma successivamente accede correttamente, allora è probabilmente solo un errore di battitura

Controlla se c'è qualcuno che sta provando a indovinare la password: alcune password comuni, proprio come 123456 e la data di nascita, che ha risolto l'hash, se tali tentativi esistono, il login non riuscito può essere eseguito da chi indovina la password.

È sufficiente registrare l'account, il timestamp, l'IP e se hanno avuto successo. Puoi dedurre molto da queste informazioni.

Se vedi un modello di fallimento, fallimento, fallimento, passa in rapida successione per lo stesso account che probabilmente era un errore di battitura. Se vedi molti errori di seguito e molto rapidamente, probabilmente è un attacco a quell'account.

Ma un attaccante intelligente giocherà il gioco dei numeri e distribuirà i loro attacchi su più account. Se l'autore dell'attacco non ha informazioni sui tuoi account, è probabile che una determinata ipotesi di password funzioni su un determinato 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 usare più indirizzi IP. Se vedi un gruppo di quasi tutti gli errori da molti account ma un singolo IP che potrebbe essere un attacco distribuito o potrebbe essere un gruppo di utenti reali dietro lo stesso NAT o VPN. È difficile dire.

Realisticamente c'è un modo molto più semplice. Questi attacchi sono resi più costosi da limite di velocità e blocchi soft. Indovinare una password si basa sulla possibilità di eseguire molti tentativi di accesso molto rapidamente. Gli accessi dovrebbero già essere limitati dalla tariffa in base all'account, non c'è motivo per cui un utente reale tenterà di accedere più volte al secondo. Scegli il limite di tariffa più alto possibile che non è ancora evidente dai tuoi utenti. Ciò ostacolerà i tentativi di accesso automatici a fuoco rapido. Se ci sono comunque tentativi persistenti, aumentare automaticamente ed esponenzialmente il limite di velocità per quell'account (e possibilmente IP), ridurlo una volta che le presunte sonde si placano.

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

In questo modo è possibile sventare le sonde automatiche a fuoco rapido senza fastidiosi utenti legittimi che stanno facendo fatica a digitare oggi.

Verifica se un utente ha un account alternativo: alcuni utenti potrebbero avere un account alternativo ma con password diverse, se un utente di solito non riesce ad accedere con lo stesso hash e l'hash è lo stesso di un altro account ma quindi effettua l'accesso correttamente, quindi potrebbe essere un utente che sta tentando di accedere con un account alternativo ma ha dimenticato di cambiare la password.

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

A meno che non sia la tua attività, ad esempio se sei una società di data mining, considera perché hai questo requisito: qual è il suo reale effetto sul tuo sistema? Di quali metriche devi eseguire il backup?

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

1
Schwern

È questa 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 qui contro il grano e dire ciò per cui può essere utile e quali precauzioni sono state prese per evitare i problemi rilevati da altri.

In un contesto di incessanti attacchi esterni su accessi ben noti, utilizzando la forza bruta, gli attacchi a dizionario, gli attacchi con una sola password per qualsiasi utente, lo spearphishing e il malware che annusa la password, l'organizzazione stava riscontrando gravi problemi con telefoni cellulari, tablet e password modificare.

Quando la sessione mobile è stata reimpostata a seguito di una modifica della password, i telefoni cellulari in genere hanno provato più volte la password prima di arrendersi, di solito più di tre (forse posta, calendario, attività o simili), prima che richiede all'utente una nuova password. Ciò ha bloccato l'account dell'utente a causa di una regola dei tre avvertimenti amministrativa e tecnicamente non negoziabile sul back-end di autenticazione.

È molto probabile che questo comportamento dei dispositivi mobili sia stato corretto da allora (come alcuni anni fa) e sarei interessato a sapere se è così.

In breve, gli utenti hanno ricevuto una "modifica della password" sul desktop ogni mese e coloro che non hanno immediatamente hanno cambiato la password su tutti i loro dispositivi mobili sono stati bloccati su tutti i dispositivi, anche quelli connessi alla (più) rete interna sicura, il che era un problema più grave del "solo" venire bloccato da Internet. A volte, immediatamente non era abbastanza, e c'era una procedura con una danza complicata che prevedeva la modalità aereo per evitare di essere rinchiuso. Gli utenti che hanno sia il telefono cellulare che il tablet ovviamente hanno avuto ancora più problemi.

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

  • inserito come layer tra l'applicazione e il back-end di autenticazione.
  • hash usando PBKDF2.
  • un sale da mezzanotte a mezzanotte, un sale da mezzogiorno a mezzogiorno, due hash memorizzati per ogni accesso. Il sale è stato mantenuto nello strato e non memorizzato in nessun altro posto (un riavvio dello strato significava un nuovo sale e quando il sale è stato rigenerato è andato perso, poiché non è stato memorizzato nell'hash, come avrebbe fatto bcrypt).
  • pepe con login (il che significa che password identiche per account diversi non erano rilevabili).
  • memorizzato in un database specifico (non accessibile all'helpdesk) e (facoltativamente) registrato in un archivio dati specifico nel modulo errore (data, utente, IP di origine, hash1, hash2, useragent ...) e successo (data, utente, fonte IP, useragent...).
  • il database utilizzava un'API che proibiva qualsiasi azione non specificatamente elencata qui (ad esempio, elencando hash per tutti gli utenti).
  • al ricevimento di una richiesta di autenticazione:
    • controlla nel database se una password con lo stesso hash per quell'utente è stata rifiutata (nelle precedenti 24 ore) e, in tal caso, rifiuta l'accesso senza presentare la richiesta di autenticazione al backend e registra tale motivo nell'helpdesk accessibile registri (senza hash).
    • verificare nel database se lo stesso IP di origine non ha superato l'autenticazione per più account utente nelle ultime n ore, senza accessi riusciti, e in tal caso, rifiutare l'accesso senza presentare la richiesta di autenticazione al back-end e registrare tale motivo in i log accessibili dall'helpdesk (ancora senza hash).
    • in caso contrario, passare la richiesta al back-end e registrare/archiviare il risultato.
  • quando la password dell'utente viene modificata, il back-end di autenticazione avvia la rimozione di tutti i record per quell'utente dal database (che registra il fatto che la password è stata modificata). Questa è stata l'unica modifica al back-end di autenticazione.
  • i record più vecchi di 24 ore sono stati espulsi dal database.
  • i registri erano accessibili solo ai revisori della sicurezza.
  • nel caso in cui si accedesse ai log, l'API per accedervi elimina gli hash, presentando solo i nomi nel formato PASS1, PASS2. . . PASSATO al controllore della sicurezza. L'accesso al database non elaborato era estremamente limitato, fondamentalmente solo sulla presentazione delle credenziali di uno sviluppatore senior e di un responsabile della sicurezza. Ciò non era in realtà dovuto alla presenza degli hash, era a causa della natura sensibile dei registri in generale ed era (è) una procedura standard nell'organizzazione per l'accesso a database non elaborati all'esterno dell'API approvata.
  • si è discusso se fosse necessario memorizzare effettivamente il nome utente. Le stesse funzionalità desiderate avrebbero probabilmente potuto essere raggiunte senza farlo, e ciò avrebbe evitato il tracciamento dell'utente non necessario. Alla fine è stato ritenuto importante sapere se un utente malintenzionato sta prendendo di mira specificamente un utente o ha accesso a un elenco di utenti.
  • c'era anche una funzione che registrava utenti inesistenti in modo sicuro (con hash) (reso possibile dal back-end di autenticazione che restituiva un motivo dettagliato per qualsiasi rifiuto), in modo che un agente esterno che provava molti utenti inesistenti fosse anche inserito nella lista nera per alcuni notevole quantità di tempo.

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

Questa implementazione:

  • evitato con successo di bloccare gli utenti quando uno dei loro dispositivi ha ripetutamente provato la stessa password, che era l'obiettivo desiderato ed estremamente urgente
  • impedito attacchi di forza bruta mirati a password comuni contro più account, che non era una funzione che il back-end di autenticazione poteva fornire
  • disaccoppiare l'autenticazione da Internet dal sistema interno, in modo che gli attacchi da Internet non influiscano sull'accesso dell'utente sulla propria workstation
  • ha notevolmente ridotto le chiamate all'help desk in materia
  • ridurre drasticamente le escalation al livello 3 perché il livello 2 ora aveva accesso al motivo dell'autenticazione rifiutata per un determinato account (con l'utente-agente ma senza hash).

Per rispondere alla domanda . . si presentano diversi motivi per la registrazione degli hash delle password rifiutate, ma come si vede questo esempio concreto di scelta effettiva per la registrazione degli hash delle password rifiutate non si applica a tali motivi. Personalmente ritengo che le ragioni fornite non siano valide.

  1. Controlla se si tratta solo di un errore di battitura: finché un utente accede effettivamente dopo un numero limitato di tentativi, non hai problemi. Può essere un refuso o una vecchia password o la password di un altro account, ma dovresti preoccupartene?

  2. Controlla se c'è qualcuno che sta provando a indovinare la password: sì, ma non lo fai e non dovresti confrontarlo con gli hash delle password conosciute. Se si desidera impedire l'utilizzo di password comuni, è necessario applicare le regole quando l'utente sceglie una password, non successivamente.

  3. Verifica se un utente ha un account alternativo: il collegamento degli account può essere effettuato tramite l'IP di origine, ma non credo che sapere che un utente sta provando prima la password di un altro utente prima del proprio è qualcosa che ti aiuterà a prevenire l'accesso non autorizzato. Se hai qualche motivo urgente e legale per impedire agli utenti di avere più account, faresti meglio monitorando 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 qui era la gestione dei dispositivi mobili e un dispositivo MFA hardware per gli accessi desktop e, una volta stabilizzata la situazione, quella era la scelta dell'organizzazione in questione.

Spero che sia di aiuto.

1
Law29

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

Quello che posso vedere è uno dei requisiti del mondo reale, di seguito dallo standard HIPAA (Health Insurance Portability and Accountability Act), ma non c'è insistenza nel registrare le password non riuscite ma nel 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 falliti

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

Spero che questo sia utile ...

0
Sayan