Implicazione della sicurezza di dire all'utente che non possono accedere a causa di troppi tentativi da IP

Absolutely do not message end user telling them why login failed. You are giving a potential attacker critical information to aid them in attacking you application.

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

Se non si chiarisce se l'IP dell'utente è stato bannato o se l'utente ha usato una password errata, potrebbe entrare in panico poiché sembra che qualcuno abbia effettuato l'accesso al proprio account e abbia modificato la password per bloccarli. Se il mio login con una password pre-compilata fallisce, la prima cosa a cui sto pensando è un break-in piuttosto che un blocco IP.

Inoltre, un ingenuo meccanismo di blocco IP potrebbe essere inefficace e introdurre ulteriori problemi. È potenzialmente banale da bypassare per un utente malintenzionato con risorse sufficienti e qualcuno che condivide un indirizzo IP con altri utenti potrebbe abusare del divieto IP di 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 norma vietare un indirizzo IP se vengono effettuati troppi tentativi di accesso?
• Perché le persone utilizzare l'indirizzo IP vieta quando gli indirizzi IP cambiano spesso?

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

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

Ma se Bob non cambia il messaggio? Alice continuerà con la forza bruta e continuerà ad ottenere il "tentativo di accesso fallito" generico su ogni tentativo anche se le credenziali sono corrette . Se dovesse capitare di provare le credenziali corrette, Bob rifiuterà il tentativo perché il limite IP è stato superato, ma Alice non saprà che questa è la ragione e dovrà trattarla come un tentativo errato (a meno che non abbia qualche altro modo di sapere che va oltre lo scopo di questa domanda). La sua unica opzione è continuare con la ricerca, ignorando se ha già individuato e spostato le credenziali corrette.

Tieni presente che questo vantaggio è sicurezza attraverso l'oscurità poiché si basa su Alice che non conosce i criteri di blocco IP di Bob. A seconda della configurazione, questa informazione potrebbe essere banale da ottenere. Ad esempio, se Alice ha accesso a un altro account sul sistema (facile se accetta la registrazione dell'account pubblico), allora può usare tentativi ed errori per vedere se un tentativo corretto alla fine viene rifiutato dopo troppi tentativi sbagliati.

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" a un utente standard. Va anche notato che ogni attaccante esperto inizierà a notare un tipo di risposta mutevole, o una differenza temporale, e probabilmente riuscirà a capire cosa sta succedendo, comunque.

Potresti prendere in considerazione l'idea di utilizzare un servizio come CloudFlare. Hanno un'API scriptable 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 usando le funzioni di Azure.

In questo caso, la sicurezza e l'usabilità sono obiettivi contrari. Mentre l'implementazione più sicura non offrirebbe feedback, sarebbe anche meno user-friendly. Devi decidere in che misura il tuo sistema è suscettibile di brutalizzare gli accessi, quali altre attenuazioni sono presenti e quanto sia efficace la mitigazione specifica quando viene valutata contro gli inconvenienti dell'utente.

Ad esempio, se stavo progettando il login per un dispositivo consumer, lo renderei il più user-friendly possibile, avendo un feedback dettagliato e introducendo ulteriori mitigazioni per compensare. Se stessimo progettando l'accesso HSM, non offrirò feedback e timeout onerosi su tutto il 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 i tentativi legittimi e in cui non ci si fida della robustezza dell'applicazione, è necessario proteggerlo da qualsiasi cosa possa essere un attacco e non dire mai perché rifiuti un accesso.

Se stai costruendo un'applicazione professionale e ti aspetti che gli accessi professionali non limitino gli accessi da un singolo IP se la tua applicazione è abbastanza robusta. Se lo fai, assicurati di informare l'utente del motivo e imposta una hot line ragionevolmente reattiva (al massimo 1 giorno lavorativo per leggere e comprendere un messaggio, e avviare un'azione correttiva se necessario) ). Perché è comune per le grandi organizzazioni configurare un singolo proxy in uscita per tutti i loro accessi HTTP e HTTPS. Potresti avere migliaia di dipendenti in diversi luoghi in 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 cambiarlo rapidamente se uno dei tuoi clienti fa evolvere la sua rete e cambia il suo indirizzo proxy.