Si sta negando l'accesso dopo che i tentativi non corretti sono stati inefficaci?

La prevenzione del login senza la password corretta è la funzionalità principale del processo di accesso. Continuare a farlo non è assolutamente una funzione di sicurezza "aggiuntiva".

Negare i tentativi di accesso dopo X tentativi errati significa respingere i tentativi tutti in quella situazione, indipendentemente dal valore della password che viene poi presentata. Se accetti comunque la password corretta, non stai negando nulla, stai solo gestendo una procedura di accesso.

Con i sistemi online, disabilitare l'account è un po 'avventato; significa che chiunque può bloccare efficacemente il tuo account inserendo password spazzatura. Una procedura più semplice consiste nell'aggiungere ritardi : dopo X password errate, chiedere al server di bloccare l'account, ad esempio, un minuto e rebloccarlo per un minuto dopo ogni tentativo finché non viene immessa la password corretta. I tentativi iniziali di X dovrebbero essere sufficienti per far fronte agli utenti con dita tremolanti, e il tasso di un minuto per minuto ostacola gravemente un attaccante bruteforcing (combinato con alcune misure di sicurezza come il divieto di IP da cui troppe richieste di accesso arrivano in pochissimo tempo) .

L'idea è di non accettare nemmeno la password corretta durante il blocco.

Ma prima di implementare un sistema di blocco, ha senso esaminare i casi di attacco:

un utente specifico è scelto come target

Se l'utente malintenzionato ha come target un utente specifico, negare o ritardare gli accessi dopo un paio di tentativi errati è utile. Un errore comune con l'approccio di ritardo non è quello di impedire i tentativi di login paralleli.

Un altro approccio comune è usare CAPTCHA per rallentare l'aggressore. Bisogna tenere a mente che molti CAPTCHA standard sono già guasti. Quando il voto del NY Times è stato manipolato, gli aggressori hanno creato un'interfaccia speciale che mostra molti CAPTCHA su una pagina.

L'attaccante può provare solo due tentativi di accesso ogni giorno per un lungo periodo di tempo (di fatto lo vediamo in Stendhal di tanto in tanto). Potrebbe essere utile visualizzare il numero di tentativi di accesso non riusciti dopo un accesso riuscito. È importante non dire "0 tentativi di accesso non riusciti" ogni volta perché questo insegnerà semplicemente alle persone a ignorare quel messaggio. Mostra solo l'avviso se c'è stato almeno un tentativo di accesso fallito.

Un elenco di indirizzi IP e timestamp degli ultimi tentativi di accesso (riusciti o meno) può essere d'aiuto, almeno per gli utenti che hanno a cuore la sicurezza e hanno un certo livello di conoscenza.

qualsiasi utente è target

Nei casi in cui viene tentato un numero molto elevato di accessi, gli aggressori spesso scelgono una password fissa e forza bruta i nomi degli account. Ciò significa che non verrà attivata una soglia di tre tentativi di accesso per account.

Pertanto, i tentativi di accesso falliti devono essere monitorati su base multipla, ad esempio in base agli indirizzi IP.

blocco di un numero elevato di utenti

L'implementazione delle misure dei contatori menzionate sopra crea una nuova vulnerabilità: un utente malintenzionato può bloccare un numero elevato di account. In alcuni casi ciò potrebbe causare danni molto maggiori a un sito rispetto a un numero limitato di account compromessi.

Il conteggio basato su IP può aiutare a mitigare questo vettore di attacco. Oppure può dare una leva in situazioni in cui molte persone si trovano dietro lo stesso server proxy (in un'università, in una wlan pubblica, ecc.)

blocco di un account specifico

Oltre all'ultima sezione, un utente malintenzionato può tentare di bloccare un account specifico. Ad esempio qualcuno che sta facendo un'offerta contro di loro su un'asta.

Potrebbe essere possibile utilizzare un secondo canale per consentire al proprietario dell'account di riattivare il suo account. Ad esempio inviando un messaggio di testo o un'email con un codice.

Mi piace la risposta di Thomas Pornin. La mia unica aggiunta sarebbe: quando crei una funzione di blocco della password, devi capire come supportare la tua base di utenti e bilanciarla con il rischio di errori.

In un sistema di sicurezza elevato con un numero limitato di utenti esperti di sicurezza, amministratori dedicati e un grande budget per il supporto degli utenti, l'abilitazione di una password bloccata può essere manuale e può richiedere una nuova autenticazione attraverso un canale secondario che è costoso e richiede tempo.

In un sistema a bassa sicurezza con una base di utenti enorme (e forse anche analfabeta informatico) - come Google o Hotmail - il rischio di un'interruzione è probabilmente annullato dalla spesa di supportare lo sblocco dell'account attraverso qualsiasi cosa eccetto un automatizzato, molto semplice, processo.

Ho visto sistemi così semplici, che tutto ciò che hanno fatto è stato forzare la chiusura del browser quando sono state raggiunte 3 password errate. Leggermente migliore è il sistema proposto da Thomas con un timeout su account disabilitati. Secondo la mia esperienza, i sistemi fanno questo per fornire una barriera moderata agli attacchi bruteforce mentre bilanciano le esigenze di tonnellate di utenti che stanno tentando di accedere ai propri account.

È vero che non è l'approccio migliore, ma i sistemi devono trovare un modo per rallentare gli attacchi senza trattare gli utenti faccia a faccia, poiché ogni chiamata di supporto costa il denaro del provider, quindi con servizi gratuiti come Gmail, ottieni per cosa paghi.

Suggerisco di non bloccare solo un profilo utente che riceve troppe password errate ... ma anche di bloccare l'IP di una macchina che riceve troppe password errate (eventualmente con più account).

Uso DenyHosts sulle mie macchine Linux per bloccare gli IP che provano a indovinare le password.

Penso che dovresti consentire all'utente di determinare come "casuale" sia la sua password.

Per alcune "password", non ha senso porre un limite: alcuni utenti generano automaticamente le loro "password" (rendendole impossibili da ricordare) e le conservano in un file, quindi queste password sono più simili a cripto chiavi rispetto alle normali password.

Credo che permetta all'utente di scegliere quanti tentativi prima che l'account ottenga 10 s, 30 s, 1 minuto di penalità per il tempo di accesso e quanti prima che l'account sia bloccato per 1 ora, 12 ore, 1 giorno , con o senza ricorso a CAPTCHA costringerebbe l'utente a pensare di più sulla forza della propria password.

Quindi non stai dando un po 'di libertà alle persone, stai forzando questa libertà sugli utenti : ogni utente dovrebbe scegliere una politica di blocco.

Anche un utente dovrebbe avere il permesso di collegare il suo account ad alcuni RBL per impedire l'accesso da relé SOCKS aperti o da uscite Tor (per impostazione predefinita non è stato sottoscritto un abbonamento a RBL).

Per le applicazioni Web, un utente dovrebbe avere il diritto di scegliere tra un'autenticazione basata su HTTP pura (HTTP-auth, cookie, ...) o un'autenticazione basata su IP basata su HTTP (legando un utente loggato a un indirizzo IP) (impostazione predefinita solo per l'autenticazione basata su HTTP, nessuna associazione indirizzo IP).

Penso che dovresti dare aggressivamente libertà e responsabilità agli utenti. In questo modo non possono piangere nei forum quando sono stati violati, dicendo che la password impostazione del sistema era debole, insicura, non professionale ...

Dipende molto dal tipo di account che l'utente sta tentando di accedere. Gli account di posta elettronica basati sul Web sono il solito esempio in cui l'e-mail è il nome utente, tuttavia in altri casi è meglio non utilizzare l'e-mail come nome utente, pertanto l'utente malintenzionato non avrà le credenziali dell'utente in primo luogo per scomporre la password .

Qualsiasi forma di blocco dell'account senza captchas o qualche altra forma di prevenzione POST di massa può portare a un Denial of Service in cui viene utilizzato uno strumento di attacco per inviare più richieste con l'espresso scopo di causare blocchi di account.

Usando non-mail o nomi è lo standard con gli accessi agli account del sito web come Godaddy e altri, e anche gli accessi al conto bancario, ad esempio, sebbene questi tendano ad essere stringhe numeriche che li aprono agli attacchi di tipo denial of service tramite massa attacchi di forza bruta su blocchi di numeri.

es: utente: 1000000 ++ passare: a-zA-Z0-9

Un attacco che invia 4 tentativi su un nome utente sequenziale in cui la banca ha impostato l'utente come un intervallo di numeri come 48829387 potrebbe facilmente consentire a un utente malintenzionato di negare l'accesso a una vasta gamma di utenti bancari superando il limite consentito richieste di password a numeri casuali tra le gamme di dire 4000000 e 4999999.

Nella maggior parte delle situazioni di accesso al web, tuttavia, avere utenti che scelgono un nome utente separato per il loro nome o indirizzo e-mail chiede un po 'di più, ed è probabilmente il motivo per cui le banche usano spesso le stringhe numeriche come nomi utente.

Quindi se i nomi utente difficili non sono disponibili come opzione, quindi prevenire il martellamento del dizionario è la prossima porta di chiamata o l'uso di captcha o anche javascript impegnativo prima di stabilire sessioni, poiché spesso questi strumenti di attacco di tipo dizionario non hanno la capacità di affrontare restituire i cookie e solo i sessons stabiliti dopo il rilevamento di javascript.