Perché non è diventata la norma per inibire le ipotesi di password ripetute?

Vorrei sfidare la tua ipotesi che questo non sia in corso.

[avviso: approssimazioni selvagge da seguire]

Ricorda che un attacco di forza bruta di successo richiederà milioni o miliardi di supposizioni al secondo per fare il crack in un ragionevole lasso di tempo (ad esempio, un paio d'ore al mese a seconda della forza della tua password). Anche un limite di velocità di 100 tentativi di password al secondo aumenterebbe il tempo di crack da un mese a centinaia di migliaia di anni. Forse i miei standard sono bassi, ma questo è abbastanza buono per me, e nessun utente umano che cerchi legittimamente di entrare nel proprio account lo noterà mai. Ancora meglio se il limite di velocità fosse per IP anziché per nome utente solo per prevenire alcuni tipi di attacchi di tipo Denial of Service.

Inoltre, non so quale distribuzione Linux stai usando, ma sui miei sistemi Ubuntu e CentOS, quando scrivo la mia password sulla schermata di login della GUI o del terminale, si blocca per 1 secondo prima di richiederti .

Anche se il server non sta attivamente limitando i tentativi di accesso (che dovrebbero essere veramente), solo il tempo di ping da solo è sufficiente per rallentare a milioni di anni. Probabilmente sarai DDOS sul server prima di arrivare a circa 1 miliardo di tentativi al secondo. Il vero denaro è ottenere una copia del database delle password hash e inserirla in un rig GPU in cui sono possibili miliardi di ipotesi al secondo.

TL; DR: se hai intenzione di mettere a dura prova il tuo server di login, avrai più soldi per te migliorando l'hashing della password e rendendo il tuo database difficile da rubare di implementando la limitazione della velocità nella schermata di accesso.

UPDATE : da quando è diventato virale, inserirò qualcosa dai commenti:

Questa logica si applica solo ai server di accesso. Per dispositivi fisici come telefoni o computer portatili, una cosa tipo "3 tentativi e si blocca" o "10 tentativi e il dispositivo si asciuga" ha ancora senso perché qualcuno potrebbe navigare mentre stai digitando la tua password, o vedere lo schema sfumato sullo schermo, o sapere che un PIN a 4 cifre ha solo 10.000 combinazioni comunque, quindi il numero di tentativi che devono fare è molto molto molto più piccolo.

C'è un problema significativo nel bloccare le persone dopo ripetuti tentativi non validi: in realtà diventa un vettore di attacco per un tipo di attacco di tipo Denial of Service. Pensa a cosa potrebbe accadere ad un servizio di supporto o ad un sito di assistenza clienti se un paio di centinaia di migliaia di account finiscono per essere bloccati su una base coerente da qualcuno che cerca di interrompere un servizio.

C'è persino un sito web che uso che mi invia un messaggio fisico ogni volta che cambio la mia password: qualcuno particolarmente antipatico potrebbe davvero creare problemi trovando un elenco di account e sospendendoli ripetutamente.

C'è sicuramente un giudizio da fare tra sicurezza e usabilità, e personalmente non credo che ci sia una risposta fissa o pat.

Basta la complessità per renderla tecnologicamente poco pratica per la forza bruta, rallentarla non farebbe molto di più.

"Ma questo aumenta semplicemente il numero di tentativi necessari" è un modo strano se si dice che durano miliardi di anni.

Si presuppone che le password possano essere verificate solo utilizzando il login. Ma molto spesso c'è una perdita di dati / hack che consente a qualcuno di ottenere gli hashtables della password. Se ne ha, può solo fare bruteforce per gli hash, che è molte volte più veloce rispetto all'utilizzo del login. Ed è qui che hai davvero bisogno di buone password.

Un concetto molto importante che non vedo menzionato nelle altre risposte finora è la differenziazione tra forza bruta offline e online.

In bruteforce offline l'utente malintenzionato ha accesso alle password con hash e qui la difesa principale utilizza un algoritmo di hashing della password appropriato (ad esempio bcrypt). punti attorno a algoritmi di hashing, cracking GPU, ecc. si riferiscono solo a bruteforce offline

Suppongo che questa domanda riguardi la bruteforce online in cui l'autore dell'attacco tenta di accedere al sistema probabilmente in remoto.

Con gli accessi remoti per servizi come SSH, come è stato menzionato, la supposizione remota delle password è comunemente inibita attraverso fail2ban o simili.

Dove non è comune è nelle applicazioni web (lo so perché causo i proprietari di risultati di applicazioni Web per mancanza di questa funzionalità abbastanza comunemente).

Un blocco diretto è configurato in alcuni sistemi, ma ciò comporta il rischio di negare il servizio da parte degli aggressori che inducono ad attaccare la password e anche un po 'di disagio dell'utente a seconda del meccanismo di riattivazione degli account.

Una soluzione migliore sta forzando un ritardo crescente nei tentativi di accesso per rendere l'attacco meno fattibile, tuttavia è importante notare che in alcuni casi un utente malintenzionato potrebbe voler semplicemente compromettere un account (e non preoccuparsi del proprio account) in in tal caso possono solo tentare un piccolo numero di password comuni sulla base di utenti, con l'aspettativa che qualcuno li abbia usati.

Il modo semplice per vedere questo è con un'altra domanda. Perché SHA-1 / MD5 è ancora in uso quando ci sono difetti / problemi noti con esso?

In parole povere, la valutazione del rischio della persona / azienda ritiene che tali questioni non siano di grande interesse. Proprio come nel caso dei timeout a rotazione.

Quando ho fatto un po 'di amministrazione per una scuola locale, era abbastanza comune per gli insegnanti "indovinare" le proprie password. Costringere gli insegnanti ad aspettare era molto più di un inconveniente, quindi bloccare un account dopo 4 o 5 password errate e farmi telefonare per sbloccarlo.

Anche i timeout per il roll-back sono un grosso problema da affrontare. Per un sistema locale, questo potrebbe non essere un problema, ma prendi il mio esempio di scuola (come sopra) o una grande impresa con oltre 1.000 dipendenti. Il lavoro non può più essere eseguito perché qualcuno è seduto al prompt della password, in attesa della possibilità di inserire la password corretta. Forse qualcuno ha pensato che sarebbe stato divertente convincere qualcuno a sedersi a un prompt per alcune ore, o un attaccante voleva rallentare la produzione? Considerate il fatto che ci deve essere un modo per amministrare quanto tempo sono i timeout, quanto aumentano e un modo per resettarli.

Direi che un sistema di blocco, come quello consentito da Windows, è in realtà più sicuro. Richiede un intervento amministrativo e può essere molto più veloce da annullare (più il tempo necessario per esaminare i registri). Su un sistema basato sul Web, un timeout di rolling potrebbe essere più vantaggioso, ma come abbiamo già visto, gli hash delle password saranno trapelati e il timeout di roll-back non sarebbe di aiuto.