Domanda:
La visualizzazione del conteggio dei tentativi rimanenti della password rappresenta un rischio per la sicurezza?
Ahmet Arslan
2019-01-16 14:11:53 UTC
view on stackexchange narkive permalink

Alcuni siti web visualizzano un conteggio rimanente di tentativi di password quando inserisco password errate più di due volte. Ad esempio, mostrando che ci sono 3 tentativi rimanenti fino al blocco del mio account. È pericoloso dal punto di vista della sicurezza?

Una considerazione è che questo può facilmente rivelare se un nome utente esiste sul sito.Questo potrebbe essere indesiderabile se i nomi utente sono email e il sito è qualcosa di personale come foot-fetish.com Puoi evitarlo restituendo un numero falso per account inesistenti
Sarebbe così incredibilmente difficile per un hacker contare il numero di tentativi falliti prima di ricevere il messaggio di account bloccato?Con questa logica dovresti chiederti se la visualizzazione del messaggio "Account bloccato" è un rischio per la sicurezza.
@MonkeyZeus Ma con un numero visualizzato, l'hacker sa quando fermarsi prima che l'account venga bloccato e il tentativo fallito venga notato.Possono quindi attendere un po 'di tempo fino a quando il proprietario non ha effettuato l'accesso e azzera il contatore.
@BlackJack Non necessariamente.Se l'utente ha effettuato 2 tentativi subito prima che l'hacker facesse il primo tentativo, spero davvero che non pensi che un singolo errore si traduca in un account bloccato.In ogni caso nessun modello di minaccia è stato menzionato da OP, quindi congetture aperte come questa non fanno davvero nulla ...
Perché nessuno ha considerato che il conteggio dei tentativi potrebbe essere basato sul riconoscimento dell'ip o del dispositivo?
@Nightwolf Questo è quello che stavo pensando anche io, invece del nome dell'account.
Non bloccare gli account, blocca l'indirizzo IP che sta effettuando i tentativi di accesso non riusciti.[fail2ban] (http://www.fail2ban.org) è il tuo amico lì.
@paj28 Non credo che risolva il problema che hai menzionato.Tutto ciò che fa è estendere il problema a ogni possibile indirizzo di posta elettronica (per quanto ne sa l'attaccante)
no no no ... NON bloccare gli IP per gli accessi al SITO WEB.SSH?Sicuro.Ma molte aziende / scuole / complessi di appartamenti / hotel / ecc. NAT tutto il loro spazio interno attraverso un singolo IP e potresti bloccare un sacco di utenti non affiliati bannando tramite IP.
@nightwolf perché è un'idea terribile che è banalmente superabile (ad esempio se eseguita da cookie) o potrebbe portare a un diniego del servizio contro qualcuno (ID dispositivo tramite indirizzo mac, ad esempio) o a un sacco di qualcuno (indirizzo IP).
@RobMoir La pratica di bloccare l'IP può funzionare per proteggere dai tentativi di forza bruta bloccando l'IP per 5 minuti.Visualizzare un conteggio di quanti tentativi disponibili prima del ban temporaneo sembra del tutto ragionevole, così come il tempo rimanente del ban.Se un utente legittimo riceve un IP abusato, gli verranno negati al massimo 5 minuti e quindi sarà chiaro a procedere.Questo ovviamente dipende dal tuo modello di minaccia.
@Nightwolf Lo capisco.Ma come affronti le questioni che io e Angelo abbiamo segnalato?Potrei banalmente bloccare circa 7500 persone dall'utilizzo del tuo servizio con uno sforzo minimo se stai bloccando tramite indirizzo IP.
@RobMoir Quindi il mio suggerimento è semplicemente notare che attualmente esiste un blocco temporizzato e per accedere è richiesta l'autenticazione a due fattori (collegamento e-mail e password / cellulare e password) fino alla scadenza del blocco temporizzato.
Un avversario può semplicemente controllare il conteggio dei tentativi scegliendo un altro utente casuale e possibilmente un altro indirizzo IP.È molto probabile che la maggior parte degli utenti abbia raggiunto il numero massimo di tentativi rimasti dopo tutto, poiché si disconnetterebbero solo dopo aver effettuato l'accesso. Se la "fuga" di queste informazioni rendesse il tuo sistema vulnerabile, saresti nei guai, indipendentemente dal fatto che tu lo visualizzi onon.
Otto risposte:
#1
+147
Sean Werkema
2019-01-16 21:52:42 UTC
view on stackexchange narkive permalink

Innanzitutto, bloccare gli account è una cattiva idea. Potrebbe sembrare che tu stia rendendo la tua organizzazione più sicura tenendo lontani i "cattivi" che "indovinano" le password usando la forza bruta attacchi, ma cosa hai veramente risolto? Anche con questa politica e una base di utenti perfetta che non commette mai errori di sicurezza, un utente malintenzionato può eseguire un attacco Denial of Service alla tua organizzazione utilizzando ripetutamente la password "aaa" per bloccare gli account degli utenti critici. Considera cosa succede se il tuo aggressore ottiene una copia dell'elenco dei nomi utente per l'intero reparto IT: all'improvviso, l'IT stesso, l'organizzazione che altrimenti sarebbe in grado di sbloccare altri utenti, viene a sua volta completamente chiuso.

Considera sempre qual è il modello di minaccia prima di implementare una policy. Un "cattivo" determinato a danneggiare la tua organizzazione troverà vettori di attacco alternativi. La tua politica di blocco non sconvolgerà nemmeno un attore di uno stato nazionale (come Russia, Cina o NSA); un hacker determinato troverà semplicemente altri modi per aggirarlo (come l'ingegneria sociale); e danneggerà solo gli utenti legittimi del tuo servizio, non importa quanto alto o basso imposti il ​​contatore di blocco.

Morale della storia: non bloccare gli account. , fai quello che fa Apple con l'iPhone: ogni tentativo di accesso raddoppia il ritardo di accesso, in modo che dopo una dozzina di errori o giù di lì, devi aspettare un'ora tra ogni tentativo successivo. È abbastanza lungo da impedire ai "malintenzionati" di eseguire attacchi di forza bruta, ma comunque abbastanza breve da consentire a un utente legittimo di dedicare quell'ora a capire quale fosse la propria password e a digitarla correttamente dopo pranzo o a contattare l'IT chiedendo scusa aiuto . (Allo stesso modo, i criteri di "inondazione" possono spesso essere implementati a livello di indirizzo IP nel firewall, non solo a livello di account utente nel software, se sei preoccupato per un attaccante dedicato che cerca di forzare molti account diversi .)

E se non blocchi gli account, non è necessario avere un contatore o visualizzarlo .

[ vedi anche: questa eccellente risposta a una domanda simile ]

Consiglio solido.Anche se continuo a chiamare questo blocco degli account, è solo con un breve timeout
Sono d'accordo con questo per le implementazioni blocca e dimentica, ma i blocchi di breve durata (si sbloccano automaticamente dopo pochi minuti) possono essere utili per attacchi di forza bruta con limitazione della velocità.
A meno che tu non possa permetterti un monitoraggio attivo 24 ore su 24, 7 giorni su 7, 365 giorni l'anno da parte di esseri umani vivi per il tuo servizio - abbastanza esseri umani vivi per affrontare lo scenario peggiore anche alle 3 del mattino del giorno di Natale - la tua implementazione _è_ una qualche forma di set-it-e dimenticalo, quindi non dovresti ancora utilizzare i blocchi degli account.E questo è praticamente ogni servizio là fuori.
E non dimenticare che alcuni di noi sono * obbligati * da una serie di leggi ancora più folli per applicare blocchi per tentativi di accesso falliti.C'è una ragione per cui anche il NIST include una clausola di blocco "deve" (generosamente alta a 100 tentativi).Perché il più delle volte è il governo che ci richiede di fare le serrate.
Ma dovresti avere un display che informi l'utente di quanto tempo sarà il ritardo di accesso per il prossimo tentativo?
Vorrei visualizzare un captcha per un utente che ha molti tentativi di accesso falliti.Dovrebbe fermare la maggior parte degli abusi.
Aumentare gradualmente i tempi di blocco è una cosa sensata da fare su un dispositivo fisico.Ma non si dovrebbe ancora farlo su un account a cui è possibile accedere tramite Internet.L'aggressore può continuare a inviare tentativi di password anche mentre l'account è bloccato e ogni volta che il blocco scade l'utente legittimo avrà solo un breve periodo di tempo durante il quale potrà accedere prima che l'attaccante lo blocchi nuovamente.Blocca invece gli indirizzi IP e blocca i prefissi se più indirizzi in un prefisso sono stati bloccati.
Quell'attacco DoS "aaa" è specifico in modo interessante.Non ti capita di avere una storia reale di un attacco del genere, vero?Forse un puntatore di riferimento per me da cercare?Mi piacerebbe leggerlo.
@MichaelEricOberlin: Aneddoticamente, abbiamo avuto un caso di un utente con un account costantemente bloccato.Dopo molte ore trascorse a indagare, si è scoperto essere un collega / nemesi dell'utente che continuava a farlo per dispetto dell'utente.Non era su scala aziendale, ma non richiede nemmeno competenze esperte per escludere qualcuno che desideri.
Lo stesso principio del blocco non funziona con Apple, dove puoi effettivamente aumentare il contatore dei blocchi fino a quando le persone non possono accedere per un periodo di tempo significativo?Forse non permanente, ma pur sempre una negazione del servizio di forte impatto, no?
Per un sistema online, raddoppiare il tempo di blocco non * realmente * aiuta più di tanto.Essere bloccato con l'intero reparto IT per un paio di giorni è già abbastanza, ma non è nemmeno così difficile ripetere il tuo attacco a intervalli crescenti, mantenendo il tuo team bloccato più o meno a tempo indeterminato.
@kasperd il lucchetto potrebbe essere legato a un IP specifico piuttosto che connesso all'account, no?Basta scartare il traffico di quel tipo da quella fonte piuttosto che interagire con essa.
Blocciamo gli account dove lavoro ma utilizziamo anche un servizio per bloccare dispositivi e indirizzi IP specifici per prevenire la situazione qui descritta .. o almeno prevenirla in un modo che ci sta a cuore.Si applica solo agli account esterni che accedono al servizio che forniamo e non agli account dei dipendenti interni.Gli account interni possono essere ripristinati e indagati facilmente qui.Ma il punto è che esistono servizi in grado di bloccare IP e dispositivi sospetti, quindi il blocco non dovrebbe essere universalmente scontato.
(1) Un sistema di sicurezza che blocca gli account senza un modo "magico" di entrare (ad esempio, gli accessi alla console non vengono mai bloccati, perché il server è fisicamente protetto) è, ovviamente, fondamentalmente guasto.Quindi dovremmo presumere che, anche se un utente cattivo (o malizioso) blocca gli account del personale IT, avrà comunque un modo per entrare.Quindi, come dicono [Flater] (https://security.stackexchange.com/q/201566/34757#comment404075_201596) e [Jasper] (https://security.stackexchange.com/q/201566/34757#comment404086_201596),non è altrettanto grave bloccare il personale IT per un'ora?... (segue)
(Continua) ... (2) Mi sembra che la tua ultima frase non abbia molto senso.Se raddoppi il ritardo di accesso dopo ogni tentativo fallito, stai ancora tenendo traccia degli accessi falliti.Il fatto che tu stia memorizzando * 2 ^ n * invece di * n * non lo rende davvero un contatore.
@SeanWerkema Se il ritardo di accesso è troppo alto e c'è un attacco di negazione del servizio in corso, così tante richieste saranno in coda che il server non potrà più accettare una nuova richiesta.Non è questa una possibilità?
@Andrew Il mio commento ha suggerito di bloccare gli indirizzi IP (e in alcuni casi i prefissi).Ma sicuramente non scartare il traffico.Si dovrebbe comunque rispondere con un messaggio di errore appropriato, ma non provare a convalidare nome utente o password prima di inviare il messaggio di errore se l'IP del client è in un intervallo bloccato.
Raddoppiare il tempo di accesso è meglio che bloccare gli account a titolo definitivo, ma è comunque una negazione del servizio.Affrontare un tempo di accesso che raddoppia non è davvero un grosso inconveniente per un avversario che automatizza il processo di accessi fasulli.
"un attore di uno stato nazionale (come Russia o Cina o NSA)" - Interessante insieme di * nazioni *.
Per quanto riguarda gli utenti amministratori DoS'ing, questi account potrebbero essere protetti in un modo diverso, ad es.whitelist agli IP dell'azienda.
@Scott: Ho usato per eseguire una password di root vuota con quella teoria dietro di essa.Avevo truccato in modo sicuro in modo che gli accessi remoti come root non fossero semplicemente possibili.
I blocchi a livello IP di @kasperd influenzeranno le persone che utilizzano una VPN per accedere al tuo servizio (lo ricevo regolarmente, poiché utilizzo regolarmente una VPN ed è molto fastidioso).
Ricordo che al liceo i ragazzi si chiudevano a vicenda indovinando la password sbagliata.Qualcuno è diventato furbo e ha bloccato anche l'insegnante in modo che non potesse sbloccare gli account.Sono sicuro che alcuni lo hanno fatto apposta per avere una scusa per non lavorare, anche se presumibilmente la maturità dovrebbe essere aumentata nel momento in cui le persone entrano nel posto di lavoro.
@LoganPickup VPN non ha nulla a che fare con questo.Il problema è piuttosto due altre cose: ** 1. ** Potresti aver scelto di utilizzare un fornitore che ha molti clienti abusivi.** 2. ** Potresti aver scelto un provider che utilizza NAT.
@northerner Cosa importa se la maturità è aumentata?Stiamo parlando di uno scenario in cui chiunque su Internet può attaccarti.E da qualche parte su Internet puoi trovare almeno una persona che non è matura e forse anche qualcuno che è apertamente malvagio.
Ho sempre messo in guardia contro i blocchi degli account proprio per questo motivo.Non solo sono un fastidio per gli utenti che non si collegano da un po 'e non riescono a ricordare quale variazione della loro password hanno usato, ma ancora più importante (dal punto di vista della sicurezza), creano un vettore DoS sieroso.Un mio amico una volta ha sviluppato un'app Web con una politica di blocco aggressiva (contro il mio consiglio).Per portare a casa il mio punto di vista (e scherzare con il mio amico), l'ho bloccato fuori dalla sua app solo usando la sua e-mail e un mucchio di password fasulle.
Odio i timeout sempre crescenti.Se vengono utilizzati, hanno bisogno di un limite, altrimenti hai ancora un Denial of Service, anche se solo per un utente.
#2
+32
Silver
2019-01-16 15:24:42 UTC
view on stackexchange narkive permalink

Dipende dal tuo meccanismo di blocco. Se gli accessi non validi vengono ripristinati dopo un po 'di tempo E un account bloccato non viene sbloccato, mostrare un contatore può aiutare un utente malintenzionato a non bloccare un account. Ma un utente malintenzionato esperto avrà determinato in anticipo la politica di blocco e ne terrà conto quando indovina la password. Quindi l'impatto è limitato.

Inoltre, fare affidamento su questo per proteggere il tuo meccanismo di accesso non ha senso. Dovresti avere una politica delle password decente e una politica di blocco da abbinare. Se la politica della password è forte, un utente malintenzionato dovrà indovinare un gran numero di volte prima di ottenerla correttamente. Se blocchi un account dopo 20 tentativi, hai poche possibilità di essere compromesso.

Devi chiederti: qual è il vantaggio di mostrare queste informazioni a un utente autentico? Spesso, questo problema con il blocco si verifica perché il numero di tentativi è impostato su un valore troppo basso. 3 o 5 sono scelte comuni. NIST (attualmente non disponibile a causa della chiusura del governo, quindi nessun riferimento diretto) suggerisce meno di 100 tentativi.

NIST ha uno scopo: pensa a una password che nessun aggressore indovinerà in 3 tentativi, ma che indovineranno in 100 tentativi. Tutti gli aggressori utilizzano dizionari e approcci diversi. Se una password non è sicura per resistere a 100 tentativi, può anche essere violata utilizzando meno tentativi, sebbene sia meno probabile. Quindi una buona politica per le password è un must.

Aggiungerò i riferimenti NIST quando il sito tornerà. Troy hunt ha alcuni buoni post sul blog che riassumono la password e i meccanismi di accesso. È anche un fan delle linee guida del NIST.

Stai cercando la pubblicazione speciale NIST 800-63 che normalmente può essere vista qui (link alla sezione pertinente): https://pages.nist.gov/800-63-3/sp800-63b.html#throttle Ovviamente, perché hanno fatto uno sforzo speciale per mettere quel server in modalità di manutenzione invece di allontanarsi (brontolare), quindi dovrai usare la Wayback Machine per vederlo subito: https://web.archive.org/web/20181223021935 / https: //pages.nist.gov/800-63-3/sp800-63b.html#throttle
Quello che mi piace è ricordare almeno l'ultima password non riuscita (hash).E se si usa lo stesso non aumentare il contatore di errori.Questo aiuta molto con i client ricordati male o con script per non bloccare regolarmente l'autore del reato.
Se un utente malintenzionato deve solo indovinare migliaia di volte per ottenere la tua password, allora non è una password complessa.
@Qwertie, lo cambierò in una descrizione più vaga;)
#3
+5
jamesdlin
2019-01-19 07:26:40 UTC
view on stackexchange narkive permalink

In linea di principio no, non dovrebbe essere un rischio per la sicurezza. Se lo fosse, faresti affidamento sulla sicurezza attraverso l'oscurità (informazioni nascoste).

Nascondere un conteggio sarebbe, nella migliore delle ipotesi, un piccolo inconveniente per un avversario.

Al contrario, nascondere un conteggio può essere un inconveniente significativo per gli utenti legittimi. Non è raro che a volte inserisca la password sbagliata e poi la reinserisca ancora un paio di volte supponendo di aver fatto un errore di battitura. Se so che verrò bloccato con un altro tentativo errato, cercherò la mia password e la copia / incolla o la digiterò attentamente. Se, tuttavia, mi blocco inconsapevolmente il mio account, ora devo affrontare molti problemi extra per sbloccarlo.

#4
+2
Tom K.
2019-01-16 19:50:51 UTC
view on stackexchange narkive permalink

Per dare un'altra prospettiva a questo: non importa per un utente malintenzionato esperto .

In che modo gli account online vengono compromessi oggi tipicamente 1 ? Esistono due varianti di una tecnica comunemente utilizzata.

I database con hash delle password (o password in chiaro) vengono rubati e violati offline dagli aggressori. Dopo aver crackato con successo un hash, la password corretta viene fornita al meccanismo di accesso al primo tentativo, quindi questo controllo è inefficace.

Questo può essere il database del servizio in questione o il database di un altro servizio. Sfortunatamente le persone tendono a riutilizzare le proprie password con diversi servizi, quindi è molto probabile che una volta che una password viene abbinata a un indirizzo e-mail, possa essere utilizzata su un altro sito. Un utente malintenzionato potrebbe avere due o tre password tra cui scegliere, ma probabilmente non 20. Ancora una volta, questo controllo è inefficace.

Quindi quale livello di sicurezza stabilisce questo controllo? Il livello necessario per proteggere da script kiddies inesperti, ex partner maliziosi e genitori ficcanaso che vogliono dare un'occhiata al tuo account personale e provare cinque password a caso. Niente di più, ma niente di meno.


1 Poi ci sono ovviamente altre tecniche più "avanzate" come keylogging, (spear) -phishing, MitM ecc. non mitigato da questo controllo.

#5
+1
Security Beast
2019-01-16 14:22:23 UTC
view on stackexchange narkive permalink

Solo due scenari sono possibili con esso, ma piuttosto mostrare che il rischio della politica del tempo di blocco dell'account è maggiore del tempo di blocco.

Ad esempio

  • una volta può configurare l'idra o qualche altro strumento per forzare il login e attendere dopo 3 tentativi. se non hai tempo di blocco sufficiente può causare la compromissione dell'account.

  • se hai un tempo di blocco di circa 30 minuti, è comunque possibile configurare lo strumento per la forza bruta e aspetta dopo tre tentativi, ci vorranno anni per decifrare la password.

per concludere che questo non comporta alcun rischio nella visualizzazione del tentativo di blocco dell'account.

#6
+1
jfran3
2019-01-16 15:29:04 UTC
view on stackexchange narkive permalink

In generale, mi propongo di fornire meno informazioni a un aggressore, meglio è. Come menzionato da @ security-beast, uno strumento può essere configurato per attendere la quantità di tempo appropriata. Fornire loro le informazioni per quella configurazione non è necessariamente l'ideale.

Tuttavia, devi bilanciarlo con le esigenze dei tuoi utenti. Trovi che gli amministratori di sistema impieghino una quantità eccessiva di tempo per sbloccare gli account perché i tuoi utenti continuano a bloccarli? In tal caso, la tua analisi potrebbe indicare che ottieni maggiori vantaggi dalla visualizzazione del numero di tentativi agli utenti in modo che sappiano quando devono attendere prima di bloccare i loro account. In altri casi sarà vero il contrario, ma in entrambi i casi la risposta dovrebbe essere il risultato di un'analisi oggettiva dei compromessi per il particolare sistema.

Spero che questo aiuti.

Non avevo visto il commento di Silver quando l'ho postato, ma avrei appoggiato le linee guida del NIST come una buona base per iniziare.
#7
  0
Hugo
2019-01-16 19:32:38 UTC
view on stackexchange narkive permalink

Il rischio per la sicurezza è soggettivo e dipenderà da ciò che stai cercando di proteggere, dall'obiettivo del controllo di sicurezza e da qualsiasi altro controllo di sicurezza in atto che mitiga o compensa il rischio.

Sulla base di queste diverse società / affari avranno un'accettazione diversa dello stesso rischio.

Se in modo generico fornire quanti tentativi hai ancora potrebbe non imporre un rischio (es: PIN nella tua smart card per effettuare chiamate telefoniche) In altre situazioni potrebbe essere un rischio (es: tentare di brute force mobile phone access) dove puoi fermarti prima dell'ultimo tentativo e attendere un po 'di tempo in modo che l'utente resetti il ​​contatore con un accesso valido ...

Dovresti controllare l'obiettivo del controllo di sicurezza, cosa stai cercando di proteggere e quali controlli di sicurezza hai in atto per compensare o almeno monitorare situazioni anomale.

Sulla base di tutto ciò, puoi decidere se è un rischio accettabile o meno per le tue specifiche.

#8
  0
Brandhout
2019-01-20 03:44:34 UTC
view on stackexchange narkive permalink

A un certo punto ero in un'azienda in cui hanno chiesto ad alcuni ragazzi di testare la loro sicurezza. Una di queste cose che quei ragazzi hanno scoperto è che non c'era il blocco dell'account quando c'erano troppe password errate. Tuttavia, con grande gioia del CISO, non sono riusciti a dimostrare di essere effettivamente in grado di entrare forzando la password. Il motivo è che il blocco dell'account è stato silenzioso ed è durato circa 15 minuti.

Chiediti cosa guadagni visualizzando un messaggio del genere e cosa perdi in sicurezza così facendo. È perfettamente valido non dare alcuna notifica di blocco di un account a causa di troppi tentativi di accesso errati. Se dai un messaggio del genere, aiuterai un aggressore a capire quando sta sprecando il suo tempo forzando brute. Se non lo fai, è meno probabile che lo capisca, ma potrebbe portare a più chiamate / e-mail al tuo helpdesk che potrebbe essere costoso. Una FAQ o una pagina di aiuto potrebbe ridurre questo problema.

Anche l'implementazione del conto alla rovescia, probabilmente, significherà più codice e più codice significa più bug. Questo non è qualcosa che desideri in un meccanismo di sicurezza. Aggiungete a ciò che lo implementate in modo sbagliato, potrebbe consentire agli aggressori di enumerare i nomi utente, il che è doppiamente problematico se si tratta di indirizzi e-mail. Diavolo, se lo implementi usando un cookie non firmato, potrebbe effettivamente dare all'aggressore la possibilità di impedire del tutto un blocco.

In generale la tua sicurezza sarà migliorata se i tuoi messaggi di errore forniscono il minor numero possibile di informazioni .

Sono un pentester.Se do il consiglio "limita i tentativi di accesso" e il cliente risponde "dimostra che è vulnerabile", sarei infastidito.È una questione di fortuna se riesco ad entrare con questo metodo.Vuoi fare affidamento sulla fortuna, o preferiresti applicare la logica e scoprire che, in effetti, se * uno * dei tuoi utenti imposta una password sbagliata e * uno * attaccante ha fortuna, sei pwn?Pertanto, sarei seccato di doverlo provare.Quindi, se in seguito venissi a sapere che c'è stato un blocco silenzioso (quindi mi lasci fare il lavoro, sapendo che non può avere successo), mi sentirei come se avessi doppiamente perso il mio tempo.
Quindi hai infastidito il pentester, ora passiamo alla modalità utente.Non riesco ad accedere al mio account anche se so che deve essere una di quelle cinque password.Ora devo eseguire altri passaggi per recuperare il mio account.Successivamente scopro che la mia password era corretta, ma che il sistema non mi ha permesso di entrare a causa di troppi tentativi.Invece di perdere tempo a provare password diverse e fornire al sito sempre più password possibili (dando più visibilità alle mie password), sarebbe stato molto bello se il sistema me l'avesse detto.
Infine, esaminiamo la situazione come attaccante.Se riesco a creare un account, posso provare 100 tentativi errati sul mio account (1. eseguire un tentativo di accesso in Firefox; 2. copiare come curl dalla barra degli strumenti per sviluppatori; 3. utilizzare Bash one-liner: `for i in {1..100}; fai ; fatto`) e poi vedi se riesco ancora ad accedere.No!Quindi c'è un blocco in atto.Ora creo un altro account e scrivo uno script simile che fa prima un tentativo non valido, poi due, poi tre ... e nel frattempo controllo se riesco ancora ad accedere.Tutto questo richiede circa cinque minuti.Nascondere il conteggio dei tentativi non è un ostacolo significativo.
@Luc hai ragione nascondere il conteggio dei tentativi non è un ostacolo enorme per un aggressore determinato, ma è comunque un ostacolo.
Quello che potrei non aver chiarito nel mio aneddoto è che i conti sono stati silenziosamente bloccati per un breve periodo di tempo, quindi la constatazione pentest era errata, motivo per cui è stato chiesto loro di dimostrarlo.Il punto era che il blocco silenzioso di un account è un modo perfettamente valido per farlo, in realtà è fatto in pratica e mostra che può aggiungere ostacolo al tuo aggressore.Hai perfettamente ragione che ci sono dei compromessi da fare e che non è una sicurezza perfetta, ma è sempre così.


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