Tre tentativi di bloccare l'accesso sono una buona idea?

Mentre la risposta di Rory è praticamente azzeccata, aggiungo che il blocco degli account dopo i tentativi di X, in certi contesti, può essere un modo semplice per provocare un Denial of Service (DoS) contro un utente legittimo.

Immagina se un fornitore di servizi webmail (come Gmail) ha funzionato in questo modo. Se voglio causarti un DoS temporaneo, tutto quello che dovrei fare è provare ad accedere come se fossi con tre (o 5, o comunque molti ci vogliono ... il numero effettivo non ha molta importanza) con la password sbagliata. Il fornitore di servizi webmail bloccherà quindi il tuo account e quando tu, anche se conosci la tua password, sei entrato per il login, non ti autenticherà.

Questo è il motivo per cui tali politiche di blocco non sono troppo comuni con i siti accessibili pubblicamente in questi giorni. Un approccio migliore consiste nell'esporre un ritardo sempre maggiore tra le istruzioni per la password, che scoraggerà i kiddie degli script ma ti consentirà comunque di inserire la tua password. Ancora meglio sta usando un altro fattore, come l'IP sorgente dei tentativi di accesso nel decidere di rallentare il prompt di accesso (o visualizzare un captcha nel caso di account Google).

Qualcosa su cui riflettere quando si discute questo tipo di politica. Cin cin.

Essenzialmente, se si osserva il blocco degli account, è progettato per ridurre il rischio di un attacco indovinatore di password online.

Se esiste una regola di password ragionevole (ad es., 8 caratteri + con complessità e un controllo per password comuni), è abbastanza improbabile che un attacco di indovinamento di password online possa avere successo in un numero basso di tentativi.

Vale anche la pena considerare l'ostilità dell'utente nei blocchi che si verificano + il costo aziendale del lavoro perduto. Quindi, come per qualsiasi cosa in sicurezza, è un compromesso.

FWIW Suggerirei che per molti sistemi 5-10 è un numero più ragionevole. anche se è abbastanza facile digitare una password 2 o 3 volte, quando arrivi a 10 è ragionevole presumere che l'utente l'abbia dimenticato.

Un altro fattore da considerare è il rischio normativo. I revisori tendono ad avere idee fisse su questo, e molti dei loro script potrebbero dire che qualsiasi cosa su 3 è un problema ...

Microsoft ha un white paper su questo qui che contiene alcuni dettagli su questo argomento.

Is this a common security rule or just a stupid one?

È una politica estremamente comune, e probabilmente, a causa del rifiuto di un attacco di servizio che implica, anche uno stupido.

È piuttosto standard nelle aziende. Potresti argomentare che ha più senso qui dove c'è un helpdesk aziendale per far fronte alla ricaduta, e tu speri spero poca motivazione per un altro dipendente di approfittare del DoS. In questo contesto è richiesto anche da alcuni standard di sicurezza, ad esempio PCI DSS. In un contesto rivolto al consumatore, in cui hai una gamma più ampia di potenziali aggressori e costi più elevati nel supportare gli utenti bloccati, sarebbe un compromesso peggiore.

L'attacco che sta tentando di bloccare è quello della forza bruta che indovina un particolare account di un utente mirato. Se vuoi eliminare il blocco degli account, dovresti trovare qualche soluzione alternativa per quell'attacco. Questo potrebbe includere:

• requisiti più complessi per la password: aumentare l'entropia in una password potrebbe aumentare notevolmente il numero di ipotesi che si prevede di ottenere una violazione;

• autenticazione a due fattori; potenzialmente, utilizzando fattori deboli aggiuntivi come indirizzi IP, profili di dispositivi e modelli di comportamento per esprimere un giudizio di rischio e potenzialmente richiedere un secondo fattore o un autenticatore aggiuntivo;

• limite di velocità basato su IP / reputazione, per rallentare progressivamente l'accesso all'interfaccia di accesso quando ci sono molti accessi non riusciti recenti.

Poiché il meccanismo di blocco degli account non tenta di evitare lo scenario di ipotesi di forza bruta su molti account (ad esempio, l'attacco "inversione della password invertita" di scegliere una password comune e provarlo su molti account), potresti voglio considerare alcuni di questi approcci in ogni caso. (L'altra mitigazione tradizionale contro questo tipo di attacco è di mantenere i nomi utente semi-segreti, proteggendo contro l'enumerazione del nome utente, ma questo è un po 'debole e può essere difficile da coprire completamente per alcuni tipi di sistema.)

Non sono sicuro di ciò che potrebbe essere appropriato nella tua situazione particolare, ma poiché tu menzioni un "mainframe" il mio sospetto sarebbe un sistema legacy con poche possibilità di cambiamento. Inoltre, non è chiaro quale tipo di "firewall" sarebbe interessato alle password degli utenti: stai parlando dell'autenticazione del proxy Web?