Perché i siti implementano il blocco dopo tre tentativi di password non riusciti?

Recentemente, alla conferenza OWASP AppSec 2010 a Orange County, Bill Cheswick di AT & T ha parlato a lungo di questo problema.

In breve, la ricerca è insufficiente.

A lungo, ecco alcune delle sue idee per un blocco dell'account meno doloroso:

• Non contare i tentativi di password duplicati (probabilmente pensavano di averlo digitato in modo errato)
• Definisci la password sulla password principale e non hai un secondario (debole)
• Consenti a una parte fidata di garantire l'utente, in modo che possa cambiare la sua password.
• Blocca l'account con incrementi di tempo crescenti
• Ricorda all'utente le regole della password.

Qualsiasi sito web conforme a PCI Data Security Standard deve aderire alle sezioni

• 8.5.13 (Limita i tentativi di accesso ripetuto bloccando l'ID utente dopo non più di sei tentativi)
• 8.5.14 (imposta la durata del blocco su trenta minuti o finché l'amministratore non abilita l'ID utente).

Purtroppo questo è il motivo per cui molti siti che accettano carte di credito hanno politiche di blocco draconiane, anche se i loro progettisti potrebbero non essere necessariamente d'accordo con ciò che hanno implementato.

Modifica: tieni presente che questi requisiti si applicano solo ai sistemi per "utenti non consumatori", pertanto non devono influire sui siti dei clienti che accettano carte.

La mia esperienza è che i meccanismi di blocco stanno diminuendo di popolarità (almeno per le app web). Invece di bloccare i conti dopo una serie di tentativi falliti, si inizia a chiedere ulteriori informazioni per un'autenticazione corretta.

Non sarebbe sorpreso se provenga dalla regola del baseball "Tre colpi" piuttosto che da qualsiasi altra cosa tecnica.

Una giustificazione (per le password alfanumeriche comunque) è

In genere un tentativo fallito è un problema di tipo errato o CAPS on / off. Quindi prova ad accedere e ottenere respinto (1), riprova perché ritieni di aver digitato male (2) e poi ti rendi conto che il tasto CAPS è attivo, quindi partecipa al terzo tentativo.

In realtà non è valido per lo sblocco dei telefoni cellulari da una rete quando di solito è inserito un codice numerico.

I suggerimenti migliori sono un ritardo sempre crescente tra successivi tentativi di accesso falliti. Per prima cosa permetti un tentativo immediato, poi 1 secondo, 2, quattro, otto ... Stai aspettando rapidamente un minuto tra i tentativi che è sufficiente per simiiare qualsiasi attacco di forza bruta.

Sono d'accordo con l'OP. Se pensi a cosa ti protegge dal blocco, non c'è differenza tra 3 o 20 tentativi (o 100, se è per questo). Tutto ciò che ottieni con questi blocchi, oltre a punire gli utenti smemorati, è prevenire un attacco di forza bruta. Puoi anche utilizzarlo per attivare un avviso che un attacco è in corso, ma questo non è lo scopo principale (se lo fosse, vuol dire che stai deliberatamente facendo i tuoi utenti solo per semplificare il tuo lavoro di monitoraggio. ottima pratica).

Se qualcuno ha il tuo database di password e può hackerarlo off-line, ha un numero illimitato di tentativi. Il tuo limite di 20 tentativi non va bene lì.

Se qualcuno sta tentando una forza bruta online, tutto ciò di cui hai bisogno è una password che possa resistere per "abbastanza a lungo": abbastanza a lungo da consentire all'IRT di rispondere, o abbastanza a lungo da permettere al tuo aggressore di rinunciare.

Il database delle password di Conficker è leggermente inferiore alle 200 password, IIRC, ed è pieno di alcune delle password più stupide del pianeta. Ora supponiamo che la tua password non sia presente in questo elenco. Se permetti 20 tentativi di password, diciamo per 15 minuti, senza bloccare, ci vorrà un attaccante per più di due ore solo per passare da quella lista.

Infatti, anche se si restringe la lista delle ipotesi a password fatte da informazioni rilevanti su quell'utente, come kidsname02, birthday99 ecc., si finirà comunque con almeno qualche decina di password, estendendo un attacco dizionario a forse un'ora o più. Quella costante, errata supposizione nel tempo è ciò che dovrebbe attivare i tuoi allarmi, non una manciata di password sbagliate in un paio di minuti.

Quindi, se riesci a tenere gli utenti lontani dalle trappole più semplici della password, puoi accettare volentieri molti tentativi di password errati.

Personalmente, disegno la linea a 15. Totalmente arbitrario, e soprattutto una cosa pratica: trovo che ogni utente reale abbia rinunciato molto prima di questo. Di solito, se ci sono molti tentativi, è un processo o una sessione che si trova da qualche parte con vecchie credenziali. E se non è così, allora possiamo parlare di cercare attacchi.

È una regola arbitraria arbitraria che comporta il rischio di uno strano tipo di attacco DDOS. Diciamo che Marv odia il sito X e il sito X ha un numero Y di politica di blocco tentativo. Marv potrebbe sollevare un serio inferno facendo in modo che uno script proverà automaticamente a caso nomi Y con password false. Anche se una password funzionasse, Marv probabilmente non se ne preoccuperebbe e la ignorerebbe. Ciò bloccherebbe in modo efficace molti utenti per il sito X e causerebbe un sacco di frustrazione da parte degli utenti, e Dio li aiuterà se sono in banca che è necessario chiamare per reimpostare la password. Sono sorpreso che nessuno abbia provato questo.

Credo di essere in ritardo in questa discussione, ma spero di avere qualcosa di utile da aggiungere qui.

Il criterio di blocco degli account (con il numero di tentativi invalidi consecutivi di solito nell'intervallo di cifre singole per la maggior parte delle organizzazioni) non è stato concepito esclusivamente contro attacchi automatici di forza bruta.

È più una protezione contro la password che indovina gli aggressori umani, specialmente da parte di individui che già conoscono una parte della password. Gli aggressori potrebbero ottenere frammenti di password

• shoulder surfing
• indovinando i modelli utilizzati da un individuo per scegliere le proprie password. Dopo tutto, quante volte ha usato una password con elementi in una sequenza, come password # 01 , password # 02 ecc.

Lo svantaggio, naturalmente, è che con un valore soglia basso, è inevitabile che vi sia un rifiuto del servizio e un costo associato alle attività. Libro bianco sulle best practice per il blocco degli account emesso da Microsoft, fornisce un valore consigliato di 10. Spiega inoltre come stimare la probabilità di un attacco riuscito, utilizzando i parametri nel criterio di blocco degli account di Windows:

As an example, assume that the administrator resets the password when the account is locked with LockoutDuration registry value of 0. With the LockoutDuration registry value set to 0 and the LockoutThreshold registry value set to 20, the malicious user has 20 guesses to use against that password. If the lockout duration is 30 minutes, the malicious user has 20 guesses every 30 minutes against that password until it is changed. This is a very significant difference in the total number of guesses that are available to the malicious user.

In comparison, if the administrator sets the maximum password age to 42 days, the first malicious user has only 20 guesses against any given password, while the second malicious user has 40,320 guesses (20 tries for ever lockout, multiplied by 48 lockouts every day, multiplied by 42 days before the user changes the password). With the default password settings, there are approximately 10^12 possible passwords. This means that the malicious user has approximately a .000004 percent (%) chance of guessing the password. With an optimized guessing scheme, this percentage would most likely be a larger percentage.

Naturalmente, non è facile per qualsiasi profano scegliere un numero adatto, e tali decisioni dovrebbero essere attentamente considerate. Pertanto, si potrebbe tranquillamente presumere che alcune organizzazioni non abbiano compiuto sforzi per calcolare gli effetti monetari della politica di blocco degli account e il beneficio associato di attenuare le proprie politiche mantenendo i benefici sulla sicurezza che fornisce.

Ci sono due aspetti in questo; il primo, come lei dice, sta impedendo attacchi di forza bruta.

Per questo scopo, qualsiasi numero di tentativi dovrebbe fare - 3, 5, 20, 2000 ... con una password corretta (lunghezza + complessità + ...) che fornisce uno spazio abbastanza grande per la chiave, qualsiasi tipo di limitazione (numero X di tentativi all'ora) assicurerà che la forzatura bruta dell'intero spazio richiederebbe alcuni decenni. (Fai la matematica).

Anche se - e questo dovrebbe essere un requisito - il blocco è solo temporaneo e dopo un breve periodo di tempo si sblocca automaticamente.

Quindi, il numero di tentativi prima del blocco è arbitrario.

Tuttavia, c'è un altro, più sottile, non matematico problema in gioco qui:

It simply does not make sense for a single user to repeatedly put in a wrong password 2000 times in a row.

Cioè, se scegli arbitrariamente 2000, prima lungo sai che NON è un utente legittimo. Pertanto, si tratta in realtà di ciò che ha senso per gli affari e di un trade-off di analisi del rischio incentrato sull'attività aziendale.

Penso che storicamente il trade-off fosse più inclinato verso il lato del rischio - poiché le password erano più brevi e meno complesse, la differenza di 3 o 10 era maggiore. Inoltre, le persone avevano meno password, quindi erano più facili da ricordare ... E, in generale, gli utenti erano più esperti in termini tecnici.

Al giorno d'oggi, tre in realtà non hanno senso, considerando l'impatto sul business. È davvero una questione di cosa ha senso per l'app tua , quali tipi di utenti, con che frequenza di accesso, ecc. Di solito consiglio di capire quanti tentativi falliti e legittimi sono probabili, quindi raddoppiarli.

( Come menzionato da @realworldcoder , PCI ha scelto arbitrariamente sei, e se sei soggetto a PCI non hai molta decisione qui, altrimenti scegli un numero che abbia senso per te.)

Riguardo ai suggerimenti di tempo che aumentano i "lock-out" per ritardare i tentativi falliti successivi e quindi prevenire il brute force, ricordati che questo funziona solo sugli attacchi degli utenti mirati.

Se l'utente malintenzionato si preoccupa solo di ottenere l'accesso al sistema, potrebbe eseguire un primo attacco di ampiezza (eseguire il ciclo di tutti i nomi utente noti / indovinati prima di passare alla password successiva). Aggiungete che se è stato fatto correttamente potrebbe provenire da una rete distribuita di macchine, è abbastanza facile vedere che anche il sistema di delay non funziona.

Come menzionato da altri, il corretto monitoraggio dei tentativi falliti di scoprire gli attacchi in anticipo è fondamentale.

Sì, 3 tentativi sono abbastanza arbitrari e pone un rischio DoS. Vorrei davvero che la gente smettesse di usare per i sistemi di facciata pubblica ... Per favore!

Un'altra soluzione: identificazione di due fattori. Token RSA. Se solo avessimo un modo per possedere personalmente un singolo token RSA con un 'numero identificativo'. Potremmo quindi registrare questo 'numero ID' con qualsiasi sistema, che richiederebbe quindi il valore corrente dal token insieme alla password per accedere.

Ma questo pone un altro gruppo di problemi per l'implementazione e la fiducia ...

Le aziende che sono pubbliche (vendono azioni in borsa) sono regolamentate dalla legge Sarbanes-Oxley e sono sottoposte a revisione più volte all'anno per la conformità. Le applicazioni software critiche devono rispettare alcune funzionalità di sicurezza che sono state tra le quali bloccare gli account dopo tentativi di password falliti.

La maggior parte di queste applicazioni è in grado di integrarsi nella Active Directory dell'azienda che ha già abilitato le funzioni.

Ecco una lettura davvero piacevole che ripercorre quello che credo stia cercando. Hanno preso i dati dagli studenti universitari usando una politica di tre colpi, una politica di dieci colpi e una politica di strike infinito per suggerire di aumentare il numero da tre a dieci (poiché approssimativamente triplica il successo del login).

Ritrovare una visione soggettiva qui ...

Perché la maggior parte dei luoghi utilizza una politica di tre colpi? È certamente solo un euristico che si è sviluppato nel tempo. Tre tentativi sono più o meno una via di mezzo per amministratori e utenti, in quanto tre possibilità sono più che sufficienti.

L'idea dietro una password sei supposto per conoscerla. Non dovresti davvero aver bisogno di più di una prova. Capisco che gli errori sono fatti, ma in una guerra ... hai solo una possibilità di dimostrare che sei un alleato, giusto?.

Devono aver scelto 3 a caso. Questo è estremamente basso. Forse hanno avuto problemi di sicurezza in passato e hanno scelto un numero di blocco basso anziché l'indirizzo o risolto il problema correttamente.

Preferisco il metodo di bloccare l'utente in incrementi di tempo crescente. Tuttavia, non lo inserisco nel nome utente, ma utilizzo l'indirizzo IP della persona, poiché la persona potrebbe provare più nomi utente. Ho impostato il tempo di blocco su (numero di tentativi di accesso non validi) ^ 2 secondi, una volta che l'utente ha raggiunto 5 tentativi non validi. Se l'utente non conosce la propria password in un numero relativamente basso di tentativi, per lo più utilizza uno strumento di recupero password se il sito ne fornisce uno. Se è un vero tentativo di hacking diventerà così frustrante per l'hacker che alla fine si arrenderanno. I robot tenteranno così tante volte che non potranno quasi mai effettuare il login ... ad esempio, se avessero provato 1000 password (il che richiederebbe molto tempo per farlo in ogni caso) avrebbero dovuto aspettare 11 giorni e mezzo prima che potessero prova la 1001th password. Potresti aumentare facilmente l'abilità deterrente aumentando il moltiplicatore a ^ 3. Qualsiasi valore superiore potrebbe risultare un po 'troppo alto per utenti umani validi.

Non molto tempo fa ho implementato uno schema di sicurezza di accesso che seguiva queste regole di base:

1. Il primo tentativo fallito dà un riscontro immediato. Probabilmente lo hanno ingrassato.
2. Dal secondo al quinto tentativo fallito, la risposta è stata ritardata di un secondo per tentativo fallito. ad es. 2 secondi, 3 secondi, 4 secondi ...
3. Se il quinto tentativo non è riuscito, la sessione è terminata e viene loro presentato un messaggio che indica che dovranno chiudere il browser e riprovare.

Per me questo era più che adeguato per prevenire attacchi di forza bruta; sarebbe al massimo un inconveniente per gli utenti finali e non ha creato alcun lavoro aggiuntivo per il supporto.