Assolutamente non inviare messaggi all'utente finale spiegando loro perché il login non è riuscito. Stai fornendo a un potenziale aggressore informazioni critiche per aiutarlo ad attaccare la tua applicazione.

D'altra parte, non dire a un utente perché il suo accesso non è riuscito è un potenziale disastro dell'usabilità.

Se non si chiarisce se l'IP dell'utente è stato bannato o se l'utente ha invece utilizzato una password sbagliata, potrebbero farsi prendere dal panico poiché sembra che qualcuno abbia effettuato l'accesso al proprio account e abbia cambiato la password per bloccarlo. Se il mio accesso con una password precompilata non riesce, la prima cosa a cui penso è un'irruzione piuttosto che un blocco IP.

Inoltre, un meccanismo ingenuo di blocco IP potrebbe essere inefficace e introdurre ulteriori i problemi. È potenzialmente banale aggirare un utente malintenzionato con risorse sufficienti e qualcuno che condivide un indirizzo IP con altri utenti potrebbe abusare del divieto IP per escludere altri. Invece, un CAPTCHA dopo n tentativi falliti per IP potrebbe essere una soluzione più morbida e più appropriata per la tua applicazione.

Vedi anche:

• È buona pratica vietare un indirizzo IP se vengono effettuati troppi tentativi di accesso da esso?
• Perché le persone utilizzano il divieto degli indirizzi IP quando gli indirizzi IP cambiano spesso?

C'è un vantaggio in termini di sicurezza nel fornire messaggi generici che non sono stati menzionati.

Alice sta tentando di forzare un account sul server di Bob. Per i primi tentativi Alice riceve il messaggio "Tentativo di accesso fallito". Al prossimo tentativo ottiene "Troppi tentativi di accesso da questo indirizzo IP". Ora è consapevole che (a) tutte le credenziali che ha provato fino a questo punto non erano valide e (b) ha bisogno di fare qualcosa di diverso prima di fare altri tentativi.

Ma cosa succede se Bob non cambia il messaggio? Alice continuerà con la forza bruta e continuerà a ricevere il generico "Tentativo di accesso non riuscito" a ogni tentativo anche se le credenziali sono corrette . Se le capita di provare le credenziali corrette, Bob rifiuterà il tentativo perché il limite IP è stato superato, ma Alice non saprà che questo è il motivo e dovrà trattarlo come un tentativo errato (a meno che non ne abbia altri modo di sapere quale è oltre lo scopo di questa domanda). La sua unica opzione è continuare con la ricerca, ignara se ha già individuato e superato le credenziali corrette.

Tieni presente che questo vantaggio è la sicurezza attraverso l'oscurità poiché fa affidamento sul fatto che Alice non conosca la politica di blocco IP di Bob. A seconda della configurazione, queste informazioni potrebbero essere banali da ottenere. Ad esempio, se Alice ha accesso a un altro account sul sistema (facile se accetta la registrazione dell'account pubblico), può utilizzare tentativi ed errori per vedere se un tentativo corretto alla fine viene rifiutato dopo troppi tentativi errati.

Altre risposte hanno spiegato il compromesso tra sicurezza e usabilità, quindi non mi preoccuperò di ripeterlo.

Sì, tecnicamente stai restituendo informazioni che potrebbero essere utilizzate da un utente malintenzionato per mettere a punto una botnet di forza bruta. Inoltre, non sono sicuro di quanto sia utile il messaggio di errore "A molti tentativi di accesso da questo IP" per un utente standard. Va anche notato che qualsiasi attaccante esperto inizierà a notare un cambiamento del tipo di risposta o una differenza di tempo, e probabilmente capirà cosa sta succedendo, comunque.

Potresti prendere in considerazione l'utilizzo di un servizio come CloudFlare. Hanno un'API con script che può inserire dinamicamente una pagina interstitial o aggiornare una regola WAF in determinati scenari. Troy Hunt ha un buon tutorial in cui lo fa per Windows Azure utilizzando Funzioni di Azure.

In questo caso, sicurezza e usabilità sono obiettivi contrari. Sebbene l'implementazione più sicura non offrirebbe feedback, sarebbe anche meno user-friendly. Devi decidere quanto è suscettibile il tuo sistema alla forzatura forzata degli accessi, quali altre mitigazioni sono in atto e quanto sia efficace la mitigazione specifica quando viene valutata contro il disagio per l'utente.

Ad esempio, se stessi progettando l'accesso per un dispositivo di consumo Lo renderei il più user-friendly possibile avendo un feedback dettagliato e introdotto ulteriori mitigazioni per compensare. Se stessi progettando l'accesso HSM, non offrirei feedback e timeout onerosi a livello di dispositivo.

Tutto dipende da cosa stai costruendo. Se si tratta di un blog o di qualsiasi altro sito di fantasia in cui non è davvero importante rifiutare tentativi legittimi e in cui non ti fidi veramente della robustezza dell'applicazione, dovresti davvero proteggerlo da tutto ciò che potrebbe essere un attacco e non dire mai perché rifiutate un login.

Se state creando un'applicazione professionale e vi aspettate accessi professionali, non limitate gli accessi da un singolo IP se la vostra applicazione è abbastanza robusta. Se lo fai, assicurati di informare l'utente del motivo e di impostare una hot line ragionevolmente reattiva (al massimo 1 giorno lavorativo per leggere e comprendere un messaggio e per avviare un'azione correttiva se necessario ). Perché è comune per le grandi organizzazioni impostare un unico proxy in uscita per tutti i loro accessi HTTP e HTTPS. Potresti avere migliaia di dipendenti in diverse località di un paese, tutti utilizzando apparentemente lo stesso indirizzo IP. Una lista bianca che consente connessioni illimitate da proxy noti è sufficiente, ma devi essere pronto a cambiarla rapidamente se uno dei tuoi clienti fa evolvere la sua rete e cambia il suo indirizzo proxy.