it-swarm.dev

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

Conosco il ragionamento alla base del non lasciare infiniti tentativi di password - i tentativi di forza bruta non sono una debolezza meatspace , ma un problema con la sicurezza del computer - ma da dove hanno preso il numero tre?

La negazione del servizio non è un problema quando si implementa una politica di blocco facilmente attivabile?

Esistono ricerche approfondite che mostrano un numero o un intervallo ottimali da scegliere prima di bloccare un account che bilanci l'effettiva minaccia alla sicurezza con l'usabilità?

Ripensandoci, non vedo alcuna differenza di sicurezza misurabile tra tre tentativi e 20 tentativi con la complessità della password generalmente in uso oggi.

(Conosco questa soggettività di gonna, ma sto cercando opinioni basate sulla misurazione)

107
Bradley Kreider

Di recente, 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 breve, ecco alcune delle sue idee per un blocco dell'account meno doloroso:

  • Non contare i tentativi di password duplicati (probabilmente hanno pensato di averlo scritto male)
  • Fornisci un suggerimento sulla password per la password principale e non avere un (debole) secondario
  • Consenti a una parte fidata di garantire all'utente, in modo che possa modificare la sua password.
  • Blocca l'account con incrementi di tempo crescenti
  • Ricordare all'utente le regole della password.
75
Zian Choy

Qualsiasi sito Web conforme a PCI Data Security Standards deve aderire alle 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 fino a quando l'amministratore non abilita l'ID utente).

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: Nota che questi requisiti si applicano solo ai sistemi per "utenti non consumatori", quindi non dovrebbero influire sui siti dei clienti che accettano carte.

37
realworldcoder

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

22
Tate Hansen

Non sarei sorpreso se provenisse dalla regola del baseball "Tre colpi" piuttosto che da qualsiasi cosa tecnica.

Una giustificazione (comunque per le password alfanumeriche) è

In genere un tentativo fallito è un errore di digitazione o un problema di attivazione/disattivazione di CAPS. Quindi si tenta di accedere e di essere rifiutato (1), riprovare perché si ritiene di aver digitato erroneamente (2) e quindi realizzare che la chiave MAIUSC è attiva in modo da accedere al terzo tentativo.

Non vale davvero per sbloccare i telefoni cellulari da una rete quando in genere si inserisce un codice numerico.

Suggerimenti migliori sono un ritardo sempre crescente tra i successivi tentativi di accesso non riusciti. Prima permetti un nuovo tentativo, poi 1 secondo, 2, quattro, otto ... Stai rapidamente aspettando un minuto tra i tentativi che è abbastanza per simulare qualsiasi attacco di forza bruta.

18
Gary

Sono d'accordo con l'OP. Se pensi a cosa ti protegge dal blocco, non c'è differenza tra 3 o 20 tentativi (o 100, del resto). 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 sta causando un attacco, ma questo non è lo scopo principale (se lo fosse, significa che stai deliberatamente facendo i tuoi utenti solo per semplificare il tuo lavoro di monitoraggio. Non è un ottima pratica).

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

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

Il database delle password di Conficker è leggermente inferiore a 200 password, IIRC, ed è pieno di alcune delle password più stupide del pianeta. Ora supponiamo che la tua password non sia in questo elenco. Se consenti 20 tentativi di password, diciamo per 15 minuti, senza blocco, ci vorranno più di due ore a un utente malintenzionato per passare attraverso l'elenco.

In effetti, anche se restringi il tuo elenco di indovinazioni alle password ricavate da informazioni pertinenti su quell'utente, come kidsname02, birthday99 ecc., Finirai comunque con almeno alcune decine di password, estendendo un attacco del dizionario a forse un'ora o Di Più. Quella costante, errata ipotesi nel tempo è ciò che dovrebbe far scattare 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 ​​della password più elementari, puoi accettare felicemente 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 molti tentativi, è un processo o una sessione che si blocca da qualche parte con vecchie credenziali. E se non è così, allora possiamo parlare di cercare attacchi.

15
itinsecurity

È 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 politica di blocco dei tentativi. Marv potrebbe suscitare un grave inferno facendo in modo che uno script provi automaticamente nomi casuali Y volte con password fasulle. Anche se una password funzionasse, Marv probabilmente non se ne curerebbe e la ignorerebbe. Questo bloccherebbe efficacemente molti utenti per il sito Web X e causerebbe molta frustrazione degli utenti, e dio li aiuterebbe se sono banca che è necessario chiamare per reimpostare la password. Sono sorpreso che nessuno ci abbia provato.

11
AmaDaden

Credo di essere in ritardo in 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 generalmente nell'intervallo di cifre singole per la maggior parte delle organizzazioni) non è stata ideata esclusivamente contro attacchi di forza bruta automatizzati.

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

  • spalla surf
  • indovinando i modelli utilizzati da un individuo per scegliere le proprie password. Dopotutto, quante volte si sono usate password con elementi in una sequenza, come password # 01 , password # 02 ecc.

Il rovescio della medaglia, naturalmente, è che con un valore di soglia basso, è inevitabile che ci sia una negazione del servizio e un costo associato per l'azienda. Il White paper sulle migliori pratiche di blocco degli account rilasciato da Microsoft, fornisce un valore consigliato di 10. Spiega inoltre come stimare la probabilità di un attacco riuscito, utilizzando i parametri nella politica di blocco degli account di Windows:

Ad esempio, supponiamo che l'amministratore reimposti la password quando l'account è bloccato con un valore del registro LockoutDuration pari a 0. Con il valore del registro LockoutDuration impostato su 0 e il valore del registro LockoutThreshold impostato su 20, l'utente malintenzionato ha 20 ipotesi da utilizzare in tal caso parola d'ordine. Se la durata del blocco è di 30 minuti, l'utente malintenzionato ha 20 ipotesi ogni 30 minuti contro quella password fino a quando non viene modificata. Questa è una differenza molto significativa nel numero totale di ipotesi disponibili per l'utente malintenzionato.

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

Naturalmente, per i non addetti ai lavori non è facile scegliere un numero adeguato e tali decisioni devono essere attentamente valutate. Pertanto, si potrebbe presumere che alcune organizzazioni non si siano impegnate a calcolare gli effetti monetari della propria politica di blocco degli account e il vantaggio associato di allentare la propria politica mantenendo allo stesso tempo i vantaggi di sicurezza forniti.

10
Vineet Reynolds

Ci sono due aspetti di questo; il primo, come dici tu, è prevenire attacchi di forza bruta.

A tal fine, in realtà dovrebbe essere eseguito un numero qualsiasi di tentativi: 3, 5, 20, 2000 ... con un'adeguata politica delle password (lunghezza + complessità + ...) che fornisce uno spazio chiave abbastanza grande, any il tipo di limitazione (numero X di tentativi all'ora) assicurerà che la forzatura bruta dell'intero spazio richiederebbe 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.

Pertanto, il numero di try-before-lockout è arbitrario.

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

Semplicemente non ha senso per un singolo utente inserire ripetutamente una password errata 2000 volte di seguito.

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

Penso che storicamente, il compromesso fosse più inclinato verso il lato 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 erano più esperti tecnicamente in generale.

Al giorno d'oggi, tre non hanno davvero senso, considerando l'impatto sul business. È davvero una domanda su cosa abbia senso per la tua app, quali tipi di utenti, con quale frequenza accedono, ecc. Di solito raccomando di capire quanti tentativi legittimi, falliti, sono probabili, quindi raddoppiare esso.

( Come menzionato @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.)

8
AviD

Per quanto riguarda i suggerimenti sull'incremento del tempo dei "blocchi" per ritardare i successivi tentativi falliti e quindi prevenire la forzatura bruta, si ricorda che questo funziona solo su attacchi mirati dell'utente.

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

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

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

Un'altra soluzione: identificazione a 2 fattori. Token RSA. Se solo avessimo il modo di 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 dal token insieme alla password per accedere.

Ma ciò pone tutta un'altra serie di problemi per l'implementazione e la fiducia ...

7
Dan McGrath

Le società che sono pubbliche (vendono azioni in borsa) sono regolate dal Sarbanes-Oxley Act e sono verificate più volte all'anno per verificarne la conformità. Le applicazioni software critiche devono essere conformi a determinate funzionalità di sicurezza, una delle quali è quella di bloccare gli account dopo tentativi falliti di password.

La maggior parte di queste applicazioni non fa altro che integrarsi nella società Active Directory che ha già abilitato le funzionalità.

3
Jose

Ecco una lettura davvero piacevole che va oltre ciò che credo tu stia cercando. Hanno preso i dati dagli studenti universitari usando una politica di tre colpi, una politica di dieci colpi e una politica di sciopero infinito per suggerire di aumentare il numero da tre a dieci (dal momento che triplica approssimativamente il successo del login).

Tornare in una visione soggettiva qui ...

Perché la maggior parte dei luoghi utilizza una politica a tre colpi? È 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 dovresti conoscerla. Non dovresti davvero avere bisogno di più di un tentativo. Capisco che vengono fatti degli errori, ma in una guerra ... hai davvero solo una possibilità per dimostrare di essere un alleato, giusto ?.

3
user124863

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 piuttosto che risolvere il problema o risolverlo correttamente.

Preferisco il metodo di blocco dell'utente in incrementi di tempo crescenti. Non lo toglierei dal nome utente, invece, utilizzare l'indirizzo IP della persona, perché 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 password se il sito ne fornisce uno. Se si tratta di un vero tentativo di hack, diventerà così frustrante per l'hacker che alla fine si arrenderanno. I robot proveranno così tante volte che non potranno quasi mai effettuare il login ... per esempio, se provassero 1000 password (il che richiederebbe comunque molto tempo), dovrebbero attendere 11 1/2 giorni prima di poter prova la 1001a password. Puoi facilmente aumentare l'abilità dissuasiva aumentando il moltiplicatore a ^ 3. Qualsiasi cosa sopra potrebbe diventare un po 'troppo alta per utenti umani validi.

2
Rush Frisby

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

  1. Il primo tentativo fallito fornisce un feedback immediato. Probabilmente hanno le dita grasse.
  2. Dal secondo al quinto tentativo fallito, la risposta è stata ritardata di un secondo per tentativo fallito. es. 2 secondi, 3 secondi, 4 secondi ...
  3. Se il quinto tentativo non è andato a buon fine, la sessione è terminata e viene visualizzato un messaggio che indica che dovrebbero 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 creerebbe alcun lavoro aggiuntivo per il supporto.

2
Josh