Ciao a tutti, Pat Reeves qui, di nuovo su botsec.net. Siamo a marzo 2026, e se siete come me, probabilmente avvertite ancora un po’ gli effetti dell’audacia pura di alcune attività di botnet che abbiamo osservato l’anno scorso. Mentre i titoli dei giornali si concentravano sugli attacchi DDoS e sull’exfiltrazione di dati, altre cose sono emerse discretamente, qualcosa che, onestamente, mi impedisce di dormire la notte: le tattiche sempre più sofisticate che i bot utilizzano per eludere i metodi di autenticazione tradizionali, in particolare con l’aumento delle passkey.
Ci è stato detto che le passkey sono il futuro, vero? Resistenti al phishing, criptograficamente sicure, legate a dispositivi. E per buone ragioni, rispondono a molti vecchi punti dolenti. Ma cosa succede quando il meccanismo stesso progettato per proteggerci diventa un vettore di compromissione, non per un difetto nella crittografia stessa, ma per il modo in cui è implementato e, soprattutto, per il modo in cui i bot imparano a manipolare l’elemento umano attorno a questo?
Il paradosso delle passkey: una nuova frontiera per i bot
Pensateci. La promessa delle passkey è che eliminano i segreti condivisi (password) e richiedono un’interazione dell’utente su un dispositivo di fiducia. Ottimo! Niente più credential stuffing, niente più spraying, niente più attacchi di dizionario semplici. Ma i bot, questi piccoli cuori digitali persistenti, non si arrendono facilmente. Si adattano. E ciò che ho osservato, in particolare nei tentativi di takeover di account (ATO) su piattaforme che hanno adottato completamente le passkey, è una deviazione verso l’ingegneria sociale su larga scala, armata dall’automazione.
La mia recente esperienza con un cliente, una piattaforma e-commerce di medie dimensioni che ha investito massicciamente nelle passkey la scorsa estate, mi ha davvero aperto gli occhi. Hanno visto un calo massiccio degli attacchi basati su credenziali tradizionali, il che era fantastico. Ma circa tre mesi fa, hanno iniziato a notare un aumento dei tentativi di “accesso fallito” che erano… diversi. Non erano fallimenti delle password; si trattava di tentativi di avviare la registrazione di passkey o di recupero da dispositivi non riconosciuti, spesso seguiti da una moltitudine di richieste di supporto da parte di utenti legittimi che affermavano che i loro account erano “hackerati” nonostante l’attivazione delle passkey.
Ciò che abbiamo scoperto era un attacco in più fasi. I bot non cercavano di indovinare le passkey; cercavano di ingannare gli utenti generando o approvando nuove passkey su dispositivi controllati dagli aggressori, o coercitando a reimpostare quelle esistenti. È una variante della fatica MFA “approva questo accesso”, ma con rischi più elevati dato che una passkey compromessa significa un controllo totale dell’account.
I dirottamenti delle passkey guidati dai bot: come funziona
Decomponiamo il nuovo manuale dei bot per la compromissione delle passkey. Non si tratta di bruteforcing. Si tratta di un’ingegneria sociale sofisticata su larga scala, amplificata dall’automazione.
- Riconoscimento e Spear-Phishing leggero: I bot raccolgono dati pubblici, dai social media e anche dai dump del dark web per recuperare indirizzi email e numeri di telefono. Poi incrociano questi dati con le piattaforme bersaglio. L’obiettivo non è ottenere una password, ma identificare utenti attivi.
- L’appât del « Nuovo Dispositivo »: Un bot, mimando spesso un browser legittimo o un’applicazione mobile, tenta di avviare una connessione o una registrazione di passkey per un utente noto sulla piattaforma bersaglio. Poiché l’utente non ha una passkey registrata su questo dispositivo specifico (l’ambiente simulato dal bot), la piattaforma richiede spesso un metodo di verifica alternativo o di “aggiungere una nuova passkey”.
- Ingénierie Sociale Automatisée (ASE): È qui che avviene la magia (o meglio, la minaccia). Il bot, avendo attivato una notifica di sistema legittima (email, SMS, notifica push dall’app stessa), segue immediatamente con un tentativo di phishing mirato. Non è un’email generica “reimposta la tua password”. È altamente contestualizzata.
Immaginate questo scenario:
- Ricevete una notifica push legittima dalla vostra app bancaria: “Nuovo tentativo di registrazione di passkey rilevato da un dispositivo sconosciuto. Se sei stato tu, approva. Altrimenti, clicca qui per mettere in sicurezza il tuo account.”
- Allo stesso tempo, ricevete un’email scritta con attenzione, apparentemente dal team di sicurezza della vostra banca, con un oggetto del tipo: “Urgente: Registrazione non autorizzata di passkey rilevata – Azione richiesta.”
- Il contenuto dell’email è personalizzato, forse anche facendo riferimento all’ora esatta del tentativo di registrazione. Ti indirizza a una pagina di phishing che somiglia identicamente al portale di sicurezza della tua banca.
- Su questa pagina di phishing, ti viene chiesto di “verificare la tua identità” inserendo la tua vecchia password (se la banca la supporta ancora per il recupero), oppure, in modo più subdolo, di “revocare passkey non autorizzate”, spingendoti in realtà a *registrare una nuova passkey* sul dispositivo dell’attaccante, mascherato da misura di sicurezza.
La chiave qui è il *momento* e il *contesto*. I bot coordinano queste azioni su larga scala, mirando a migliaia di utenti simultaneamente. L’utente, vedendo una notifica legittima dall’app e un’email molto convincente e tempestiva, è molto più propenso a cadere nella trappola rispetto a un phishing generico.
Strategie di difesa pratiche contro l’abuso di passkey guidato dai bot
Allora, cosa possiamo fare? Non possiamo abbandonare le passkey; rappresentano ancora un grande passo avanti. Ma dobbiamo essere più astuti nel modo in cui le implementiamo e le proteggiamo. Ecco alcuni punti che ho consigliato ai miei clienti, con esempi pratici.
1. Rinforzate il vostro flusso di registrazione di « Nuova Passkey »
Questa è la vulnerabilità più critica. Se un aggressore può ingannare un utente per registrare una nuova passkey sul suo dispositivo, è finita. Avete bisogno di più strati di verifica qui, oltre all’invito iniziale per la passkey.
- Fattore Secondario Obbligatorio per le Nuove Registrazioni: Anche se un utente è già connesso, richiedere una verifica aggiuntiva, fuori banda (come un codice unico inviato a un numero di telefono o a un’email *pre-registrata*, non quella fornita durante il tentativo di registrazione) per *qualsiasi* nuova registrazione o sostituzione di passkey è cruciale.
- Attestazione del Dispositivo (dove possibile): Anche se non è infallibile, l’incorporazione di verifiche di attestazione del dispositivo durante la registrazione delle passkey può aiutare a filtrare le macchine virtuali o gli emulatori ovvi che i bot potrebbero utilizzare. Non si tratta di bloccare utenti legittimi, ma di aggiungere attrito per gli ambienti di aggressori noti.
- Limitazione di Tasso e Rilevazione di Anomalie: Questa è una difesa classica contro i bot, ma si applica ancora di più qui. Limitare in modo aggressivo il numero di tentativi di registrazione di passkey provenienti da indirizzi IP unici o da intervalli di indirizzi IP, abbinato a una rilevazione di anomalie comportamentali (ad esempio, un utente che prova improvvisamente a registrare 5 nuove passkey in un’ora da posizioni geografiche diverse), può segnalare un’attività sospetta.
// Esempio: Pseudocodice per un buon flusso di registrazione di una nuova passkey
function registerNewPasskey(userId, webauthnCredential) {
// 1. Controllare la sessione esistente e la forza dell'autenticazione
if (!isAuthenticatedStrongly(userId)) {
// Forzare la ri-autenticazione o un MFA aggiuntivo
initiateMFAChallenge(userId, "new_passkey_registration");
return; // Attendere la fine della MFA
}
// 2. Effettuare la validazione dell'attestazione FIDO2
if (!validateWebAuthnAttestation(webauthnCredential)) {
logSecurityAlert(userId, "Attestazione WebAuthn non valida durante la registrazione di una nuova passkey");
return;
}
// 3. Opzionale: Verifica dell'impronta del dispositivo / attestazione (lato server)
if (isSuspiciousDeviceFingerprint(request.headers['User-Agent'], request.ip)) {
logSecurityAlert(userId, "Impronta del dispositivo sospetta per la registrazione di una nuova passkey");
initiateMFAChallenge(userId, "suspicious_device_new_passkey");
return;
}
// 4. Verifica dei limiti di tasso per le nuove passkey per utente/IP
if (rateLimitExceeded("new_passkey_registration", userId, request.ip)) {
logSecurityAlert(userId, "Limite di tasso superato per la registrazione di una nuova passkey");
return;
}
// 5. Memorizzare la nuova passkey
storeUserPasskey(userId, webauthnCredential);
sendUserNotification(userId, "Nuova passkey registrata con successo.");
}
2. Migliorare i processi di recupero dell’account
Il recupero dell’account è un’altra target principale. Se un attaccante può avviare un flusso di recupero e poi manipolare l’utente affinché lo approvi, ottiene un accesso secondario.
- Ritardare il recupero dell’account: Implementa un periodo di attesa obbligatorio (ad esempio, 24-48 ore) per le azioni critiche di recupero dell’account, in particolare quelle che comportano la sostituzione di tutte le passkey esistenti. Nel frattempo, notifica proattivamente l’utente tramite tutti i canali di comunicazione noti. Questo offre all’utente legittimo la possibilità di intervenire.
- Verifica KYC tramite Video o Agente in Diretta per Reset Completo: Per le situazioni in cui un utente ha perso tutte le sue passkey e altri metodi di recupero, considera di richiedere una verifica video in diretta con un agente di supporto. È una soluzione ad alto attrito, ma per account critici, è un forte deterrente contro l’ingegneria sociale automatizzata.
- Passkey di “Cassa Vetrina”: Per gli account amministratori interni o i sistemi altamente sensibili, considera di avere una passkey fisica di “cassa vetrina” conservata in un luogo sicuro e auditato, richiedendo più approvazioni per essere utilizzata. Non è per gli account dei consumatori, ma per obiettivi di alto valore, è indispensabile.
3. Educazione degli utenti che funziona realmente
Da decenni facciamo “educazione degli utenti” e, onestamente, la maggior parte di essa fallisce. Per le passkey, abbiamo bisogno di indicazioni mirate, tempestive e specifiche.
- “Cosa Aspettarsi” Guide: Spiega chiaramente agli utenti come appaiono le notifiche di passkey legittime e i processi di recupero. Mostra degli screenshot.
- “Cosa NON Fare” Allerta: Avvisa specificamente gli utenti di non approvare le registrazioni di passkey che non hanno iniziato, né di cliccare su link in e-mail che affermano di “revocare” passkey, soprattutto se non hanno tentato un’azione di sicurezza.
- Verifiche di Sicurezza nell’App: Fornisci una sezione facilmente accessibile nella tua applicazione o sito web dove gli utenti possono vedere tutte le passkey registrate, la loro origine (se possibile) e revocarle. Rendi questo semplice e intuitivo.
// Esempio: Avviso nell'app per attività sospette
function displaySuspiciousActivityWarning(userId, activityDetails) {
const warningMessage = `
⚠ Attività Sospetta Rilevata!
Abbiamo rilevato un tentativo di registrazione di una nuova passkey per il tuo account da un dispositivo non riconosciuto (${activityDetails.ipAddress} - ${activityDetails.location}) a ${activityDetails.timestamp}.
Se eri tu, puoi ignorarlo in tutta sicurezza. Se non eri TU, ti preghiamo di agire immediatamente:
- Vai nelle tue Impostazioni di Sicurezza per esaminare e revocare le passkey.
- Cambia i tuoi altri metodi di recupero (ad esempio, password email).
- Contatta il supporto se hai bisogno di aiuto.
`;
document.getElementById('security-alert-banner').innerHTML = warningMessage;
document.getElementById('security-alert-banner').style.display = 'block';
}
Questo tipo di avviso diretto nell’app, attivato dalla stessa attività di bot contro cui stiamo cercando di difenderci, può essere estremamente efficace.
Consigli Azionabili per gli Esperti di Sicurezza dei Bot
Il campo degli attacchi da bot è sempre in evoluzione. Le passkey sono eccellenti, ma non sono una soluzione miracolosa, e gli attaccanti trovano già nuovi modi per sfruttare l’elemento umano che li circonda. Ecco la mia lista di controllo per te:
- Audita i tuoi Flussi di Passkey: Rivedi ogni flusso legato alle passkey – registrazione, accesso, recupero, revoca – con la mente di un attaccante da bot. Dove può un bot interferire con l’ingegneria sociale?
- La Verifica a Strati è Essenziale: Non contare mai su un solo fattore per azioni ad alto impatto come la registrazione di una nuova passkey o il recupero completo dell’account. Aggiungi una MFA fuori banda.
- Educa, non Limitarti a Informare: Progetta un’educazione degli utenti che sia proattiva, molto specifica per le minacce delle passkey, e integrata direttamente nelle funzionalità di sicurezza della tua applicazione.
- Monitora le Anomalie: Tieni d’occhio i tuoi registri per rilevare modelli insoliti nei tentativi di registrazione di passkey, richieste di recupero e ticket di supporto utenti associati. I bot operano su larga scala e questi modelli emergeranno.
- Non Dimenticare le Basi: Mentre ti concentri sulle passkey, non trascurare le tue difese fondamentali contro i bot per altre parti della tua applicazione: limitazione rigorosa dei tassi, reputazione IP, analisi comportamentale e CAPTCHA quando appropriato. I bot possono evolvere, ma lasciano ancora delle impronte.
Il futuro dell’autenticazione è promettente, ma solo se anticipiamo come gli attori malevoli cercheranno di aggirarlo. Resta vigile, resta sicuro e ci vedremo la prossima volta qui su botsec.net.
Articoli Correlati
- Protezione della privacy dei dati dei bot AI
- Il Mio Parere: OmniMind AI è un Incubo per la Sicurezza
- Notizie sulla Sicurezza AI Oggi: Aggiornamenti Urgenti & Prospettive di Esperti
🕒 Published: