Fattibilità degli attacchi brute-force di database basati sul tempo sui siti web

Quanto è fattibile l'attacco dipende da quanto rumore devi rimuovere per arrivare al segnale che vuoi avere. Se riesci a fare un sacco di test contro il sito web dovresti essere in grado di aumentare il livello del segnale che potrebbe essere sufficiente a filtrare abbastanza rumore per rendere fattibile questo tipo di attacco. Ma i dettagli dipendono molto dalla reale configurazione del sistema che vuoi abusare.

Per combattere questo tipo di attacco usi operazioni che sono costruite deliberatamente in modo che il loro comportamento non dipenda dall'input. Tali algoritmi sono una parte importante della crittografia pratica, non solo per il confronto delle stringhe semplici, ma anche per l'hashing e la crittografia. E il timing non è l'unico canale laterale, ma devi anche considerare il consumo energetico e persino i canali laterali più bizzarri come le radiazioni.

E probabilmente non hai solo bisogno di dare un'occhiata agli attacchi temporali contro il confronto tra stringhe. La tua applicazione web potrebbe perdere altri dati che rendono più facile la forza bruta, come comportarsi diversamente se il nome utente esiste o meno. Si noti inoltre che l'hashing semplice prima del paragone potrebbe non essere d'aiuto se la funzione di hash che si usa non è resistente contro gli attacchi temporali.

Penso che l'approccio migliore sia quello di limitare seriamente la frequenza per il numero di tentativi di accesso. Questo non solo rende la forza bruta molto più difficile, ma probabilmente renderà anche gli attacchi di temporizzazione non fattibili perché il loro è troppo rumore intorno e il segnale non può essere amplificato a causa della limitazione della velocità.

Anche se questa è certamente un'idea molto interessante, in pratica penso che sia praticamente impossibile sfruttarla. Abbiamo una connessione in fibra qui e anche il tempo di risposta diretto al nostro ISP è dappertutto:

Se la differenza che stai cercando è di pochi nanosecondi, dovresti letteralmente avere già accesso alla macchina locale per iniziare a sperare di poter effettivamente rilevare uno schema affidabile. E se l'aggressore ha accesso al tuo ambiente di rete locale, devi preoccuparti di problemi molto più grandi.

È molto difficile o impossibile sfruttare questa vulnerabilità sulla rete come già affermato da Nic Barker.

Voglio menzionare che è buona pratica definire una soglia di blocco per i meccanismi di autenticazione. Ad esempio: se l'autenticazione del client fallisce per la settima volta, l'ulteriore autenticazione per questo client viene bloccata per almeno 5 minuti. Se un blocco non è possibile, è possibile aggiungere un CAPTCHA (per interfacce umane) o una crittografia al processo di autenticazione.