“Brute force” viene spesso usato come termine generico per qualunque tentativo ripetuto di autenticazione. In realtà esistono strategie molto diverse, e distinguerle è importante perché richiedono difese differenti.
Il principio comune è semplice: l’attaccante non conosce il segreto e prova candidati finché uno viene accettato. Ma cambia completamente il problema se i tentativi avvengono contro un servizio online oppure su una copia locale degli hash rubati da un database.
Brute force online
Nell’attacco online ogni tentativo attraversa l’applicazione, SSH, VPN o altro servizio di autenticazione. Questo offre al difensore un enorme vantaggio: possiamo vedere il traffico e rallentarlo.
Un attaccante deve fare i conti con latenza, rate limiting, lockout, MFA, logging e controlli anti-abuso. Per questo i numeri teorici del tipo “milioni di password al secondo” non descrivono un attacco online realistico.
Brute force offline
Lo scenario cambia dopo una violazione del database. Se l’attaccante ottiene gli hash delle password può provare i candidati localmente, senza inviare richieste al servizio e quindi senza rate limiting.
La velocità non dipende soltanto dall’hardware: dipende soprattutto dalla funzione usata per memorizzare la password. Un hash veloce progettato per integrità dei dati permette moltissimi tentativi; una funzione come Argon2id è costruita appositamente per rendere ogni tentativo più costoso in CPU e memoria.
Perché i vecchi calcoli “X password al secondo” sono fuorvianti
Il vecchio articolo del 2012 calcolava quanto tempo impiegasse un processore da 1,4 GHz a provare tutte le combinazioni di sei o otto caratteri. Quel tipo di conto è utile per capire l’esplosione combinatoria, ma non è una misura stabile della sicurezza.
La velocità cambia di ordini di grandezza in funzione di algoritmo, parametri, hardware, parallelismo e qualità dei candidati. Inoltre gli attacchi reali raramente partono da tutte le combinazioni possibili in ordine alfabetico: provano prima le scelte più probabili.
La formula astratta resta valida: con un alfabeto di A simboli e lunghezza L, lo spazio massimo è A^L. Ma una password scelta da un essere umano non è una stringa distribuita uniformemente in quello spazio.
Dictionary attack
Invece di provare tutte le combinazioni, un dictionary attack prova candidati probabili: parole, password comuni, credenziali già comparse in breach, nomi, pattern e variazioni prevedibili.
È spesso molto più efficiente del brute force puro proprio perché sfrutta il comportamento umano. Approfondiamo il tema in Dictionary attack, password spraying e credenziali riutilizzate.
Password spraying
Un lockout per account può rendere inefficiente provare mille password contro lo stesso utente. Il password spraying rovescia il problema: prova una o poche password molto comuni contro molti account differenti.
Brute force classico:
utente1 -> password1
utente1 -> password2
utente1 -> password3
...
Password spraying:
utente1 -> PasswordComune
utente2 -> PasswordComune
utente3 -> PasswordComune
...Per questo una difesa basata soltanto sul numero di errori del singolo account può non bastare. Dobbiamo osservare anche pattern trasversali tra utenti, sorgenti e intervalli temporali.
Credential stuffing
Nel credential stuffing l’attaccante possiede già coppie username/password provenienti da altre violazioni e prova a riutilizzarle sul nostro servizio.
Qui non serve “rompere” nessuna password: basta che l’utente l’abbia riutilizzata. Per questo l’unicità delle credenziali e il password manager sono difese fondamentali.
Difese contro gli attacchi online
- rate limiting e delay progressivi;
- MFA, preferibilmente resistente al phishing per account sensibili;
- blocklist di password note e comuni;
- rilevamento di spraying e credential stuffing;
- alert su pattern anomali;
- protezione contro account enumeration;
- per SSH amministrativo, preferenza per autenticazione a chiave e ACL/VPN.
Fail2Ban: utile, ma non onnisciente
Fail2Ban è efficace quando molti fallimenti arrivano dalla stessa sorgente e vengono registrati con pattern affidabili. Un attacco distribuito oppure uno spraying molto lento può rimanere sotto soglia.
fail2ban-client status
fail2ban-client status sshd
journalctl -u fail2ban --since "-30 min"Per questo Fail2Ban va considerato un livello della difesa, non la difesa completa.
Difese contro gli attacchi offline
Dopo il furto degli hash non possiamo più applicare rate limiting. Rimangono quindi tre grandi protezioni:
- password lunghe e non prevedibili;
- salt unico per ogni credenziale;
- funzioni di password hashing lente e memory-hard, come Argon2id.
Un pepper custodito separatamente dal database può aggiungere difesa in profondità, ma introduce anche un segreto operativo che deve essere gestito e ruotato correttamente.
Monitorare l’autenticazione
Una metrica utile non è soltanto “quanti login falliti abbiamo?”, ma come sono distribuiti:
- molti tentativi sullo stesso account;
- la stessa password sospetta contro molti utenti;
- molti account da una stessa sorgente;
- tentativi distribuiti da moltissimi IP;
- successo immediatamente successivo a una sequenza anomala;
- accessi riusciti da geografie, ASN o device insoliti.
È il punto in cui logging e incident response diventano più importanti del semplice ban automatico.
SSH: eliminare proprio il problema password quando possibile
Per accessi amministrativi possiamo spesso rimuovere l’autenticazione a password e usare chiavi, VPN/rete di Gestione e ACL di rete. In questo modo il guessing della password SSH cessa di essere una superficie utile.
La configurazione completa è descritta in Hardening SSH.
Riferimenti
OWASP Credential Stuffing Prevention · NIST SP 800-63B Revision 4.
