Si noti che le statistiche di THC-Hydra sono state fatte su una macchina che è descritta come esecuzione di SuSE Linux 7.2. Nella storia delle SuSE / SuSE / SUSE / openSUSE distribuzioni Linux, questo ci riporta a metà 2001, quindi questo il benchmark era probabilmente fatto su una macchina di quel periodo. La tecnologia è migliorata da allora e le velocità di elaborazione sono aumentate.
Un tipico "servizio web remoto debole" utilizzerà l'autenticazione di base HTTP, possibilmente all'interno di un tunnel SSL (vale a dire che è HTTPS, non HTTP). Ogni ipotesi di password comporta quindi quanto segue: inviare un'intestazione HTTP che contiene la password presunta (ad esempio 200 byte per l'intestazione) e quindi ottenere una risposta di errore (un codice di errore 401, con un'intestazione che sarà probabilmente meno snella per le dimensioni di quanto l'attaccante sceglie, diciamo 1 kB di intestazione). Poiché HTTP supporta keep-alive , la connessione TCP (o il tunnel SSL / TLS) può essere immediatamente riutilizzata per un altro tentativo; in particolare, ciò significa che non ci sarà un sovraccarico notevole in presenza di SSL. 1000 tentativi al secondo richiede quindi una larghezza di banda di circa 200 kB / s al server, 1 MB / s dal server; questa è una larghezza di banda di 10 Mbit / s e anche i servizi di hosting economici offrono così tanto. Sulle reti locali, 100 MBit / s o maggiore sono la norma. Nessun problema di larghezza di banda qui.
Naturalmente, l'attaccante dovrebbe provare a parallelizzare per evitare la latenza. Non è necessario attendere la risposta del server prima di inviare un'altra richiesta. Parallelizzazione, qui, significa aprire un centinaio di connessioni al server di destinazione e eseguirle in parallelo. I sistemi operativi, al giorno d'oggi, possono gestire molte migliaia di connessioni aperte; cento non affamano la macchina.
Lato server, poiché tutti i tentativi mirano allo stesso utente la password (con hash) sarà nella RAM (normalmente è memorizzata in un file o database, ma la RAM viene utilizzata come cache per i dati utilizzati di frequente, e durante una password- sessione di cracking che l'elemento di dati sarà molto frequentemente accessibile). Dato che stiamo parlando di un servizio web remoto weak , il server memorizzerà le password "così com'è" o hash con una semplice funzione di hash, non qualcosa come bcrypt . Il ridimensionamento di ogni password in ingresso userà una CPU trascurabile (un PC anemico può calcolare milioni di hash al secondo, quindi 1.000 hash al secondo non sono nulla). Allo stesso modo, l'analisi dell'intestazione HTTP non utilizzerà molta CPU.
Quindi 1000 ipotesi di password al secondo sembrano una cifra altamente fattibile; in realtà, non dovrebbe essere troppo difficile superarlo con un ampio margine. Nota i punti importanti nella discussione sopra:
- L'attaccante può parallelizzare, dal momento che ha molte password da provare.
- L'autenticazione avviene molto presto nell'elaborazione di una richiesta in arrivo, quindi i normali costi di elaborazione delle richieste (per qualsiasi funzionalità fornita dal servizio Web) non si applicano).
- L'uso della funzione di hashing lento (come bcrypt) può essere efficace in una situazione del genere.