Con quale algoritmo posso prevenire una forza bruta su un login?

Tempo è tuo amico.

Pensa a cosa succede quando ricaverai i soldi da "la tua macchina bancaria media" .

1. Scheda inserimenti utente (leggi: email / nome / altro),
2. La macchina dice "ciao, per favore inserisci il codice PIN" (leggi: password / qualunque)
3. L'utente può ora inserire il codice PIN corretto entro 3 tentativi. Se fallisce, la carta viene ritirata e l'utente dovrà attendere il giorno successivo per richiedere personalmente una nuova carta e un codice PIN, spiegando alla sua banca cosa è successo.

Ora, nella tua situazione probabilmente non vuoi che le persone vengano a bussare alla tua porta perché non hanno inserito il codice corretto. Per evitare ciò, devi semplicemente rimuovere la "venuta e presentare una nuova carta" e quello che rimane è "aspetta fino a domani".

Quindi, se dai a un utente 3 tentativi di verificare se stesso e lui / lei non riesce ... fallo aspettare un'ora prima che lui / lei possa riprovare.

Se qualcuno provasse ancora a fare un attacco di forza bruta, gli avrebbe permesso di provare ("3 tentativi all'ora" massimo x "24 ore al giorno" massimo = 3 x 24 =) 72 tentativi al giorno.

A seconda di cosa sta provando a fare la forza bruta, 72 tentativi al giorno (che sono 26280 tentativi in un anno di 365 giorni) sono troppo lenti.

In questo modo - e fino a quando "reverse engineering" per trovare una backdoor non è un'opzione - il tuo "software" dovrebbe essere al riparo da qualsiasi forza bruta.

Aggiorna

Un piccolo aggiornamento, basato sui commenti a questa risposta ...

Ora, per quanto riguarda le persone che vengono bloccate perché una o più persone malintenzionate abusano del nome utente di un membro specifico e cercano semplicemente di assicurarsi che un utente non possa accedere perché hanno inserito semplicemente una password errata per 3 volte?

Giusto, sembra un attacco di tipo "Denial of Service". Ma questo non ti impedirà di farlo in questo modo, in quanto tali attacchi possono essere elusi facilmente. Tutto quello che devi fare è assicurarti di non dimenticare un secondo livello di sicurezza per questi casi.

Ricorda che ci sono cose come "domande di sicurezza". Qualcuno potrebbe essere in grado di conoscere o indovinare il tuo nome utente, ma ci vorrà un sacco di tempo per aggirare una domanda di sicurezza quando è bloccata ... a meno che tu non conosca la risposta. La domanda di sicurezza potrebbe essere limitata semplicemente a "sbloccare" l'area di accesso "bloccata".

Pensa a come Google e Co. lo fanno:

1. accedi con nome utente / email e password,
2. fallisce più volte dà un blocco,
3. rispondere alla domanda di sicurezza solleva correttamente il blocco.

Usa un captcha ai punti (1) e (3) per rallentare qualsiasi tentativo di forza bruta e tutto è pronto.

Se non vuoi usare esplicitamente un captcha (che mi fa chiedere il perché), dovrai implementare un'implementazione di "user-ip", "time-of-access" e rallentare l'accesso al sistema per un casuale da 1 a 2 secondi. Questo non dovrebbe essere un problema in quanto sarebbe un'implementazione simile alla procedura di blocco, solo che non blocchi, ma rallenti le cose in certi punti, quindi un attacco a forza bruta richiede tempo . Un rallentamento di 1 secondo su 1 pagina limiterà la forzatura bruta a 60 tentativi al minuto, mentre blocchi il brute-forcer dopo 3 tentativi falliti. Lo stesso vale per la domanda di sicurezza: rallenta. Il bruto-forcer dovrà essere abbastanza intelligente da occuparsi di entrambi i punti e dovrà eseguire la forza bruta di entrambi nello stesso momento ... rubare le sue preziose risorse e il tempo necessario a causare il caos.

Comunque lo fai. Se lo fai in questo modo, non c'è bisogno che l'amministratore lasci la macchina da caffè mentre tutto sta succedendo, e risolve tutti i problemi che pensi di aver scoperto in merito al "blocco degli utenti legittimi con un attacco simile al DOS" .

Diamo un'occhiata all'esempio iniziale che ho fornito sopra in (3):

If that fails, the card is withdrawn and the user will have to wait for the next day to personally apply for a new card and pincode, explaining to his bank what happened.

Bene, l'opzione "domanda di sicurezza" per consentire agli utenti legittimi di rimuovere il blocco è come essere costretti a visitare personalmente e parlare con la banca. Semplicemente più facile.

Inoltre, questa procedura di "sblocco" può essere utile per l'amministratore / sysop come un semplice file di registro che mostra il numero di "tentativi" può aiutare l'amministratore a rintracciare i tentativi di un attacco definitivo. Ogni bambino di script potrebbe provare a bloccare gli utenti inserendo la password errata per 3 volte ... ma se qualcuno non risponde più volte alla domanda di sicurezza, c'è qualcosa di brutto.

E per ultimo ma non meno importante: proprio come una cipolla, questi livelli di sicurezza possono persino essere racchiusi l'uno nell'altro (se ha senso, come negli ambienti ad alta sicurezza).

Il semplice trucco è quello di rendere difficile per le persone fare confusione con le cose, mantenendo al contempo l'utente normale.

Posso solo ripetere: tempo è tuo amico ... (il resto è semplice logica)

Perché pensi che il tuo approccio di ritardare l'accesso dopo una quantità fissa di tentativi falliti non si riduca? Secondo me, si adatta perfettamente: per ogni IP (o cookie di sessione o qualsiasi altra cosa) e intervallo di tempo, c'è una quantità fissa di tentativi di accesso, rendendo impossibile lanciare un attacco a forza bruta.

A parte questo, non mi preoccuperei delle botnet, dal momento che il proprietario di una botnet sufficientemente potente può facilmente generare abbastanza traffico sul tuo uplink in modo che nessun'altra connessione sia possibile / fattibile, sia che si tratti di tentativi di accesso o meno. p>

EDIT: aggiunta ai commenti e solo per far notare chiaramente questo problema: non è possibile difendersi dagli attacchi DoS a causa della natura di TCP / IP (e DNS). Il meglio che puoi fare è proteggere quelle risorse che non sono vulnerabili a DoS, che potrebbero interessare gli utenti validi. Cioè, quando si memorizzano tentativi di accesso falliti, non archiviare più di N tentativi di accesso per evitare che un DoS riuscito riempia completamente lo spazio disponibile su disco oltre alla larghezza di banda disponibile (che non è possibile proteggere).

La semplice analogia di una casa potrebbe aiutarti: puoi proteggere la tua porta, ma non la strada che conduce ad essa.

Cose che farei per evitare la forza bruta sul sistema di login (molto severo e complicato):

1. Ritardo di X secondi nel controllo di ciascun tentativo di accesso, x tra 2-4 secondi.
2. Non consentire per 30-50 minuti dopo 7 errori per ciascun IP
3. Non consentire per 30-50 minuti dopo 7 errori per ogni tentativo di accesso all'account (IP varia, il nome utente è lo stesso)
4. Misura le battute sulla pagina di accesso utilizzando Javascript.
5. Misura il tempo trascorso dall'utente sul server.
6. lunghezza della password almeno 6, applica l'uso del simbolo di atleast 1, 1 cifra e 1 alfabeto.

A seconda dello scopo del brute-forcer, se lui / lei vuole interrompere i tuoi servizi e ha risorse illimitate, non c'è modo di fermarlo. ma se sta cercando di accedere al sistema, fallirà (si spera).

Modifica - >

3) non complesso, è esattamente come l'indirizzo IP di registrazione 2) con # 3 in effetti, chiaramente l'account che viene scelto non è lo stesso account, quindi 100.000 bot non possono eseguire la brute-force per 1 account singolo 700.000 volte in un'ora (ma solo 7 volte) ... 5) questo non è "ritardare l'utente del lato client" ma "misurare la spesa del client del tempo che riempie il nome utente / password"

Gli IF 2 e 3 sono bypassati, lo scopo dell'attacco è DOS / DDOS

Mantieni il tasso medio di errore di accesso (per ora) (simile a un grafico) nel tuo sistema, con un attacco DDOS, l'errore diventerà molto alto (rispetto al tasso di errore medio) - > Devi eseguire azioni manualmente.

PS: ovviamente sarà complesso.

Se hai bisogno di una password di sette caratteri, il numero di possibili password alfanumeriche miste è enorme. Ci vorrebbero circa 111670 anni, ad un tentativo al secondo per essere sicuri di averlo.

Assicurati che il ritardo sia su un utente che tenta di accedere, non che qualcuno stia tentando di loggarlo, poiché sarebbe un sistema molto lento.

Questo renderebbe un attacco di forza bruta non fattibile.

Non credo che la scelta dell'algoritmo impedirà completamente i tentativi di accesso alla forza bruta. Anche se ci sono modi per renderlo più difficile, a seconda dello scenario reale.

Puoi introdurre attese e blocchi di vario tipo che prolungheranno il tempo necessario per forzare la forza bruta in un tentativo di accesso. Una volta che un utente malintenzionato si è impossessato del file della password, questo non impedirà a questo utente di utilizzare una delle cosiddette tabelle arcobaleno con password precalcolate per ottenere password funzionanti per tutti gli account.

Anche se ci sono diversi modi per impedire che ciò accada. Un modo è introdurre un cosiddetto sale nei calcoli crittografici. Questo è semplicemente un valore specifico per ogni utente che impedisce l'uso di password precalcolate. Ciò significa che devi forzare la forza bruta su ogni account dato che non puoi usare le tabelle arcobaleno precalcolate. Questo spesso richiede molto tempo e l'utente malintenzionato tenta invece un altro sito.

Un altro trucco che Unix usa è usare un algoritmo molto inefficiente che richiede molto tempo per calcolare. Ciò rende inoltre impossibile calcolare preventivamente le password.

Ho letto un ottimo articolo su questo ultimo trucco che rende sia difficile usare la forza bruta e praticamente impossibile con l'hardware di oggi per precalcolare le password o la forza bruta. Purtroppo Google non è riuscito a trovarlo per me quando ho provato a trovarlo.

Trovato uno, ma non quello: link

Invece di archiviare gli IP da cui sono stati effettuati i tentativi falliti, che ne dici di archiviare l'ultimo N IP da cui sono stati effettuati gli accessi riusciti? Potresti già farlo per i rapporti di tipo "attività dell'account".

Tratta questi IP come una sorta di "lista bianca" per i blocchi. Per esempio. se 10.1.1.100 e 10.1.2.200 sono IP che hanno avuto accessi validi per luser , allora questa è la whitelist. Se 172.16.1.50 effettua tre tentativi falliti, imposta il flag lockout per luser sul timestamp corrente. Per i prossimi 15 minuti, qualsiasi tentativo di accesso che non proviene dalla lista bianca verrà incontrato con un messaggio "Combinazione nome utente / password non valida". (In altre parole, non lasciare che l'attaccante sappia che è stato rilevato e che l'account utente è bloccato, lascia che continui a sprecare le sue risorse e non gli consenta di ottimizzare l'attacco.)

Per lo scenario in cui l'aggressore riesce a condividere un IP con la vittima, rimuovere un indirizzo IP dalla whitelist dopo tre tentativi falliti. (O aumenta la soglia se vuoi dare agli utenti legittimi più possibilità di ingrassare la password.) Sembra che sarebbe più un attacco mirato contro un particolare utente, che è più difficile da difendere di una "forza bruta qualsiasi account "tipo di attacco (sembra che quest'ultimo è ciò che stai cercando di difendere contro). In questo caso l'utente legittimo dovrà reimpostare la sua password per riottenere l'accesso al sistema - scomodo ma non fatale.

Per lo scenario in cui un utente (in particolare l'amministratore in vacanza) è lontano dal suo normale indirizzo IP, consentire alla funzionalità di reimpostazione della password di inserire una nuova voce nella whitelist. Un utente legittimo proverà solo una manciata di volte prima di arrendersi e di eseguire la reimpostazione della password dance.

Un'alternativa alla strategia whitelist / lockout sarebbe quella di aggiungere una sfida secondaria al processo di accesso. Dopo tre tentativi di accesso falliti, imposta un flag sull'account dell'utente. Se il flag è impostato, fai un ritardo di 10 secondi, quindi servi una seconda schermata che richiede risposte a un paio di "domande di sicurezza" prima che controllano la combinazione nome utente / password. Quando viene inviata la seconda schermata, attendere 10 secondi, quindi verificare nome utente, password e domande di sicurezza e segnalare successo / fallimento in modo generico (ovvero non fornire all'utente malintenzionato quale dato non corrispondente). Questo sarà solo leggermente scomodo per l'utente legittimo, ma rallenta l'attaccante fino a 3 password al minuto e fa in modo che ogni ipotesi di password debba essere combinata con una domanda di sicurezza corretta. Ad eccezione di un attacco mirato (in cui l'attaccante potrebbe conoscere la risposta a "qual è il nome del tuo primo animale domestico?"), Ciò richiederebbe più ipotesi di domande di sicurezza per indovinare la password. Ovviamente sceglierai queste due domande tra una dozzina di risposte che l'utente ha già fornito durante la registrazione.

Assicurati di includere un token criptopandom sia nella pagina iniziale che in quella secondaria e convalidali su ogni invio in modo che l'attaccante non possa ignorare i ritardi.

Ad ogni modo, gli utenti legittimi eseguiranno la reimpostazione della password dance dopo una serie di accessi non riusciti comunque.

In entrambi i casi, sarebbe anche utile inviare un avviso agli amministratori se viene rilevata una certa soglia di lockout (o trigger di schermata secondaria) in modo da poter prendere contromisure più attive di fronte a un attacco di forza bruta su più conti.

La domanda è un po 'sottostimata. Suppongo che l'accesso sia verificato su un server e che avvenga da un'applicazione client scritta in una lingua con un'implementazione crittografica ad alte prestazioni disponibile.

Quindi prima di ogni accesso è necessaria una prova di lavoro. L'implementazione classica è che l'utente deve trovare un valore proof in modo che Hash(challenge&proof) inizi con una certa quantità di 0 bit. Dove challenge&proof è una combinazione di una sfida generata dal server e una prova generata dal cliente. Il cliente deve indovinare una prova che soddisfa la condizione. Non sono sicuro di come combinare sfida e prova, se è sufficiente una concatenazione semplice o se è necessario utilizzare uno schema basato su HMAC.

La scelta della funzione di hash è importante, dal momento che l'utente malintenzionato potrebbe eseguire hardware diverso da quello legittimo. Analizzerei uno schema basato su scrypt per evitare attacchi basati su GPU e FPGA efficienti.

In una situazione di attacco puoi semplicemente aumentare la difficoltà (cioè il numero di 0 bit richiesti), quindi un accesso richiede più lavoro.

Non esiste una soluzione. Puoi provare a rallentare la crittografia della password alghoritm, se hai il controllo su di esso (questa è la soluzione di OpenBsd MD5). Ma stai solo per rallentare l'attacco di forza bruta.