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.

In lungo, ecco alcune delle sue idee per un blocco degli account meno doloroso:

• Non contare i tentativi di password duplicati (probabilmente pensavano di averla digitata male)
• Fai il suggerimento per la password sul password principale e non avere una secondaria (debole)
• Consenti a una parte fidata di garantire per l'utente, in modo che possa cambiare la sua password.
• Blocca l'account in un tempo crescente incrementi
• Ricorda all'utente le regole per la password.

Qualsiasi sito web conforme agli standard di protezione dei dati PCI deve rispettare le sezioni

• 8.5.13 (Limita i tentativi di accesso ripetuti 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'utente ID).

Questo è purtroppo 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", quindi non dovrebbero influire sui siti dei clienti che accettano carte.

La mia esperienza è che i meccanismi di blocco stanno diminuendo in popolarità (almeno per le app web). Invece di bloccare gli account dopo una serie di tentativi falliti, inizi a chiedere ulteriori informazioni per una corretta autenticazione.

Non sarei sorpreso se provenisse dalla regola del baseball "Tre strike" piuttosto che da qualcosa di tecnico.

Una giustificazione (per le password alfanumeriche in ogni caso) è

In genere un tentativo fallito è un errore di digitazione o un problema di attivazione / disattivazione CAPS. Quindi provi ad accedere e vieni rifiutato (1), riprova perché pensi di aver digitato male (2) e poi ti rendi conto che il tasto MAIUSC è acceso, quindi accedi al terzo tentativo.

Non non è valido per sbloccare i telefoni cellulari da una rete quando si inserisce normalmente un codice numerico.

I suggerimenti migliori sono un ritardo sempre maggiore tra i successivi tentativi di accesso non riusciti. Per prima cosa consenti un nuovo tentativo istantaneo, poi 1 secondo, 2, quattro, otto ... Stai aspettando rapidamente un minuto tra i tentativi che è sufficiente per simulare qualsiasi attacco di forza bruta.

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

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

Se qualcuno sta tentando una forza bruta in linea, tutto ciò di cui hai bisogno è una password che possa resistere per "abbastanza a lungo": abbastanza a lungo perché il tuo IRT risponda o abbastanza a lungo perché il tuo aggressore si arrenda.

Il database delle password di Conficker è leggermente inferiore a 200 password, IIRC, ed è pieno di alcune delle password più stupide del pianeta. Supponiamo ora che la tua password non sia in questo elenco. Se consenti 20 tentativi con la password, diciamo ogni 15 minuti, senza bloccare, un utente malintenzionato impiegherà più di due ore solo per superare quell'elenco.

In effetti, anche se restringi la password create da informazioni rilevanti su quell'utente, come kidsname02, birthday99 ecc., ti ritroverai comunque con almeno qualche decina di password, estendendo un attacco al dizionario a forse un'ora o più. attiva i tuoi allarmi, non una manciata di password sbagliate in un paio di minuti.

Quindi, se riesci a tenere i tuoi utenti lontani dalle insidie ​​delle password più basilari, puoi tranquillamente accettare molti tentativi di password errati.

Personalmente, traccio la linea a 15. Totalmente arbitrario, e soprattutto una cosa pratica: trovo che qualsiasi utente reale abbia rinunciato molto prima di questo. Di solito, se ci sono così tanti tentativi, è un processo o una sessione appesa da qualche parte con vecchie credenziali. E se non è così, possiamo parlare della ricerca di attacchi.

È una stupida regola arbitraria che comporta il rischio di uno strano tipo di attacco DDOS. Diciamo che Marv odia il sito web X e il sito web X ha un numero Y di criteri di blocco dei tentativi. Marv potrebbe creare un inferno serio facendo in modo che uno script provi automaticamente con nomi casuali Y volte con password fasulle. Anche se una password funzionasse, Marv probabilmente non se ne preoccuperebbe e la ignorerebbe. Ciò bloccherebbe efficacemente molti utenti per il sito Web X e causerebbe molta frustrazione per gli utenti, e Dio li aiuti se sono una banca che devi chiamare per reimpostare la tua password. Sono sorpreso che nessuno ci abbia provato.

Credo di essere in ritardo a questo dibattito, ma spero di avere qualcosa di utile da aggiungere qui.

La politica di blocco dell'account (con il numero di tentativi non validi consecutivi di solito compreso tra una singola cifra per la maggior parte delle organizzazioni) non è stato concepito esclusivamente contro gli attacchi automatici di forza bruta.

È più una protezione contro l'individuazione della password da parte di aggressori umani, in particolare da persone che già conoscono una parte della password. Gli aggressori potrebbero ottenere frammenti di password

• navigando a spalla
• indovinando i modelli utilizzati da un individuo per scegliere le proprie password. Dopo tutto, quante volte è stata utilizzata una password con elementi in una sequenza, come password # 01 , password # 02 ecc.

Lo svantaggio, ovviamente, è che con un valore di soglia basso, è inevitabile che ci sia un Denial of Service e un costo associato per le imprese. Il Libro bianco sulle best practice per il blocco degli account pubblicato da Microsoft fornisce un valore consigliato di 10. Spiega inoltre come stimare la probabilità di un attacco riuscito, utilizzando i parametri nei criteri di blocco degli account di Windows:

Ad esempio, si supponga che l'amministratore reimposti la password quando l'account è bloccato con il valore di registro LockoutDuration di 0. Con il valore di registro LockoutDuration impostato su 0 e il valore di registro LockoutThreshold impostato su 20, il l'utente malintenzionato ha 20 tentativi da utilizzare contro quella password. Se la durata del blocco è di 30 minuti, l'utente malintenzionato ha 20 tentativi ogni 30 minuti contro quella password finché non viene modificata. Questa è una differenza molto significativa nel numero totale di tentativi disponibili per l'utente malintenzionato.

In confronto, se l'amministratore imposta l'età massima della password a 42 giorni, il primo utente malintenzionato ha solo 20 tentativi contro una determinata password, mentre il secondo utente malintenzionato ha 40.320 tentativi (20 tentativi di blocco per sempre, moltiplicati per 48 blocchi ogni giorno, moltiplicato per 42 giorni prima che l'utente cambi la password). Con le impostazioni della password predefinita, sono disponibili circa 10 ^ 12 password possibili. Ciò significa che l'utente malintenzionato ha circa una probabilità dello 0,000004% (%) di indovinare la password. Con uno schema di ipotesi ottimizzato, questa percentuale sarebbe molto probabilmente una percentuale maggiore.

Ovviamente, non è facile per nessun profano scegliere un numero adatto e tali decisioni dovrebbero essere prese con attenzione considerato. Pertanto, si potrebbe tranquillamente presumere che alcune organizzazioni non si siano impegnate a calcolare gli effetti monetari della loro politica di blocco dell'account e il vantaggio associato di allentare la loro politica pur conservando il vantaggio di sicurezza che fornisce.

Ci sono due aspetti in questo; il primo, come hai detto, è prevenire gli attacchi di forza bruta.

A questo scopo, dovrebbe essere fatto un numero qualsiasi di tentativi - 3, 5, 20, 2000 ... con una corretta politica delle password (lunghezza + complessità + ...) fornendo uno spazio sufficiente per la chiave, qualsiasi tipo di limitazione (numero X di tentativi all'ora) assicurerà che la forzatura bruta dell'intero spazio richiederà alcuni decenni. (Fai i conti).

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, qui è in gioco un altro problema, più sottile e non matematico:

Semplicemente non ha senso che un singolo utente inserisca ripetutamente un errore password 2000 volte di seguito.

Cioè, se scegli arbitrariamente 2000, sai molto prima che questo NON è un utente legittimo. Quindi, si tratta davvero di ciò che ha senso per gli affari e di un compromesso di analisi del rischio incentrato sul business.

Penso che storicamente, il compromesso 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 gli utenti in generale erano più tecnicamente esperti.

Al giorno d'oggi, tre non hanno davvero senso, considerando l'impatto sul business. È davvero una questione di ciò che ha senso per la tua app, quali tipi di utenti, quanto spesso accedono, ecc. Di solito consiglio di capire quanti tentativi falliti e legittimi sono probabili, quindi raddoppialo.

( 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 tu.)

Per quanto riguarda i suggerimenti di "blocchi" che aumentano il tempo per ritardare i successivi tentativi falliti e quindi prevenire la forzatura bruta, ricorda che questo funziona solo con attacchi mirati degli utenti.

per ottenere l'accesso al sistema, potrebbero eseguire un primo attacco ampio (scorrere tutti i nomi utente noti / indovinati prima di passare alla password successiva). Aggiungi che se è stato fatto correttamente potrebbe provenire da una rete distribuita di macchine, è abbastanza facile vedere che neanche il sistema di ritardo funziona.

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

Sì, 3 tentativi sono abbastanza arbitrari e rappresentano un rischio DoS. Vorrei davvero che le persone smettessero di usare per i sistemi rivolti al pubblico ... Per favore!

Un'altra soluzione: l'identificazione a 2 fattori. Token RSA. Se solo avessimo un modo per possedere personalmente un singolo token RSA con un "numero ID". Potremmo quindi registrare questo "numero id" con qualsiasi sistema, che richiederebbe quindi il valore corrente del token insieme alla password per accedere.

Ma questo pone tutta un'altra serie di problemi per l'implementazione e fiducia ...

Le società che sono pubbliche (vendono azioni in borsa) sono regolate dal Sarbanes-Oxley Act e vengono controllate più volte l'anno per verificarne la conformità. Le applicazioni software critiche devono essere conformi a determinate funzionalità di sicurezza: una di queste consente di bloccare gli account dopo i tentativi di password non riusciti.

La maggior parte di queste applicazioni consiste nell'integrarsi nell'Active Directory aziendale che dispone già delle funzionalità abilitate.

Ecco una lettura davvero piacevole che ripercorre ciò che credo tu stia cercando. Hanno preso i dati dagli studenti universitari utilizzando una politica di tre colpi, una politica di dieci colpi e una politica di colpi infiniti per suggerire di aumentare il numero da tre a dieci (poiché triplica approssimativamente il successo dell'accesso).

Tornando a una visione soggettiva qui ...

Perché la maggior parte dei luoghi utilizza una norma dei tre avvertimenti? È certamente solo un'euristica che si è sviluppata 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 alla base di una password è che si suppone di conoscerla . Non dovresti aver bisogno più di un tentativo. Capisco che si commettano errori, ma in una guerra ... hai davvero solo una possibilità per dimostrare di essere un alleato, giusto?

Devono averne scelto 3 a caso. Questo è estremamente basso. Forse hanno avuto problemi di sicurezza in passato e hanno scelto un numero di blocco basso piuttosto che indirizzare o risolvere il problema correttamente.

Preferisco il metodo di bloccare l'utente in incrementi di tempo crescenti. Tuttavia, non lo escluderei dal nome utente, ma utilizzerei invece l'indirizzo IP della persona, perché 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, utilizzerà principalmente uno strumento di recupero della password se il sito ne fornisce uno. Se si tratta di un vero tentativo di hacking, diventerà così frustrante per l'hacker che alla fine si arrenderà. I bot proveranno così tante volte che non sarà quasi mai permesso di accedere ... ad esempio, se provassero 1000 password (il che richiederebbe molto tempo per farlo comunque) dovrebbero aspettare 11 giorni e mezzo prima di poter prova la 1001a password. Puoi facilmente aumentare la capacità di deterrenza aumentando il moltiplicatore a ^ 3. Qualunque cosa sopra potrebbe diventare un po 'troppo alta per gli utenti umani validi.

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

1. Il primo tentativo fallito fornisce un feedback immediato. Probabilmente l'hanno capito.
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 è stata terminata e gli è stato presentato un messaggio che indicava che avrebbero dovuto chiudere il browser e provare di nuovo.

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