Innanzitutto, bloccare gli account è una cattiva idea. Potrebbe sembrare che tu stia rendendo la tua organizzazione più sicura tenendo lontani i "cattivi" che "indovinano" le password usando la forza bruta attacchi, ma cosa hai veramente risolto? Anche con questa politica e una base di utenti perfetta che non commette mai errori di sicurezza, un utente malintenzionato può eseguire un attacco Denial of Service alla tua organizzazione utilizzando ripetutamente la password "aaa" per bloccare gli account degli utenti critici. Considera cosa succede se il tuo aggressore ottiene una copia dell'elenco dei nomi utente per l'intero reparto IT: all'improvviso, l'IT stesso, l'organizzazione che altrimenti sarebbe in grado di sbloccare altri utenti, viene a sua volta completamente chiuso.

Considera sempre qual è il modello di minaccia prima di implementare una policy. Un "cattivo" determinato a danneggiare la tua organizzazione troverà vettori di attacco alternativi. La tua politica di blocco non sconvolgerà nemmeno un attore di uno stato nazionale (come Russia, Cina o NSA); un hacker determinato troverà semplicemente altri modi per aggirarlo (come l'ingegneria sociale); e danneggerà solo gli utenti legittimi del tuo servizio, non importa quanto alto o basso imposti il ​​contatore di blocco.

Morale della storia: non bloccare gli account. , fai quello che fa Apple con l'iPhone: ogni tentativo di accesso raddoppia il ritardo di accesso, in modo che dopo una dozzina di errori o giù di lì, devi aspettare un'ora tra ogni tentativo successivo. È abbastanza lungo da impedire ai "malintenzionati" di eseguire attacchi di forza bruta, ma comunque abbastanza breve da consentire a un utente legittimo di dedicare quell'ora a capire quale fosse la propria password e a digitarla correttamente dopo pranzo o a contattare l'IT chiedendo scusa aiuto . (Allo stesso modo, i criteri di "inondazione" possono spesso essere implementati a livello di indirizzo IP nel firewall, non solo a livello di account utente nel software, se sei preoccupato per un attaccante dedicato che cerca di forzare molti account diversi .)

E se non blocchi gli account, non è necessario avere un contatore o visualizzarlo .

[ vedi anche: questa eccellente risposta a una domanda simile ]

Dipende dal tuo meccanismo di blocco. Se gli accessi non validi vengono ripristinati dopo un po 'di tempo E un account bloccato non viene sbloccato, mostrare un contatore può aiutare un utente malintenzionato a non bloccare un account. Ma un utente malintenzionato esperto avrà determinato in anticipo la politica di blocco e ne terrà conto quando indovina la password. Quindi l'impatto è limitato.

Inoltre, fare affidamento su questo per proteggere il tuo meccanismo di accesso non ha senso. Dovresti avere una politica delle password decente e una politica di blocco da abbinare. Se la politica della password è forte, un utente malintenzionato dovrà indovinare un gran numero di volte prima di ottenerla correttamente. Se blocchi un account dopo 20 tentativi, hai poche possibilità di essere compromesso.

Devi chiederti: qual è il vantaggio di mostrare queste informazioni a un utente autentico? Spesso, questo problema con il blocco si verifica perché il numero di tentativi è impostato su un valore troppo basso. 3 o 5 sono scelte comuni. NIST (attualmente non disponibile a causa della chiusura del governo, quindi nessun riferimento diretto) suggerisce meno di 100 tentativi.

NIST ha uno scopo: pensa a una password che nessun aggressore indovinerà in 3 tentativi, ma che indovineranno in 100 tentativi. Tutti gli aggressori utilizzano dizionari e approcci diversi. Se una password non è sicura per resistere a 100 tentativi, può anche essere violata utilizzando meno tentativi, sebbene sia meno probabile. Quindi una buona politica per le password è un must.

Aggiungerò i riferimenti NIST quando il sito tornerà. Troy hunt ha alcuni buoni post sul blog che riassumono la password e i meccanismi di accesso. È anche un fan delle linee guida del NIST.

In linea di principio no, non dovrebbe essere un rischio per la sicurezza. Se lo fosse, faresti affidamento sulla sicurezza attraverso l'oscurità (informazioni nascoste).

Nascondere un conteggio sarebbe, nella migliore delle ipotesi, un piccolo inconveniente per un avversario.

Al contrario, nascondere un conteggio può essere un inconveniente significativo per gli utenti legittimi. Non è raro che a volte inserisca la password sbagliata e poi la reinserisca ancora un paio di volte supponendo di aver fatto un errore di battitura. Se so che verrò bloccato con un altro tentativo errato, cercherò la mia password e la copia / incolla o la digiterò attentamente. Se, tuttavia, mi blocco inconsapevolmente il mio account, ora devo affrontare molti problemi extra per sbloccarlo.

Per dare un'altra prospettiva a questo: non importa per un utente malintenzionato esperto .

In che modo gli account online vengono compromessi oggi tipicamente ¹ ? Esistono due varianti di una tecnica comunemente utilizzata.

I database con hash delle password (o password in chiaro) vengono rubati e violati offline dagli aggressori. Dopo aver crackato con successo un hash, la password corretta viene fornita al meccanismo di accesso al primo tentativo, quindi questo controllo è inefficace.

Questo può essere il database del servizio in questione o il database di un altro servizio. Sfortunatamente le persone tendono a riutilizzare le proprie password con diversi servizi, quindi è molto probabile che una volta che una password viene abbinata a un indirizzo e-mail, possa essere utilizzata su un altro sito. Un utente malintenzionato potrebbe avere due o tre password tra cui scegliere, ma probabilmente non 20. Ancora una volta, questo controllo è inefficace.

Quindi quale livello di sicurezza stabilisce questo controllo? Il livello necessario per proteggere da script kiddies inesperti, ex partner maliziosi e genitori ficcanaso che vogliono dare un'occhiata al tuo account personale e provare cinque password a caso. Niente di più, ma niente di meno.

^{1 Poi ci sono ovviamente altre tecniche più "avanzate" come keylogging, (spear) -phishing, MitM ecc. non mitigato da questo controllo.}

Solo due scenari sono possibili con esso, ma piuttosto mostrare che il rischio della politica del tempo di blocco dell'account è maggiore del tempo di blocco.

Ad esempio

• una volta può configurare l'idra o qualche altro strumento per forzare il login e attendere dopo 3 tentativi. se non hai tempo di blocco sufficiente può causare la compromissione dell'account.

• se hai un tempo di blocco di circa 30 minuti, è comunque possibile configurare lo strumento per la forza bruta e aspetta dopo tre tentativi, ci vorranno anni per decifrare la password.

per concludere che questo non comporta alcun rischio nella visualizzazione del tentativo di blocco dell'account.

In generale, mi propongo di fornire meno informazioni a un aggressore, meglio è. Come menzionato da @ security-beast, uno strumento può essere configurato per attendere la quantità di tempo appropriata. Fornire loro le informazioni per quella configurazione non è necessariamente l'ideale.

Tuttavia, devi bilanciarlo con le esigenze dei tuoi utenti. Trovi che gli amministratori di sistema impieghino una quantità eccessiva di tempo per sbloccare gli account perché i tuoi utenti continuano a bloccarli? In tal caso, la tua analisi potrebbe indicare che ottieni maggiori vantaggi dalla visualizzazione del numero di tentativi agli utenti in modo che sappiano quando devono attendere prima di bloccare i loro account. In altri casi sarà vero il contrario, ma in entrambi i casi la risposta dovrebbe essere il risultato di un'analisi oggettiva dei compromessi per il particolare sistema.

Spero che questo aiuti.

Il rischio per la sicurezza è soggettivo e dipenderà da ciò che stai cercando di proteggere, dall'obiettivo del controllo di sicurezza e da qualsiasi altro controllo di sicurezza in atto che mitiga o compensa il rischio.

Sulla base di queste diverse società / affari avranno un'accettazione diversa dello stesso rischio.

Se in modo generico fornire quanti tentativi hai ancora potrebbe non imporre un rischio (es: PIN nella tua smart card per effettuare chiamate telefoniche) In altre situazioni potrebbe essere un rischio (es: tentare di brute force mobile phone access) dove puoi fermarti prima dell'ultimo tentativo e attendere un po 'di tempo in modo che l'utente resetti il ​​contatore con un accesso valido ...

Dovresti controllare l'obiettivo del controllo di sicurezza, cosa stai cercando di proteggere e quali controlli di sicurezza hai in atto per compensare o almeno monitorare situazioni anomale.

Sulla base di tutto ciò, puoi decidere se è un rischio accettabile o meno per le tue specifiche.

A un certo punto ero in un'azienda in cui hanno chiesto ad alcuni ragazzi di testare la loro sicurezza. Una di queste cose che quei ragazzi hanno scoperto è che non c'era il blocco dell'account quando c'erano troppe password errate. Tuttavia, con grande gioia del CISO, non sono riusciti a dimostrare di essere effettivamente in grado di entrare forzando la password. Il motivo è che il blocco dell'account è stato silenzioso ed è durato circa 15 minuti.

Chiediti cosa guadagni visualizzando un messaggio del genere e cosa perdi in sicurezza così facendo. È perfettamente valido non dare alcuna notifica di blocco di un account a causa di troppi tentativi di accesso errati. Se dai un messaggio del genere, aiuterai un aggressore a capire quando sta sprecando il suo tempo forzando brute. Se non lo fai, è meno probabile che lo capisca, ma potrebbe portare a più chiamate / e-mail al tuo helpdesk che potrebbe essere costoso. Una FAQ o una pagina di aiuto potrebbe ridurre questo problema.

Anche l'implementazione del conto alla rovescia, probabilmente, significherà più codice e più codice significa più bug. Questo non è qualcosa che desideri in un meccanismo di sicurezza. Aggiungete a ciò che lo implementate in modo sbagliato, potrebbe consentire agli aggressori di enumerare i nomi utente, il che è doppiamente problematico se si tratta di indirizzi e-mail. Diavolo, se lo implementi usando un cookie non firmato, potrebbe effettivamente dare all'aggressore la possibilità di impedire del tutto un blocco.

In generale la tua sicurezza sarà migliorata se i tuoi messaggi di errore forniscono il minor numero possibile di informazioni .