Furto di account nel 2026: perché il credential stuffing continua a vincere e cosa lo ferma
Il credential stuffing riesce perché il riutilizzo delle password rende l'economia dell'attacco nettamente favorevole agli aggressori. La 2FA copre solo la minoranza iscritta: l'intelligence dei dispositivi al login è la leva decisiva.
Il furto di account è la categoria di frode che la maggior parte delle piattaforme sottovaluta. Le perdite non compaiono come una singola voce di bilancio: sono disperse tra «ticket di assistenza per account bloccati», «chargeback da transazioni contestate», «abbandono da parte di utenti frustrati che hanno perso l'accesso» e «sanzioni normative quando la compromissione era soggetta a obbligo di notifica».
Il costo aggregato è ingente. Javelin Strategy ha stimato le perdite USA da furto di account in 11 miliardi di dollari nel 2024. I numeri globali sono più alti. Il trend è in crescita, non in calo: le fughe di credenziali si sommano, gli strumenti di automazione costano meno, la capacità degli aggressori supera quella dei difensori nella maggior parte delle piattaforme.
Questo articolo è rivolto ai responsabili di security, prodotto e rischio delle piattaforme con flussi di login degni di protezione. Scritto per spiegare come si presenta davvero il credential stuffing (letteralmente «riempimento di credenziali») nel 2026, perché le difese che la maggior parte delle piattaforme adotta non bastano e quali pattern architetturali reggono.
La meccanica del credential stuffing moderno
Il credential stuffing non è un attacco tecnicamente sofisticato. È uno sfruttamento economico del fatto che la maggior parte delle persone riutilizza le password tra i vari servizi.
La meccanica:
Fase 1: raccolta delle credenziali. Le violazioni di dati di altri servizi producono dump di credenziali contenenti miliardi di coppie username-password. I dump freschi si vendono su mercati privati a 200–2.000 dollari a seconda di qualità e recency. I dump più vecchi sono sostanzialmente gratuiti.
Fase 2: targeting. Gli aggressori individuano le piattaforme che vale la pena attaccare — piattaforme di pagamento, exchange di criptovalute, e-commerce con metodi di pagamento salvati, operatori iGaming con depositi, SaaS con dati di valore. La lista dei bersagli è ampia perché il costo marginale di testare più piattaforme è prossimo allo zero.
Fase 3: automazione. Script o sistemi guidati da agenti testano le coppie di credenziali contro gli endpoint di login su larga scala. Il volume è tipicamente di 50.000–200.000 tentativi all'ora da infrastruttura distribuita. Gli aggressori moderni usano pool di proxy residenziali per far sembrare i singoli tentativi traffico di consumatori.
Fase 4: filtraggio dei login riusciti. Una tipica campagna di credential stuffing contro una singola piattaforma produce un tasso di successo dello 0,5–3% (credenziali ancora valide). I login riusciti vengono categorizzati per valore: i conti bancari vanno a un operatore, i wallet crypto a un altro, gli e-commerce con carte salvate a un terzo.
Fase 5: monetizzazione. Prelevare fondi dove possibile, effettuare ordini fraudolenti dove l'estrazione diretta non è disponibile, modificare i contatti di recupero per mantenere il controllo. Questa fase coinvolge spesso un operatore diverso da quello che ha condotto la campagna di stuffing: le credenziali valide sono una merce che viene scambiata.
I conti economici favoriscono l'aggressore. Il costo per tentativo di login è di frazioni di centesimo. Il costo per compromissione riuscita è di pochi dollari. Il valore medio estratto per compromissione è di 1.200–5.000 dollari. L'economia unitaria sostiene operazioni su scala industriale.
Perché la 2FA non è la risposta che la maggior parte dei team spera
La difesa intuitiva contro il credential stuffing è l'autenticazione a due fattori. Le credenziali possono essere valide, ma senza il secondo fattore l'aggressore non riesce ad accedere. Questo è vero in linea di principio e parzialmente vero nella pratica.
La valutazione onesta della 2FA nel 2026:
2FA via SMS. La forma più comune perché è la più facile da distribuire. È anche la più debole. Gli attacchi di SIM-swap aggirano la 2FA via SMS su larga scala. Le campagne di phishing raccolgono i codici 2FA insieme alle password. Per gli account di alto valore, gli aggressori investono spesso lo sforzo aggiuntivo per sconfiggere specificamente la 2FA via SMS, proprio perché il valore per account lo giustifica.
2FA basata su TOTP. Più robusta dell'SMS. Richiede agli utenti di installare un'app di autenticazione e registrare i dispositivi. Il problema è l'adozione: le piattaforme tipiche vedono l'iscrizione a TOTP tra il 25% e il 40% degli utenti attivi nonostante anni di incentivi. Il restante 60–75% degli account non ha alcuna protezione TOTP.
2FA basata su push. Prompt di approvazione/rifiuto su un dispositivo mobile registrato. La più robusta delle tre perché il phishing richiede una configurazione più sofisticata per sconfiggere i prompt push. L'adozione è persino inferiore a TOTP perché richiede app mobili specifiche della piattaforma e l'attrito di iscrizione è più alto.
WebAuthn / FIDO2. Autenticazione ancorata all'hardware tramite biometria del dispositivo o chiavi di sicurezza. Sconfigge la maggior parte delle categorie di attacco. L'adozione è estremamente bassa perché richiede una capacità hardware che l'utente potrebbe non avere e la UX non è familiare.
Il pattern: le forme di 2FA più robuste hanno un'adozione più bassa. La 2FA supportata dalla sua piattaforma è abilitata per una certa percentuale di utenti, e il credential stuffing prende di mira semplicemente la percentuale restante. Per le piattaforme con il 35% di adozione TOTP, l'aggressore ha comunque il 65% degli account su cui lavorare.
La 2FA è necessaria. Ma non è nemmeno sufficiente.
Cosa aggiunge al quadro l'intelligence dei dispositivi
Il principio difensivo: gli utenti legittimi accedono tipicamente da dispositivi che hanno già usato. La stessa persona dallo stesso laptop, dallo stesso telefono, dalla stessa rete — pattern riconoscibili di accesso ripetuto.
Gli attacchi di credential stuffing rompono questo pattern per definizione. L'aggressore non ha accesso al dispositivo dell'utente legittimo. Ogni credenziale valida viene testata da un'infrastruttura che l'utente legittimo non ha mai usato. È questo il segnale che l'intelligence dei dispositivi intercetta.
L'architettura:
Al tentativo di login: l'SDK sul client cattura il fingerprint del dispositivo insieme alle credenziali. Il server riceve il tentativo di login, le credenziali e il fingerprint del dispositivo tutti insieme.
Controllo lato server: questo dispositivo è già stato visto per questo account? In caso affermativo — dispositivo noto, comportamento normale, si prosegue. In caso negativo — dispositivo sconosciuto, verifica aggiuntiva richiesta.
Verdetto a tre vie:
- ALLOW: dispositivo noto, pattern normale, rischio basso → il login prosegue
- CHALLENGE: dispositivo sconosciuto o pattern sospetto → verifica di step-up (codice SMS, conferma via e-mail, prompt biometrico)
- BLOCK: fingerprint di dispositivo noto come malevolo (parte di un cluster di credential stuffing, browser anti-rilevamento, ecc.) → login rifiutato
Lo step di challenge sostituisce il modello «richiedi sempre la 2FA» con «richiedi una verifica aggiuntiva solo quando il pattern del dispositivo suggerisce un rischio». Gli utenti legittimi dai loro dispositivi abituali sperimentano zero attrito. I tentativi sospetti da dispositivi mai visti vengono sottoposti a challenge. L'infrastruttura confermata come malevola viene bloccata.
I conti sui falsi positivi contano. Una piattaforma con 1 milione di login mensili, dove il 5% degli utenti legittimi acquista un nuovo laptop o telefono in un dato mese, produrrà 50.000 eventi di challenge al mese solo da questa transizione. Fatte bene, queste challenge sono rapide (codice SMS, notifica dell'app) e l'attrito è accettabile. Fatte male (imponendo una ri-verifica completa, bloccando gli account in attesa di revisione dell'assistenza), l'attrito per gli utenti legittimi soverchia il beneficio di sicurezza.
L'architettura ben calibrata produce tassi di falsi positivi sotto lo 0,5% — una challenge ogni 200 login legittimi. Questo è accettabile perché le challenge sono a basso attrito e rapide.
E l'aggressore che impara?
Gli aggressori sofisticati conoscono l'intelligence dei dispositivi. La contromossa naturale è provare a far combaciare il pattern del dispositivo dell'utente legittimo. Gli aggressori riescono a farlo?
La risposta onesta: parzialmente. Alcuni pattern di attacco si adattano all'intelligence dei dispositivi:
Pattern 1: credential stuffing con dispositivo abbinato. L'aggressore arricchisce i dump di credenziali con indizi sul dispositivo provenienti dalla stessa violazione (User-Agent, cronologia di geolocalizzazione IP). Tenta ogni credenziale da un'infrastruttura che corrisponde grosso modo al profilo dell'utente legittimo. Questo adattamento è reale ma non banale: richiede dati che l'aggressore non sempre possiede, e far combaciare l'infrastruttura è più difficile che falsificare l'User-Agent.
Pattern 2: furto di account tramite phishing anziché stuffing. L'aggressore convince l'utente legittimo ad accedere attraverso un ambiente controllato, raccogliendo sia le credenziali sia le caratteristiche del dispositivo. Questa categoria di attacco esiste ma opera a volumi molto più ridotti del credential stuffing: il phishing è lavoro per singola vittima, lo stuffing è su scala industriale.
Pattern 3: SIM-swap combinato con riutilizzo di credenziali. L'aggressore prende il controllo del numero di telefono, poi usa le credenziali trafugate più il numero acquisito per sconfiggere sia le difese basate su password sia la 2FA via SMS. L'intelligence dei dispositivi intercetta comunque questo caso perché il dispositivo di login dell'aggressore è nuovo per l'account. Il SIM-swap sconfigge la 2FA via SMS ma non le difese basate sul dispositivo.
Il pattern: l'intelligence dei dispositivi alza significativamente l'asticella senza renderla insormontabile. Combinata con l'autenticazione di step-up basata sul rischio, costringe gli aggressori o a investire molto di più per account (sconfiggendo l'economia dello stuffing di massa) o a individuare specifici bersagli di alto valore e condurre attacchi mirati (che diventano di volume ridotto e più facili da investigare).
Come si presenta un deployment efficace
Un istituto di credito digitale con 200.000 clienti attivi, saldo medio del conto 500 dollari. Prima del deployment: 230 incidenti di furto di account al mese, perdita diretta media per incidente 1.200 dollari. Totale: 276.000 dollari al mese in perdite dirette, più danno reputazionale e sovraccarico dell'assistenza.
Architettura distribuita:
- SDK sulla pagina di login che cattura il fingerprint del dispositivo a ogni tentativo
- Chiamata di verifica lato server prima del completamento dell'autenticazione
- Regola: se il fingerprint del dispositivo non è mai stato visto per questo account, il verdetto è CHALLENGE
- Meccanismo di challenge: conferma via SMS o e-mail (a seconda di quale sia registrata)
- Blocco automatico per i fingerprint appartenenti a cluster noti di credential stuffing
Risultati a 60 giorni:
- Incidenti ATO al mese: 230 → 7
- Riduzione delle perdite dirette: da 276.000 dollari al mese a 8.000 dollari al mese
- Tasso di blocco sui tentativi di credential stuffing: 99,6% allo stadio di verifica del dispositivo
- Tasso di falsi positivi: 0,3% — circa 1 login legittimo su 350 riceve una CHALLENGE
- Volume dell'assistenza clienti su problemi di accesso agli account: in calo del 60%
- Abbandono dei clienti attribuito alla compromissione degli account: in calo dell'89%
Il deployment ha richiesto 4 giorni lavorativi. L'integrazione del backend è stata semplice: il flusso di autenticazione esistente è rimasto invariato, il livello di intelligence dei dispositivi è stato aggiunto come wrapper che restituiva il verdetto prima dell'evento di completamento dell'autenticazione.
I conti sul ROI: l'infrastruttura di rilevamento è costata circa 2.000 dollari al mese a questa scala. Risparmi: 268.000 dollari al mese. ROI di 134× nel primo anno, con rendimenti marginali decrescenti man mano che il tasso di attacco si normalizza sull'equilibrio più basso.
Cosa significa per il suo team
Se gestisce una piattaforma con un endpoint di login che protegge qualcosa di valore — denaro, dati, contenuti, stato dell'account — tre osservazioni:
Osservazione 1: ha un problema di ATO che lo misuri o no. La maggior parte delle piattaforme sottovaluta le perdite da ATO perché sono disperse su più voci di bilancio. L'esercizio di misurazione onesto comprende: contare i ticket di assistenza per account bloccati, attribuire i chargeback alla compromissione degli account dove possibile, indagare le ragioni dell'abbandono, esaminare i pattern di login riusciti alla ricerca di eventi da dispositivo mai visto prima. Il numero che emerge è di solito 2–3× quello che la leadership crede.
Osservazione 2: la 2FA da sola non è sufficiente. È necessaria, ma copre solo la percentuale di utenti che si sono iscritti. Il credential stuffing prende di mira la percentuale non iscritta, che di solito è il 60%+. L'intelligence dei dispositivi copre gli utenti che non si sono iscritti alla 2FA — cioè la maggior parte.
Osservazione 3: il rilevamento al login è leva. La maggior parte delle categorie di frode richiede un'indagine post-evento. L'ATO tramite credential stuffing può essere rilevato al tentativo di login stesso. Questo lo rende uno dei deployment di rilevamento a più alta leva: impedire il successo dell'attacco anziché ripulire dopo.
Le piattaforme che gestiscono bene questo aspetto condividono un pattern: misurano il proprio tasso di ATO reale ogni trimestre, distribuiscono l'intelligence dei dispositivi al livello di login indipendentemente dal loro tasso di adozione della 2FA, e trattano il tasso di falsi positivi come metrica primaria da ottimizzare.
I prossimi 18 mesi
Tre previsioni:
Previsione 1: la qualità dei dump di credenziali migliora. Le violazioni recenti includeranno un contesto più ricco (caratteristiche del dispositivo, pattern comportamentali, cronologia di rete) che consente agli aggressori di soddisfare più efficacemente le aspettative dei difensori. L'asticella per il rilevamento si alza.
Previsione 2: il credential stuffing guidato da agenti diventa mainstream. Gli agenti guidati da LLM gestiscono l'intero flusso — incluso il recupero, la gestione delle challenge MFA, la navigazione post-login — rendendo ogni compromissione riuscita più approfondita. La sfida di rilevamento si sposta verso l'identificazione delle sessioni guidate da agenti anche quando sembrano umane.
Previsione 3: le piattaforme che non distribuiscono l'intelligence dei dispositivi entro la fine del 2026 affrontano un'esposizione significativa. La combinazione di dump di credenziali più economici, aggressori più intelligenti e strumenti di attacco in miglioramento significa che le piattaforme che si affidano alla sola 2FA vedranno i tassi di ATO salire sensibilmente, mentre le piattaforme ben difese continueranno ad abbassare i propri.
La finestra per anticipare tutto questo sono i prossimi 12–18 mesi. Le piattaforme che si attivano ora avranno una posizione difendibile. Quelle che aspettano si ritroveranno a inseguire aggressori dotati di strumenti migliori.
Dove si colloca Tracio
Tracio è intelligence dei dispositivi costruita per la difesa del login, tra gli altri casi d'uso. L'architettura copre i segnali che intercettano il credential stuffing in modo affidabile: fingerprinting del dispositivo (130+ segnali), analisi a livello di rete (fingerprinting TCP/TLS, reputazione ASN), pattern comportamentali al login (ritmo di digitazione, jitter del mouse, caratteristiche temporali), abbinamento a cluster noti come malevoli dalla condivisione di segnali tra clienti.
Il verdetto — ALLOW, CHALLENGE o BLOCK — viene restituito in meno di 50 millisecondi. L'integrazione è rapida: il livello di intelligence dei dispositivi avvolge il suo flusso di autenticazione esistente senza richiedere modifiche al backend. Il verdetto indica al suo sistema di autenticazione se procedere normalmente, richiedere una verifica aggiuntiva o rifiutare il tentativo.
Il livello JavaScript polimorfico ruota quotidianamente, negando agli aggressori la possibilità di distribuire evasioni efficaci contro il rilevamento statico. La rete di segnali tra clienti condivide dati di fingerprint anonimizzati tra le piattaforme, intercettando le operazioni di credential stuffing che si estendono su più bersagli.
Tempi di deployment per la maggior parte delle piattaforme: 1–3 giorni dalla registrazione alla produzione. Il piano gratuito copre 2.500 verifiche al mese, sufficienti per condurre un pilota significativo su un sottoinsieme del traffico di login e misurare il suo tasso di ATO reale.
Curiosi di sapere come appare il suo tasso di ATO reale?
Avvii la sua prova gratuita — 2.500 verifiche gratuite, senza carta di credito. Prenoti una demo per vedere come appaiono i pattern specifici del suo traffico di login con il livello di rilevamento completo di Tracio.