Politica di sicurezza del blocco dell'account (nome utente / password)

Non c'è una risposta giusta o sbagliata. Il criterio di blocco più aggressivo è leggermente più sicuro e leggermente meno conveniente per i tuoi utenti. Devi valutare se vale la pena fare in base ai requisiti della tua applicazione, alla tua conoscenza della tua base di utenti, al valore della risorsa che stai proteggendo, al tuo modello di minaccia, ecc. Ecc.

Ricorda sempre che potrebbero esserci degli idioti che stanno cercando di DOS qualcuno che non gli piace cercando intenzionalmente di bloccare il proprio account usando l'account email conosciuto.

Sì, l'account deve essere bloccato.

Il motivo è che l'accesso riuscito potrebbe provenire dall'utente reale e gli accessi non riusciti potrebbero essere di un utente malintenzionato. Il fatto che l'utente reale abbia effettuato il login non deve resettare il contatore per l'attaccante. Ovviamente è possibile tenere traccia delle sessioni e bloccare l'utente solo se si trovano su una sessione diversa rispetto all'utente reale, tuttavia qui vi è un rischio maggiore di bug di implementazione che significa che è possibile introdurre inavvertitamente qualcosa che consente a un utente malintenzionato di aggirare il blocco. Con la sicurezza è spesso meglio mantenere le cose il più semplici possibile.

Dovresti anche valutare i tentativi limitati ripetuti dallo stesso indirizzo IP che ti aiuteranno a proteggere da un attacco orizzontale contro account utente diversi.

Quanto sopra è un commento sulla tua proposta attuale, tuttavia vorrei anche una risposta sempre più ritardata piuttosto che bloccarla.

per es.

Login Attempt              Artificial Delay
1                          0
2                          1 second
3                          2 seconds
4                          4 seconds
5                          8 seconds

In questo modo l'utente reale sarà in grado di accedere durante una forza bruta sul proprio account e l'utente malintenzionato non può causare un Denial of Service all'utente legittimo. Per ritardi più lunghi è possibile visualizzare all'utente qualcosa che mostri che il loro accesso è in corso in modo da non essere tentato di fare nuovamente clic. Ovviamente non si desidera che il ritardo massimo sia molto più lungo di alcuni secondi, tuttavia l'aggiunta di un ritardo artificiale attraverso i thread ritarderà l'aggressore. La differenza tra il rallentamento dell'accesso e la visualizzazione di un messaggio bloccato è che l'utente reale non dovrà continuare a inviare i propri dati di accesso: devono solo essere pazienti mentre il login è stato completato.