Perché è ancora necessario bloccare gli attacchi a forza bruta quando la verifica dell'hash delle password richiede un lavoro significativo?

Question

Perché è ancora necessario bloccare gli attacchi a forza bruta quando la verifica dell'hash delle password richiede un lavoro significativo?

#1 da (5 voti)
#2 da (0 voti)

2

Per i controlli di autenticazione, Owasp fornisce consigli per prevenire attacchi brute-force da blocco dell'account e vedo questo tipo di consigli in diversi punti (blocco per IP di origine dopo accessi non riusciti, blocco per account ...).

Perché?

Voglio dire, due casi qui:

o archiviate in modo sicuro le vostre password nel database con costose verifiche (bcrypt, argon2, ...): in questo caso, le vostre password dovrebbero resistere all'attacco offline, quando l'utente malintenzionato ha accesso diretto in lettura al Banca dati. E penso che lo faranno: se la verifica della password prende sul lato server ~ 0.05s con un hardware decente e imponi una lunghezza della password di 7 caratteri E proibisci la password comune (inclusa in una lista potenzialmente grande), ci vorranno mediamente 0.05 * 62^7 / (2*3600*24*365) = 2 800 years per decrittografare ogni password (supponendo che gli utenti abbiano scelto password di 7 caratteri in [a-zA-Z0-7] ). A meno che il tuo modello di minaccia non implichi una potenza di calcolo davvero grande, lo trovo abbastanza. E l'attacco online (forza bruta che utilizza il modulo di accesso) è più lento dell'attacco offline: è ancora necessario bloccare l'attaccante se i suoi tentativi di forza bruta sono destinati a fallire per un periodo piuttosto lungo? E sì, il tentativo di forza bruta sarà una sorta di (D) DoS, ma questo deve essere mitigato da tecniche anti- (D) Dos generali che non sono specifiche per i moduli di accesso.
o non memorizzi la tua password in modo sicuro (hash veloci, niente sale, niente hash ...): questo è un problema e dovresti prima considerare in modo sicuro la memorizzazione delle password. E se non puoi (eredità del software ...), semplicemente aggiungendo un ritardo di 200 ms ad ogni verifica della password si ottiene una protezione simile nel modulo di login (ma non nel caso di perdite di database / attacchi offline), ed è molto più semplice da implementare.

In nessuna di queste 2 alternative vedo bloccare i tentativi di forza bruta come una buona soluzione. Aggiunge complessità e potenzialmente crea vulnerabilità DoS.

authentication passwords brute-force

posta SamuelBF 09.11.2018 - 13:12

fonte

2 risposte

0

L'hash è ragionevolmente veloce, quindi è perfettamente fattibile hash poche migliaia di password al secondo. Naturalmente, ci sono gli hash progettati per essere seriamente lenti e gli hash progettati per essere sicuri ed efficienti. Tuttavia, se si sceglie un hash troppo lento e si hanno molti utenti, è possibile che si verifichino dei tentativi di accesso legittimi perché il server non è in grado di gestire il carico.

simply adding a 200ms delay to each password verification achieves a similar protection in the login form

Sì, ma un ritardo è solitamente un sonno, il che significa che il processo di esecuzione (o fibra) viene bloccato per 200ms e se si fanno mille richieste di forza bruta al secondo, si avranno migliaia di processi in sospeso o mille fibre appese - nessuna delle quali è l'ideale. Inoltre, un ritardo non fa praticamente nulla contro le richieste di forza bruta poiché le richieste si verificano in parallelo. Se riesco a testare 1000 password, non mi interessa il ritardo di 200 ms perché ritarderà la prima risposta. Se lanci un migliaio di rocce giù da un dirupo e loro prendono 200ms per colpire il terreno che 200ms non limita la quantità di rocce che puoi lanciare - aumenta il ritardo fino a che la prima roccia non tocca il suolo.

risposta data 10.11.2018 - 11:33

fonte

Leggi altre domande sui tag authentication passwords brute-force

In che modo le shell inverse persistenti e altri malware acquisiscono persistenza? Ho trovato un indirizzo ipv4 sconosciuto sul mio router

score 5 · Accepted Answer

L'archiviazione sicura delle password da sola non aiuta a forzare le password banali. Se tutto ciò che l'utente malintenzionato deve fare è provare 100 password per accedere all'account utente, quindi la verifica lenta della password non è un problema reale. A parte questo, la verifica della password non può essere troppo lenta perché altrimenti è possibile creare un DOS sul sistema semplicemente tentando di accedere.

Per quanto riguarda il tuo esempio: se la verifica della password richiede 0,05 secondi, il sistema può solo verificare l'accesso di 20 utenti in un singolo secondo. Per molti casi d'uso questo è troppo lento. D'altra parte l'attaccante ha bisogno solo di 5 secondi per forzare 100 password e allo stesso tempo rende il sistema inutilizzabile per gli altri (cioè DOS).

Se invece la verifica della password richiede solo 0,01 secondi ma c'è un limite di soli 3 tentativi in 30 secondi per un singolo account utente, l'hacker avrebbe bisogno di 1000 secondi per provare 100 password e allo stesso tempo il sistema può gestire altri utenti senza problemi.

A parte questo, l'hashing della password comune non ha lo scopo di gestire attacchi di forza bruta contro un singolo account. La complessità di salatura e hashing è invece intesa a rendere impossibile la decifrazione delle password in massa.