Capire come prevenire i tentativi di login rapidi

1

Ho problemi a comprendere appieno come prevenire i tentativi di accesso rapidi. Le mie domande provengono essenzialmente da La guida definitiva all'autenticazione del sito Web basata su modulo .

Il consiglio finale è impostare una limitazione dell'accesso, impostando un intervallo di tempo tra i tentativi non riusciti . Qualcosa come:

  • 1 tentativo fallito = 5 secondi di ritardo
  • 2 tentativi falliti = 15 secondi di ritardo
  • 3+ tentativi falliti = 45 secondi di ritardo

Alcune domande che ti vengono in mente facilmente sono:

  • Se stiamo cercando di proteggere il nostro sistema dagli attacchi brute-force o di dizionario, come mai i ritardi sono così restrittivi ?. Uno degli esempi mostra un aumento di 2 ** 2 per tentativo non valido. Non sarebbe una discreta quantità di tempo scoraggiare già un aggressore automatico?

  • In questo schema di protezione, quale sarebbe il client? Come sarebbe identificato? Stiamo parlando di un account IP + o solo di un account ?. Se stiamo parlando di un solo account senza tenere conto dell'IP, non è probabile che infastidiscano gli utenti legittimi che tentano di accedere al proprio account?

  • Non ho mai visto materiale di lettura che parli degli umani che tentano di accedere agli account ?. Capisco che questo caso sarebbe altamente improbabile (più se assumiamo politiche relative alle password in atto) ma, cosa succede se un utente malintenzionato ha creato un elenco di password probabili tramite un metodo (social engineering). Non dovrebbe essere protetto anche questo ?. Perché in quel caso, essendo il cliente identificato dall'account IP +, essere molto restrittivi avrebbe molto senso, provare a bloccare l'IP che sta usando.

  • In che modo gli accessi con throttling non riusciti fanno davvero la differenza tra la semplice limitazione? . Con la limitazione semplice, intendo un throttle sull'endpoint 'login' che controlla il numero di volte in cui provi ad accedere, ma senza tener conto se questi tentativi hanno avuto successo o meno.

Assumendo questa definizione precedente per quello che intendevo con una semplice accelerazione, supponiamo di controllare il numero di volte che è possibile chiamare l'endpoint di accesso per un account dato un intervallo di tempo:

  • Per ogni account, l'endpoint di accesso può essere chiamato 3 volte al minuto.

Basterebbe questo per fermare un attacco di forza bruta ?. Aggiungendo questo ritardo menzionato prima quando il tentativo non è valido si ottengono risultati migliori?.

Sarei molto grato se qualcuno potesse far luce qui.

    
posta IoChaos 18.05.2017 - 14:30
fonte

4 risposte

2

L'idea principale qui è di rallentare rapidamente la finestra per forzare brute-un attacco. Normalmente implementa questo come:

  • Traccia su una base di account. (quindi ogni account ha il proprio tempo di attesa)
  • Aumenta esponenzialmente il tempo di attesa.
  • Avere un meccanismo di reset per la password e / o tempo di attesa attraverso qualche persona (Admin / service desk / ecc.)

La principale differenza tra il normale throttling e la velocità di accesso è il meccanismo del tempo di attesa. il fattore esponenziale significa che è necessario attendere più di un giorno per inserimento della password (bloccando efficacemente tale account), rendendo molto più probabile il rilevamento dell'abuso e la normale limitazione delle connessioni conteggio / velocità per volta e una quantità stabile di azioni consentite in ogni slot. (quindi è un tasso costante di tentativi invece di una quantità rapidamente in diminuzione).

    
risposta data 18.05.2017 - 15:26
fonte
2

Se l'attaccante è automatizzato, allora stanno bene aspettando. Potrebbero lasciare funzionare il loro strumento per un lungo periodo, se glielo permetterai. Quindi, non saranno facilmente "scoraggiati" (ecco a cosa servono gli strumenti).

Il blocco degli account ha un impatto sull'esperienza utente e ogni sito deve eseguire tale analisi dei rischi. Il modo in cui definisci il "cliente" dipende dal tuo scenario specifico.

    
risposta data 18.05.2017 - 15:02
fonte
0

Un attaccante "intelligente" non attacca un singolo account, ma cerca password comuni per un ampio numero di account utente.

Quindi, se vuoi difendere contro un attacco di login rapido, aumentare il ritardo per un singolo account non è sufficiente per proteggere il sistema nel suo complesso.

Suggerisco di mantenere una media costante dei tentativi di accesso falliti per il sistema, entro un certo limite di tempo (ad esempio 5 minuti). Se il numero di tentativi di accesso non riusciti per il sistema inizia a picco, rispetto alla media corrente, si ritarda il feedback del tentativo di accesso per tutti i tentativi di accesso a livello di sistema.

Il peso del ritardo può essere regolato per far corrispondere la differenza tra la media corrente e il picco misurato.

Una volta che è stato attivato un ritardo, la media corrente non può più essere considerata attendibile, perché ora è (potenzialmente) influenzata dall'attaccante. Quindi devi trovare un altro metodo per decidere quando ridurre o interrompere il ritardo nel feedback del tentativo di accesso.

    
risposta data 18.05.2017 - 16:01
fonte
0

Devi considerare gli intenti dell'accesso non autorizzato. Per qualcuno, potrebbe essere per ottenere l'accesso all'account al fine di ottenere le informazioni all'interno. Per qualcun altro, potrebbe essere negare l'accesso legittimo al proprietario e l'uso dell'account. Per un'altra persona, potrebbe essere l'avvio di un attacco denial of service efficace su un servizio che altrimenti arresterebbe la tempesta di pacchetti o l'attacco LOIC a monte.

La sicurezza IT non consiste solo nel negare agli attori malintenzionati l'accesso alle informazioni, ma nel garantire che gli utenti autorizzati dispongano di un accesso affidabile e affidabile alle loro informazioni.

Per mancanza di un chiodo ... tutto era perduto.

    
risposta data 19.05.2017 - 01:47
fonte

Leggi altre domande sui tag