C'è qualche rischio nel permettere più tentativi di accesso falliti prima dell'autobanning per un tempo più lungo?

1. Molte persone hanno password molto deboli e molto deboli - il 40% di tutti gli utenti condivide le stesse 100 password, il 14% condivide le stesse 10 password (vedi articolo ). Pertanto, anche un 10 o 20 password possono essere sufficienti per un utente malintenzionato che effettua la pesca di più account utente. Da qui la barra di taglio basso.

2. Se l'utente è legittimo e ha semplicemente digitato erroneamente la password diverse volte, probabilmente l'hanno dimenticato. Alcune organizzazioni preferiscono essere contattate direttamente per reimpostare la password, nonostante l'eventuale sovraccarico di supporto.

3. Mentre personalmente mi piacciono i time-lock esponenziali; a meno che un'organizzazione non abbia un supporto tecnico 24/7, i timelock si trasformeranno in normali blocchi utente in un fine settimana. Inoltre, un attacco distribuito su più utenti contemporaneamente può riorganizzare i ritardi esponenziali a sufficienza che, su una curva a campana, alcuni account utente verranno violati molto prima del ritardo esponenziale che un singolo utente implicherebbe.

4. L'organizzazione può presumere che un denial of service sia sufficientemente risolvibile o abbastanza improbabile che un blocco DDoS da parte di tutti gli utenti sia un problema.

5. Un'organizzazione può ritenere che l'accesso dell'utente al proprio servizio sia un privilegio e che le informazioni dell'utente o del servizio siano più preziose della possibilità dell'utente di accedervi. Da qui una priorità verso la sicurezza operativa invece della comodità dell'utente. Dopotutto, gli utenti reali vengono raramente invitati come diretti interessati nei workshop di progettazione del software.

6. Le soluzioni iniziali per i Punti 1 - 5 sono state fatte su sistemi informatici precoci e poi spesso copiate come "abbastanza buone" per sistemi informatici realizzati decenni dopo. I sistemi originali che prevedevano il login remoto erano progetti militari e universitari; dove l'utente era un supplicante non un cliente.

Non generalizzerei le tue capacità di scegliere le password per il pubblico in generale. Gli utenti spesso riutilizzano le password deboli e forse potrebbero essere indovinate.

C'è anche la considerazione del supporto. Diciamo che blocchi qualcuno dopo 5 cattivi tentativi per 20 minuti. Forse dopo che l'attacco è stato bloccato, è stato spostato su un altro account, il che significa che dopo 20 minuti l'account è ora aperto all'utente reale. Questo è un intervallo di tempo veramente breve, ma entro un periodo di 24 ore, l'utente legittimo sarebbe comunque bloccato. Ora devono chiamare il supporto per sbloccare il proprio account e possono anche farsi prendere dal panico. Dal punto di vista del supporto degli utenti, forse preferirebbero ridurre il volume delle chiamate di sblocco manuali.

O più probabilmente, stanno solo facendo ciò che "tutti gli altri" stanno facendo o ciò che pensano è conoscenza comune. È anche possibile che "qualche auditor" abbia detto loro di farlo. Un backoff esponenziale può essere una buona tecnica fino a un punto, ma suona come poche altre righe di codice da gestire [sarcastico, ma in una grande org ci può essere un vero costo in dollari associato anche a tali un piccolo cambiamento]; improbabile, ma la possibilità di memorizzare / elaborare un tempo e contare durante un attacco basato su bot per il backoff esponenziale potrebbe avere un effetto negativo sulle prestazioni su larga scala.

Una breve risposta alla tua domanda è di attenuare il rischio di DoS agli utenti effettivi non disabilitando l'account per un lungo periodo. Per siti diversi nella loro C.I.A. requisiti e ciò che funziona per uno potrebbe non essere applicabile per un altro.

Per quanto riguarda la tua domanda di base, devi considerare le ramificazioni di ogni schema. I tempi esatti hanno più a che fare con la paranoia e il volume delle chiamate di supporto tecnico rispetto all'analisi di sicurezza formale.

In termini di forza bruta, devi provare un sacco di tentativi. I tentativi di forzatura bruta offline sono in grado di recuperare il 90% + delle password perché sono in esecuzione a centinaia di migliaia o milioni di password al secondo . Gli utenti possono condividere le password, ma anche un divieto di 5 minuti riduce efficacemente i tentativi di forza bruta fino a 1 password / minuto. Inoltre, in genere gli autori di attacchi non hanno accesso a tutti i nomi utente. Lanciare blacklist IP di noti robot di spam ed è un attacco davvero poco pratico. Gli hacker avrebbero molto più facile sniffare il traffico di rete e registrare le sequenze di tasti utilizzando un virus.

Un divieto di cinque-dieci minuti è più breve del tempo necessario per un cliente per contattare il supporto tecnico. Se l'utente non riesce a capirlo dopo (ad esempio) 3 divieti, è probabile che l'utente contatterà l'assistenza clienti o reimposterà la propria password poiché probabilmente l'hanno dimenticata comunque. Quindi, che senso ha metterli al bando per 24 ore / ore usando uno schema complesso? Questo frustrerà un utente già frustrato.

Schemi più complessi potrebbero avere senso per Wordpress e altri framework che non dispongono di team dedicati che filtrano i robot spam. Tuttavia, la maggior parte di questi tipi di framework invia le proprie password su testo normale e sarebbe preferibile affidare in outsourcing l'identificazione dell'utente a Google / Yahoo / Mozilla.

Per le banche e altri obiettivi di alto valore, tali schemi complessi vengono applicati perché gli aggressori sono motivati a compiere attacchi altrettanto sofisticati. Le istanze frustranti si verificano quando l'amministratore IT solo per un'organizzazione ha sia paranoia sia mancanza di cagare sull'utente finale. Per loro, pensano che se sono in grado di memorizzare password complesse o utilizzare un software di gestione password, perché l'utente finale non può farlo?