È sicuro memorizzare gli hash di password eventualmente non esistenti in un modo meno sicuro?

Se l'elaborazione di un tentativo di accesso fallito, fallita perché il nome di accesso non esiste, comporta un costo minore dalla tua parte di un accesso fallito a causa di una password errata su un nome di accesso esistente, allora l'aggressore potrebbe essere in grado di guardalo: il tuo server risponde più velocemente in quel caso. Pertanto, l'utente malintenzionato sarà comunque in grado di sapere quali sono i nomi di accesso esistenti e quali no, quindi di concentrarsi solo sui nomi di accesso esistenti.

Se si vuole davvero nascondere all'autore dell'attacco se esiste un determinato nome di accesso o meno, è necessario emularlo correttamente: indipendentemente dal fatto che il nome di accesso esista o meno, eseguire una chiamata di bcrypt completa. Anche semplicemente dormire per il giusto ammontare di tempo non sarà sufficiente, perché il tuo server sarà in grado di "elaborare" molte più operazioni di login al secondo quando i nomi di accesso non esistono, quindi quando il login i nomi esistono L'attaccante può ancora notarlo.

Anche se la Tradizione richiede di non rivelare se esiste un determinato nome di accesso o meno nel tuo sistema, direi che l'hashing della password è più importante, quindi devi semplicemente respingere i tentativi sui nomi di accesso non esistenti. Se si desidera nascondere il fatto che un determinato nome di accesso non esiste sul server, è necessario pagare il prezzo di calcolo; ma penso che non valga la pena.

Per quanto riguarda il rilevamento degli attacchi di forza bruta, ciò avviene normalmente con le statistiche sull'origine (l'indirizzo IP del computer client) rispetto a target (il nome di l'utente di destinazione). Se si limita la velocità di accesso a un tentativo al secondo o meno (o qualsiasi altra politica di "lentezza") e per indirizzo IP di origine , si rileveranno la maggior parte degli attacchi di forza bruta, indipendentemente dal fatto che ne colpiscano uno nome di accesso o diversi, esistenti o non esistenti. Questo è un metodo più robusto e copre anche il tuo prossimo passo, vale a dire quando gli aggressori tentano diverse password su molti nomi di accesso diversi (e possono certamente farlo!).

Non registrerei le password dei tentativi di accesso non riusciti in un modo meno sicuro come in testo normale o un semplice hash crittografico non salato. Molti utenti digitano accidentalmente la password per il sito A nel sito B, oppure ottengono la password corretta, ma il nome di accesso è errato. Questa informazione potrebbe essere molto preziosa agli occhi di un utente malintenzionato e sarebbe banale trovare una tabella arcobaleno di password usate di frequente da confrontare con le password provate nel sistema.

Se qualcuno alla fine ottiene l'accesso al tuo database (admin insoddisfatto, SQL injection, backup non protetto) sarà probabilmente in grado di ottenere un elenco di hash non salati associati a varie password che possono essere eseguite su una tabella arcobaleno e quindi provare queste le password prima contro le password bcrypt.

Vorrei tenere traccia del numero di successivi tentativi errati da parte degli indirizzi IP e implementare CAPTCHA e rallentare l'elaborazione. Inoltre, potresti richiedere una sorta di sistema di prova del lavoro per renderlo computazionalmente più difficile per le botnet.

Inoltre non vedo come questo schema funzionerebbe senza aggiungere funzionalità più complicate. Diciamo che un utente ha una password abbastanza comune, e qualche botnet tenta di attaccare molti account con quella password e raggiunge un certo limite. Questo impedirebbe all'utente di accedere con la propria password comune? È accettabile?

Inoltre, questo non impedisce alle botnet distribuite di attaccare tutti gli account nel tuo sistema; significa solo se hanno una lista di migliaia di password per un migliaio di account che vogliono attaccare, dovranno fare qualcosa come la password 1 per l'account 1, la password 2 per l'account 2, ... poi quando sono andati attraverso tutte le 1000 password comuni, prova la password 2 per l'account 1, la password 3 per l'account 2, ... e fai solo un po 'di contabilità alla fine.

Considera che la maggior parte delle password errate sono solo alcune sequenze di battute dall'essere corrette. Se vale la pena conservare le informazioni, vale la pena proteggerle.

Se un cracker sta provando password comuni contro molti account, allora il tuo log darà loro solo il dizionario che hanno già.

D'altra parte, qualcuno che cerca di ricordare una password per il tuo sito senza un gestore di password è 1) destinato a commettere errori, e 2) probabilmente utilizzerà una password comune con alcuni caratteri extra per renderlo unico al tuo sito . Per questo utente, avere hash semplici delle sue password esposte potrebbe essere particolarmente devastante.

A mio parere, la responsabilità di tale divulgazione supera il potenziale beneficio. Se non lo tieni, nessuno può rubarlo da te.

- parte 2: c'è un modo migliore per farlo? Qual è il tuo modello di minaccia specifico? Prenderò un'ipotesi: l'attaccante controlla una rete bot per provare nomi utente e password dai file del dizionario.

Se è pigro e ha lo zombie connesso direttamente, potresti essere in grado di mettere in quarantena / limitare il limite dell'IP del client, prima se provi a provare molti nomi utente diversi. Non hai bisogno della password fallita per farlo: solo il nome utente e l'IP.

Anche se non è pigro, puoi usare il suo dizionario contro di lui. Quando un utente crea una password, esegui un reverse John the Ripper contro di essa e rifiuta qualsiasi corrispondenza. (Agli utenti potrebbe non piacere, ma è un'opportunità per istruirli). Quindi, se vedi una password del dizionario in un tentativo di accesso, saprai che è un malintenzionato e intraprendi le azioni appropriate.

qualcosa di simile a:

create table antizombie (hashedip, hashedusername, timestamp, isdictionarypw );

badnews = seleziona distinto hashedip da antizombie dove count (hashedusername) > 20 o isdictionarypw;

ricorda che solo gli accessi falliti lo fanno in questa tabella e scompaiono dopo un tempo ragionevole.