Domanda:
Perché i siti implementano il blocco dopo tre tentativi di password non riusciti?
Bradley Kreider
2010-11-19 06:45:02 UTC
view on stackexchange narkive permalink

Conosco il motivo che sta dietro al fatto di non consentire infiniti tentativi di password: i tentativi di forza bruta non sono una debolezza di meatspace, ma un problema con la sicurezza del computer - ma da dove hanno preso il numero tre?

Non è un problema di negazione del servizio quando si implementa un criterio di blocco che può essere attivato facilmente?

Sono disponibili ricerche approfondite che mostrano un numero o un intervallo ottimale da scegliere prima di bloccare un account che saldi minaccia alla sicurezza con l'usabilità?

Pensandoci bene, non vedo alcuna differenza di sicurezza misurabile tra tre tentativi e 20 tentativi con la complessità della password generalmente in uso oggi.

(So che questo non è soggettivo, ma cerco opinioni basate su misurazioni)

Avevo la stessa domanda nella mia testa ... e penso che 3 non sia "abbastanza": 1. digitazione errata con blocco maiuscole attivato, 2. digitazione errata con blocco maiuscole disattivato, 3. digitazione errata in preda al panico che l'account potrebbe essere bloccato. ..
@Nivas: dopo che hai già fallito due volte, dovresti rallentare e guardare quello che stai facendo piuttosto che digitare panico.Inoltre, di solito un blocco è solo per un certo periodo di tempo;potresti essere bloccato per un'ora, il che limiterebbe la forzatura bruta di un account a tre tentativi all'ora, e l'utente reale può rientrare dopo un'ora (se riesce a ricordare la sua vera password per allora).
Il blocco del limite di tempo @MarkRipley ha senso.
@MarkRipley Il nostro sistema di gestione paghe richiede maiuscole, lettere regolari, numeri e caratteri speciali e password di lunghezza minima di 16 caratteri.E dopo 3 attacchi ti bloccano definitivamente, quindi devi contattare la società di gestione stipendi di persona per riavere il tuo account.Ridicolo.
Tredici risposte:
#1
+76
Zian Choy
2010-11-19 12:34:35 UTC
view on stackexchange narkive permalink

Recentemente, alla conferenza OWASP AppSec 2010 a Orange County, Bill Cheswick di AT&T ha parlato a lungo di questo problema.

In breve, la ricerca è insufficiente.

In lungo, ecco alcune delle sue idee per un blocco degli account meno doloroso:

  • Non contare i tentativi di password duplicati (probabilmente pensavano di averla digitata male)
  • Fai il suggerimento per la password sul password principale e non avere una secondaria (debole)
  • Consenti a una parte fidata di garantire per l'utente, in modo che possa cambiare la sua password.
  • Blocca l'account in un tempo crescente incrementi
  • Ricorda all'utente le regole per la password.
Odio assolutamente i "suggerimenti per la password". Questo meccanismo è effettivamente utile?
Sì. http://www.penny-arcade.com/comic/2006/7/12/ Un buon suggerimento può essere utile senza fornire alcuna informazione reale agli hacker. È particolarmente utile nei siti che vengono utilizzati molto raramente, dove la domanda è meno "qual è la mia password" rispetto a "quale password ho usato?"
+1000 "Ricorda all'utente le regole per la password." Odio quando provo a lungo un testo solo password su un sito solo per scoprire che le password devono avere un numero esso. Quindi ricordo quale password ho usato e accedo.
@Echo: Forse dovresti esaminare [LastPass] (http://lastpass.com/)
Un altro bernoccolo per "ricordare all'utente le regole della password". Tuttavia, la mia situazione è in realtà il contrario di @Echo's. Di solito, cerco di utilizzare una delle mie password più sicure (più lunghe, più complesse) e alla fine capisco che il sistema di autenticazione del sito ha funzionalità più limitate. È particolarmente frustrante quando vado a reimpostare quella password e il sito non dice nulla sulle limitazioni, lasciandomi impostare un'altra password che non verrà ricordata "correttamente" o chiedermi perché le mie password non accettano .
@Trevel A volte i suggerimenti possono essere utilizzati in modi [non intenzionali] (https://xkcd.com/1286/).
#2
+37
realworldcoder
2010-11-19 20:14:09 UTC
view on stackexchange narkive permalink

Qualsiasi sito web conforme agli standard di protezione dei dati PCI deve rispettare le sezioni

  • 8.5.13 (Limita i tentativi di accesso ripetuti bloccando l'ID utente dopo non più di sei tentativi)
  • 8.5.14 (Imposta la durata del blocco su trenta minuti o finché l'amministratore non abilita l'utente ID).

Questo è purtroppo il motivo per cui molti siti che accettano carte di credito hanno politiche di blocco draconiane, anche se i loro progettisti potrebbero non essere necessariamente d'accordo con ciò che hanno implementato.

Modifica: tieni presente che questi requisiti si applicano solo ai sistemi per "utenti non consumatori", quindi non dovrebbero influire sui siti dei clienti che accettano carte.

Scoperta spaventosa e deprimente. Richiedono porte in acciaio e più chiavi per la porta sul retro, ma la porta d'ingresso è sbloccata. Per essere caritatevoli, c'è qualche possibilità che ci siano dati finanziari (frode e furto) che supportano il limite di 6 tentativi?
Detto questo, se fallisco 6 tentativi e devo aspettare 30 minuti, non è poi così male. Non è come un blocco che richiede uno sblocco amministrativo esplicito. Mi piacerebbe vedere le loro ricerche che portano al numero 6 però ...?
Il PCI come regola imposta una linea di base minima, un minimo comune denominatore, se vuoi. Anche se dubito che il numero 6 sia così importante e supportato dalla ricerca, per i loro scopi DEVONO inserire * alcuni * numeri, altrimenti qual è lo scopo di far rispettare la conformità? 1000 tentativi sono altrettanto validi, eppure inutili (sebbene probabilmente abbiano ancora lo stesso effetto matematico). Vedi anche http://security.stackexchange.com/q/622/33
C'è qualche vantaggio in termini di sicurezza nell'hackerare un account bloccato per 30 minuti dopo sei tentativi, rispetto a consentire un tentativo ogni cinque minuti dopo il sesto tentativo? Entrambi richiederanno la stessa quantità di tempo per i tentativi di forza bruta, ma quest'ultimo renderebbe gli attacchi denial-of-service un po 'meno efficaci.
6 è semplicemente troppo basso. Devo accedere a diversi siti, alcuni dei quali mi richiedono di cambiare la password regolarmente, anche se ci accedo raramente. In sostanza devo avere almeno 20 combinazioni di password nella mia testa. Non li scrivo, quindi mi siederò felicemente a provare una serie di combinazioni. Solo alcuni siti mi bloccano (di solito senza dirmi che lo hanno fatto). Preferirei di gran lunga vedere almeno 10 tentativi.
quindi ora so chi ha inventato un ritardo del genere
#3
+22
Tate Hansen
2010-11-19 07:59:11 UTC
view on stackexchange narkive permalink

La mia esperienza è che i meccanismi di blocco stanno diminuendo in popolarità (almeno per le app web). Invece di bloccare gli account dopo una serie di tentativi falliti, inizi a chiedere ulteriori informazioni per una corretta autenticazione.

Vedo alcuni siti che ti chiedono di risolvere un captcha dopo alcuni tentativi di password falliti; questo ha senso per me.
@beetstra, ocr e human farms possono risolvere captcha.
#4
+18
Gary
2010-11-19 08:32:31 UTC
view on stackexchange narkive permalink

Non sarei sorpreso se provenisse dalla regola del baseball "Tre strike" piuttosto che da qualcosa di tecnico.

Una giustificazione (per le password alfanumeriche in ogni caso) è

In genere un tentativo fallito è un errore di digitazione o un problema di attivazione / disattivazione CAPS. Quindi provi ad accedere e vieni rifiutato (1), riprova perché pensi di aver digitato male (2) e poi ti rendi conto che il tasto MAIUSC è acceso, quindi accedi al terzo tentativo.

Non non è valido per sbloccare i telefoni cellulari da una rete quando si inserisce normalmente un codice numerico.

I suggerimenti migliori sono un ritardo sempre maggiore tra i successivi tentativi di accesso non riusciti. Per prima cosa consenti un nuovo tentativo istantaneo, poi 1 secondo, 2, quattro, otto ... Stai aspettando rapidamente un minuto tra i tentativi che è sufficiente per simulare qualsiasi attacco di forza bruta.

Assicurati di tenere conto dell'aggressore che cambia i nomi utente. Un attacco di forza bruta non deve essere prima una profondità. Potrebbero prima andare avanti, scegliendo una password e cambiando il nome utente.
@DanMcGrath Alcune note rilevanti su questo: [Do Strong Web Passwords Accomplish Anything?] (Http://research.microsoft.com/pubs/70445/tr-2007-64.pdf)
#5
+15
itinsecurity
2010-11-19 15:57:46 UTC
view on stackexchange narkive permalink

Sono d'accordo con l'OP. Se pensi a cosa ti protegge il blocco, non c'è differenza tra 3 o 20 tentativi (o 100, se è per questo). Tutto ciò che ottieni con questi blocchi, a parte punire gli utenti smemorati, è prevenire un attacco di forza bruta Puoi anche utilizzarlo per attivare un avviso che indica che un attacco è in corso, ma questo non è lo scopo principale (se lo fosse, significa che stai deliberatamente facendo il DoSing ai tuoi utenti solo per semplificare il tuo lavoro di monitoraggio. un'ottima pratica).

Se qualcuno ha il tuo database di password e può hackerarlo offline, ha un numero illimitato di tentativi. Il tuo limite di 20 tentativi non va bene lì.

Se qualcuno sta tentando una forza bruta in linea, tutto ciò di cui hai bisogno è una password che possa resistere per "abbastanza a lungo": abbastanza a lungo perché il tuo IRT risponda o abbastanza a lungo perché il tuo aggressore si arrenda.

Il database delle password di Conficker è leggermente inferiore a 200 password, IIRC, ed è pieno di alcune delle password più stupide del pianeta. Supponiamo ora che la tua password non sia in questo elenco. Se consenti 20 tentativi con la password, diciamo ogni 15 minuti, senza bloccare, un utente malintenzionato impiegherà più di due ore solo per superare quell'elenco.

In effetti, anche se restringi la password create da informazioni rilevanti su quell'utente, come kidsname02, birthday99 ecc., ti ritroverai comunque con almeno qualche decina di password, estendendo un attacco al dizionario a forse un'ora o più. attiva i tuoi allarmi, non una manciata di password sbagliate in un paio di minuti.

Quindi, se riesci a tenere i tuoi utenti lontani dalle insidie ​​delle password più basilari, puoi tranquillamente accettare molti tentativi di password errati.

Personalmente, traccio la linea a 15. Totalmente arbitrario, e soprattutto una cosa pratica: trovo che qualsiasi utente reale abbia rinunciato molto prima di questo. Di solito, se ci sono così tanti tentativi, è un processo o una sessione appesa da qualche parte con vecchie credenziali. E se non è così, possiamo parlare della ricerca di attacchi.

#6
+11
AmaDaden
2010-11-19 20:36:04 UTC
view on stackexchange narkive permalink

È una stupida regola arbitraria che comporta il rischio di uno strano tipo di attacco DDOS. Diciamo che Marv odia il sito web X e il sito web X ha un numero Y di criteri di blocco dei tentativi. Marv potrebbe creare un inferno serio facendo in modo che uno script provi automaticamente con nomi casuali Y volte con password fasulle. Anche se una password funzionasse, Marv probabilmente non se ne preoccuperebbe e la ignorerebbe. Ciò bloccherebbe efficacemente molti utenti per il sito Web X e causerebbe molta frustrazione per gli utenti, e Dio li aiuti se sono una banca che devi chiamare per reimpostare la tua password. Sono sorpreso che nessuno ci abbia provato.

Penso che la natura arbitraria dell'uso di "3" come numero massimo di tentativi abbia già ricevuto risposta dalla maggior parte dei poster precedenti, ma volevo un secondo scenario DoS di AmaDaden.Si tratta di un attacco relativamente a bassa tecnologia e potrebbe causare molti danni a livello aziendale, soprattutto se un sito Web non dispone di risorse di backup sufficienti per affrontarlo.
#7
+10
Vineet Reynolds
2011-06-02 19:11:15 UTC
view on stackexchange narkive permalink

Credo di essere in ritardo a questo dibattito, ma spero di avere qualcosa di utile da aggiungere qui.

La politica di blocco dell'account (con il numero di tentativi non validi consecutivi di solito compreso tra una singola cifra per la maggior parte delle organizzazioni) non è stato concepito esclusivamente contro gli attacchi automatici di forza bruta.

È più una protezione contro l'individuazione della password da parte di aggressori umani, in particolare da persone che già conoscono una parte della password. Gli aggressori potrebbero ottenere frammenti di password

  • navigando a spalla
  • indovinando i modelli utilizzati da un individuo per scegliere le proprie password. Dopo tutto, quante volte è stata utilizzata una password con elementi in una sequenza, come password # 01 , password # 02 ecc.

Lo svantaggio, ovviamente, è che con un valore di soglia basso, è inevitabile che ci sia un Denial of Service e un costo associato per le imprese. Il Libro bianco sulle best practice per il blocco degli account pubblicato da Microsoft fornisce un valore consigliato di 10. Spiega inoltre come stimare la probabilità di un attacco riuscito, utilizzando i parametri nei criteri di blocco degli account di Windows:

Ad esempio, si supponga che l'amministratore reimposti la password quando l'account è bloccato con il valore di registro LockoutDuration di 0. Con il valore di registro LockoutDuration impostato su 0 e il valore di registro LockoutThreshold impostato su 20, il l'utente malintenzionato ha 20 tentativi da utilizzare contro quella password. Se la durata del blocco è di 30 minuti, l'utente malintenzionato ha 20 tentativi ogni 30 minuti contro quella password finché non viene modificata. Questa è una differenza molto significativa nel numero totale di tentativi disponibili per l'utente malintenzionato.

In confronto, se l'amministratore imposta l'età massima della password a 42 giorni, il primo utente malintenzionato ha solo 20 tentativi contro una determinata password, mentre il secondo utente malintenzionato ha 40.320 tentativi (20 tentativi di blocco per sempre, moltiplicati per 48 blocchi ogni giorno, moltiplicato per 42 giorni prima che l'utente cambi la password). Con le impostazioni della password predefinita, sono disponibili circa 10 ^ 12 password possibili. Ciò significa che l'utente malintenzionato ha circa una probabilità dello 0,000004% (%) di indovinare la password. Con uno schema di ipotesi ottimizzato, questa percentuale sarebbe molto probabilmente una percentuale maggiore.

Ovviamente, non è facile per nessun profano scegliere un numero adatto e tali decisioni dovrebbero essere prese con attenzione considerato. Pertanto, si potrebbe tranquillamente presumere che alcune organizzazioni non si siano impegnate a calcolare gli effetti monetari della loro politica di blocco dell'account e il vantaggio associato di allentare la loro politica pur conservando il vantaggio di sicurezza che fornisce.

#8
+8
AviD
2010-11-22 17:40:00 UTC
view on stackexchange narkive permalink

Ci sono due aspetti in questo; il primo, come hai detto, è prevenire gli attacchi di forza bruta.

A questo scopo, dovrebbe essere fatto un numero qualsiasi di tentativi - 3, 5, 20, 2000 ... con una corretta politica delle password (lunghezza + complessità + ...) fornendo uno spazio sufficiente per la chiave, qualsiasi tipo di limitazione (numero X di tentativi all'ora) assicurerà che la forzatura bruta dell'intero spazio richiederà alcuni decenni. (Fai i conti).

Anche se - e questo dovrebbe essere un requisito - il blocco è solo temporaneo e dopo un breve periodo di tempo si sblocca automaticamente.

Quindi, il numero di tentativi prima del blocco è arbitrario.

Tuttavia, qui è in gioco un altro problema, più sottile e non matematico:

Semplicemente non ha senso che un singolo utente inserisca ripetutamente un errore password 2000 volte di seguito.

Cioè, se scegli arbitrariamente 2000, sai molto prima che questo NON è un utente legittimo. Quindi, si tratta davvero di ciò che ha senso per gli affari e di un compromesso di analisi del rischio incentrato sul business.

Penso che storicamente, il compromesso fosse più inclinato verso il lato del rischio: poiché le password erano più brevi e meno complesse, la differenza di 3 o 10 era maggiore. Inoltre, le persone avevano meno password, quindi erano più facili da ricordare ... E gli utenti in generale erano più tecnicamente esperti.

Al giorno d'oggi, tre non hanno davvero senso, considerando l'impatto sul business. È davvero una questione di ciò che ha senso per la tua app, quali tipi di utenti, quanto spesso accedono, ecc. Di solito consiglio di capire quanti tentativi falliti e legittimi sono probabili, quindi raddoppialo.

( Come menzionato da @realworldcoder, PCI ha scelto arbitrariamente sei e se sei soggetto a PCI non hai molta decisione qui. Altrimenti, scegli un numero che abbia senso per tu.)

#9
+7
Dan McGrath
2010-11-19 19:31:33 UTC
view on stackexchange narkive permalink

Per quanto riguarda i suggerimenti di "blocchi" che aumentano il tempo per ritardare i successivi tentativi falliti e quindi prevenire la forzatura bruta, ricorda che questo funziona solo con attacchi mirati degli utenti.

per ottenere l'accesso al sistema, potrebbero eseguire un primo attacco ampio (scorrere tutti i nomi utente noti / indovinati prima di passare alla password successiva). Aggiungi che se è stato fatto correttamente potrebbe provenire da una rete distribuita di macchine, è abbastanza facile vedere che neanche il sistema di ritardo funziona.

Come menzionato da altri, corretto monitoraggio dei tentativi falliti scoprire gli attacchi in anticipo è fondamentale.

Sì, 3 tentativi sono abbastanza arbitrari e rappresentano un rischio DoS. Vorrei davvero che le persone smettessero di usare per i sistemi rivolti al pubblico ... Per favore!

Un'altra soluzione: l'identificazione a 2 fattori. Token RSA. Se solo avessimo un modo per possedere personalmente un singolo token RSA con un "numero ID". Potremmo quindi registrare questo "numero id" con qualsiasi sistema, che richiederebbe quindi il valore corrente del token insieme alla password per accedere.

Ma questo pone tutta un'altra serie di problemi per l'implementazione e fiducia ...

Grandi punti. Non deve nemmeno essere così sofisticato. Potevano eseguire il primo attacco in ampiezza e un attacco di settimane a intervalli. Ma i ritardi ti danno un tasso massimo noto di attacco (se ignori l'IP di origine). Se blocchi l'account dopo 10000 (qualsiasi numero elevato) errori di fila, scambi un DoS (se l'amministratore non presta attenzione) per essere violato (supponendo che il fattore 2 sia fuori portata).
#10
+3
Jose
2010-11-20 06:18:38 UTC
view on stackexchange narkive permalink

Le società che sono pubbliche (vendono azioni in borsa) sono regolate dal Sarbanes-Oxley Act e vengono controllate più volte l'anno per verificarne la conformità. Le applicazioni software critiche devono essere conformi a determinate funzionalità di sicurezza: una di queste consente di bloccare gli account dopo i tentativi di password non riusciti.

La maggior parte di queste applicazioni consiste nell'integrarsi nell'Active Directory aziendale che dispone già delle funzionalità abilitate.

#11
+3
user124863
2016-09-20 22:34:57 UTC
view on stackexchange narkive permalink

Ecco una lettura davvero piacevole che ripercorre ciò che credo tu stia cercando. Hanno preso i dati dagli studenti universitari utilizzando una politica di tre colpi, una politica di dieci colpi e una politica di colpi infiniti per suggerire di aumentare il numero da tre a dieci (poiché triplica approssimativamente il successo dell'accesso).

Tornando a una visione soggettiva qui ...

Perché la maggior parte dei luoghi utilizza una norma dei tre avvertimenti? È certamente solo un'euristica che si è sviluppata nel tempo. Tre tentativi sono più o meno una via di mezzo per amministratori e utenti, in quanto tre possibilità sono più che sufficienti.

L'idea alla base di una password è che si suppone di conoscerla . Non dovresti aver bisogno più di un tentativo. Capisco che si commettano errori, ma in una guerra ... hai davvero solo una possibilità per dimostrare di essere un alleato, giusto?

#12
+2
Rush Frisby
2010-11-19 17:49:16 UTC
view on stackexchange narkive permalink

Devono averne scelto 3 a caso. Questo è estremamente basso. Forse hanno avuto problemi di sicurezza in passato e hanno scelto un numero di blocco basso piuttosto che indirizzare o risolvere il problema correttamente.

Preferisco il metodo di bloccare l'utente in incrementi di tempo crescenti. Tuttavia, non lo escluderei dal nome utente, ma utilizzerei invece l'indirizzo IP della persona, perché la persona potrebbe provare più nomi utente. Ho impostato il tempo di blocco su (numero di tentativi di accesso non validi) ^ 2 secondi, una volta che l'utente ha raggiunto 5 tentativi non validi. Se l'utente non conosce la propria password in un numero relativamente basso di tentativi, utilizzerà principalmente uno strumento di recupero della password se il sito ne fornisce uno. Se si tratta di un vero tentativo di hacking, diventerà così frustrante per l'hacker che alla fine si arrenderà. I bot proveranno così tante volte che non sarà quasi mai permesso di accedere ... ad esempio, se provassero 1000 password (il che richiederebbe molto tempo per farlo comunque) dovrebbero aspettare 11 giorni e mezzo prima di poter prova la 1001a password. Puoi facilmente aumentare la capacità di deterrenza aumentando il moltiplicatore a ^ 3. Qualunque cosa sopra potrebbe diventare un po 'troppo alta per gli utenti umani validi.

Il problema con il blocco in base all'IP è che questo può anche essere aggirato o utilizzato in modo improprio. Per esempio. un attacco distribuito ... E cosa succede se un singolo IP è condiviso da molti utenti, ad es. proxy aziendale?
Un attacco distribuito sarebbe più brutale se non lo avessi installato. Qualunque cosa tu faccia, aumenterà sempre il livello di minaccia. / Se gli utenti si nascondono dietro un proxy, dovrebbero solo aspettare. Potrebbe essere un hacker che utilizza un proxy e non un vero utente. Il fatto è che non si sa mai e questa è la conseguenza dell'essere anonimi. Non dovresti compromettere la sicurezza per comodità.
Non si tratta di compromettere la sicurezza, le sue misure di implementazione che non hanno nulla a che fare con la minaccia che stai cercando di prevenire. Un attacco distribuito sarebbe brutale, sì, ma da un punto di vista DoS, non basato sulla forza bruta delle password. Gli utenti sono spesso costretti a utilizzare un proxy, spesso senza nemmeno saperlo - non si "nascondono" dietro di esso.
Meglio prevenire che curare.
Questa è una delle concezioni errate più distruttive che sono così incredibilmente popolari, sfortunatamente."Meglio prevenire che curare" * potrebbe * essere valido (probabilmente), ** SE ** non c'erano altri costi o svantaggi associati.In questo caso, sicuramente ce ne sono, e finiresti con una soluzione sostanzialmente peggiore."La sicurezza a scapito dell'usabilità va a scapito della sicurezza".
Dannazione, sei così arrabbiato fratello?Nessuno si siede lì e cerca di reimpostare la propria password migliaia di volte.Solo bot.F quei robot.È una cattiva sicurezza se li fai rientrare quando sai di cosa si tratta.
Heh scusa se sono uscito fuori di testa, per niente.E hai ragione, se un singolo utente prova mille volte la password sbagliata, puoi essere dannatamente sicuro che si tratti di una qualche forma di attacco.Ma il punto è che lo perdi quando passi all'indirizzo IP.Certo, rintracciarlo, confrontarlo con altri tentativi, magari anche inserirli in un graylist, ma non ignorare il contesto più ampio e gli scenari di utilizzo tipici validi (per non parlare di quanto poco indirizzo IP vincoli davvero un attaccante).
#13
+2
Josh
2010-11-19 19:37:28 UTC
view on stackexchange narkive permalink

Non molto tempo fa ho implementato uno schema di sicurezza dell'accesso che seguiva queste regole di base:

  1. Il primo tentativo fallito fornisce un feedback immediato. Probabilmente l'hanno capito.
  2. Dal secondo al quinto tentativo fallito, la risposta è stata ritardata di un secondo per tentativo fallito. ad es. 2 secondi, 3 secondi, 4 secondi ...
  3. Se il quinto tentativo non è riuscito, la sessione è stata terminata e gli è stato presentato un messaggio che indicava che avrebbero dovuto chiudere il browser e provare di nuovo.

Per me questo era più che adeguato per prevenire attacchi di forza bruta; sarebbe al massimo un inconveniente per gli utenti finali e non creerebbe alcun lavoro aggiuntivo per il supporto.

I tentativi di forza bruta molto probabilmente non provengono da un unico punto finale, il che rende il "browser di chiusura" un punto controverso.
@Dan, hai ragione, ma potrebbero anche provenire dallo STESSO endpoint, ma senza un browser. E, senza sessione, ogni richiesta è una nuova sessione. quindi anche "la sessione era terminata" è inutile
In questo caso particolare era impossibile arrivare a questo punto senza aver abilitato la sessione. Ma ammettiamolo, un approccio migliore sarebbe stato quello di mantenere le statistiche di blocco nel database. Per noi avevamo un certo set di ID evento registrati e monitorati. Se in qualsiasi momento fosse arrivato un gran numero di tentativi per lo stesso utente ... l'avremmo saputo abbastanza rapidamente.
Penso che il punto di AviD sia che il componente della sessione potrebbe essere automatizzato, nel qual caso stai solo sconfiggendo la forza bruta tramite browser (ad esempio: una persona che tenta la forza bruta o la brutta automazione del browser). L'altro problema è che è più probabile che il ritardo di risposta colpisca utenti validi, piuttosto che scoraggiare un attacco di forza bruta automatizzato. Se il 99% degli utenti lo fa correttamente in meno di 10 tentativi e non puoi essere forzato in 10 tentativi, è probabilmente una buona idea impostare il limite a 10 (numeri composti per un esempio).


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