Domanda:
Implicazione sulla sicurezza di dire all'utente che non può accedere a causa di troppi tentativi dall'IP
Goose
2017-05-31 21:35:47 UTC
view on stackexchange narkive permalink

Nello scambio di stack di Code Review, in risposta al codice che informa l'utente quando il tentativo di accesso non è riuscito a causa di troppi tentativi di accesso da un IP, mi è stato detto

"Assolutamente non inviare messaggi all'utente finale dicendo loro perché l'accesso non è riuscito. Stai fornendo a un potenziale attaccante informazioni critiche per aiutarlo ad attaccare la tua applicazione. Qui fornisci a un attaccante informazioni molto precise per aggirare la tua restrizione IP. "

https://codereview.stackexchange.com/a/164608/93616

Sto praticando una cattiva sicurezza? Devo spiegare in termini più vaghi come "Troppi tentativi di accesso" o "Non è stato possibile accedere"?

Aggiornamento : in caso di ambiguità, attualmente i troppi La logica dei tentativi e il messaggio non si preoccupano se i tentativi hanno avuto successo o meno.

Il "assolutamente non" è troppo forte.La sicurezza è un compromesso con l'usabilità.Come controargomentazione, Google ti dirà volentieri quando troppe domande sospette sono state fatte dal tuo indirizzo IP e ho trovato che un'informazione molto utile in molti casi.Se Google può farlo, puoi farlo anche tu se ritieni che aiuterà i tuoi utenti più che gli aggressori.In caso contrario, non farlo.
"Assolutamente non inviare messaggi all'utente finale dicendo loro perché l'accesso non è riuscito."- Penso che questa affermazione sia più mirata a non restituire informazioni come "Questo account non esiste nel sistema".Un utente malintenzionato può utilizzare le varie risposte alle richieste di accesso per determinare se nel sistema esiste un account utente specifico.In altre parole, la risposta di accesso dovrebbe essere la stessa indipendentemente dal fatto che l'account esista e / o la password fornita non sia corretta.
Vorrei utilizzare un proxy anonimo per ottenere un nuovo indirizzo IP ogni richiesta, quindi qual è il punto di blocco tramite IP?Dovresti bloccare l'autenticazione errata tramite nome utente
@NeilMcGuigan Questo blocca solo gli attacchi in una singola dimensione.Non si blocca contro un bot che prova una password comune tra migliaia di nomi utente.
@Xander corretto.Puoi anche bloccare le password non riuscite
@NeilMcGuigan No, non allo stesso modo, per diversi motivi.
un utente malintenzionato può capirlo abbastanza rapidamente comunque, non è un grande segreto ...
@schroeder Dal momento che non posso commentare la mia risposta cancellata per rendere il mio caso, lo farò qui.Mi scuso per non essere stato abbastanza bravo a trasmettere chiaramente la mia risposta.Era sicuramente destinato a rispondere alla domanda.Stavo fornendo alcuni esempi concreti di dove potrebbero verificarsi falsi positivi, che altre risposte non hanno ancora fatto, per chiarire quanto sarebbe comune.Stavo quindi collegando questo con la frase finale della risposta alla domanda: se neghi i tentativi di accesso senza spiegazione da IP bloccati, tutti questi falsi positivi si chiederanno cosa sta succedendo.
Cinque risposte:
#1
+80
Arminius
2017-05-31 23:39:54 UTC
view on stackexchange narkive permalink

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:

avere un voto positivo per il captcha "soft lock"
#2
+14
Jon Bentley
2017-05-31 22:28:29 UTC
view on stackexchange narkive permalink

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.

Nota che Alice non può verificare accuratamente la password corretta a meno che il controllo della password, con il messaggio di ritorno, non avvenga prima dei controlli "troppi tentativi".L'ordine inverso fornisce meno informazioni, consentendo solo ad Alice di distinguere le password "errate" da quelle "sconosciute".Che è ancora una quantità indesiderabile di informazioni da fornire a un aggressore.
Questa risposta presume "password errata" ma il messaggio "accesso non riuscito" significa in realtà solo "nome utente errato o password errata per quel nome utente".(Potrebbe esserci un attacco di canale laterale se il nome utente errato viene rifiutato in precedenza, ma è noto per randomizzare il tempo di attesa per un messaggio di accesso non riuscito)
@MSalters Vero, ma non influisce sulla mia risposta.In ogni caso, l'effetto su un aggressore di forza bruta è lo stesso: con un messaggio generico non possono distinguere tra credenziali corrette e non corrette e devono trattarle entrambe allo stesso modo.Le differenze tra un messaggio "Password errata" e "Accesso non riuscito" sono un problema separato di sicurezza e usabilità.Modificherò la mia risposta per renderla più chiara.
#3
+13
Dan Landberg
2017-05-31 21:48:04 UTC
view on stackexchange narkive permalink

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.

Questa risposta ha senso.Cosa devo dire all'utente quando raggiunge il limite?Vorrei evitare di coinvolgere CloudFlare a questo punto.
La raccomandazione arriva anche dagli sviluppatori che non sono sempre coerenti con gli errori che mostrano.Devi stare attento anche a questo.Ad esempio, se sto tentando di forzare la password di un utente e ricevo messaggi "Informazioni di accesso errate", ma poi ricevo l'errore "Troppi tentativi da questo IP".Saprò di aver vinto il jackpot con la password anche se non ho effettuato l'accesso.
Gran parte della tua formulazione dipenderà dalla raffinatezza dei tuoi utenti.Qualcosa del tipo "Impossibile accedere adesso. Riprova più tardi a eseguire la richiesta".Se vuoi che sia il più sicuro, dovresti evitare di elencare un limite di tempo specifico, poiché un utente malintenzionato riavvierebbe i suoi tentativi dopo tale limite di tempo. Onestamente, un aggressore intelligente capirà cosa sta succedendo.Consiglio vivamente di utilizzare un servizio di terze parti per questo.Puoi dedicare un'enorme quantità di tempo a codificare una correzione per questo e un utente malintenzionato troverà un modo per ingannare il sistema.
@kotzu Non seguo la tua logica."Troppi tentativi da questo IP" significa troppi tentativi * sbagliati *, non "Hai avuto alcuni tentativi sbagliati seguiti da un tentativo corretto, ma ti bloccheremo perché il tentativo corretto ti ha messo oltre il limite".
@Jon Bentley - Sì, questo è esattamente il mio punto.quello che dici sarebbe il modo giusto per mostrare il messaggio.Ma a volte ho visto un'applicazione con una logica imperfetta che consente all'aggressore di sapere quando ha colpito la password giusta essendo incoerente con i messaggi di errore.
@JonBentley Ma assicurati di non testare solo i tentativi sbagliati ... In caso contrario, il tuo aggressore di forza bruta ottiene un errore di limite di velocità, un errore di limite di velocità, un errore di limite di velocità, quindi un accesso riuscito e non si ottiene alcuna sicurezzaqualunque cosa.
Cloudflare significa addio sicurezza.è fondamentalmente * MitM as a Service. *
@SargeBorsch Dipende davvero dal modello di minaccia.Se stai cercando di difenderti dagli aggressori dello Stato nazionale, sì, probabilmente ti rende più debole.Per la maggior parte delle applicazioni, fornisce un significativo miglioramento della sicurezza in termini di prevenzione DDoS, WAF e altre funzionalità.
@user52472 Cloudflare è comunque un pericolo, perché hanno anche dimostrato la loro incompetenza.(vedi Cloudbleed hole)
#4
+5
Kirill Sinitski
2017-05-31 22:04:31 UTC
view on stackexchange narkive permalink

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.

#5
+2
Serge Ballesta
2017-05-31 22:43:19 UTC
view on stackexchange narkive permalink

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.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...