Bonjour à tous, Pat Reeves ici, de retour sur botsec.net. Nous sommes en mars 2026, et si vous êtes comme moi, vous êtes probablement encore un peu sous le choc de l’audace de certaines des activités de botnet que nous avons observées l’année dernière. Alors que les gros titres mettaient l’accent sur les attaques DDoS et l’exfiltration de données, quelque chose d’autre a discrètement fait surface, quelque chose qui, franchement, m’empêche de dormir la nuit : les tactiques de plus en plus sophistiquées que les bots utilisent pour contourner les méthodes d’authentification traditionnelles, surtout avec la montée des passkeys.
On nous dit que les passkeys sont l’avenir, non ? Résistantes au phishing, cryptographiquement sécurisées, liées à un appareil. Et pour de bonnes raisons, elles répondent à de nombreux anciens points de douleur. Mais que se passe-t-il lorsque le mécanisme même conçu pour nous protéger devient un vecteur de compromission, non pas à cause d’un défaut dans la cryptographie elle-même, mais par la manière dont il est implémenté et, surtout, par la façon dont les bots apprennent à manipuler l’élément humain qui l’entoure ?
Le Paradoxe des Passkeys : Une Nouvelle Frontière pour les Bots
Pensez-y. La promesse des passkeys est qu’elles éliminent les secrets partagés (mots de passe) et nécessitent une interaction de l’utilisateur sur un appareil de confiance. Super ! Plus de credential stuffing, plus de spraying, plus d’attaques simples par dictionnaire. Mais les bots, qu’ils se nomment, ne se laissent pas décourager. Ils s’adaptent. Et ce que j’ai observé, en particulier dans les tentatives de takeover de compte (ATO) sur des plateformes qui ont entièrement adopté les passkeys, c’est un glissement vers l’ingénierie sociale à grande échelle, armée par l’automatisation.
Mon expérience récente avec un client, une plateforme de commerce électronique de taille intermédiaire qui a totalement embrassé les passkeys l’été dernier, m’a vraiment ouvert les yeux. Ils ont constaté une énorme baisse des attaques basées sur des identifiants traditionnels, ce qui était fantastique. Mais ensuite, il y a environ trois mois, ils ont commencé à remarquer une hausse des tentatives de « connexion échouée » qui étaient… différentes. Ce n’était pas des échecs de mot de passe ; c’étaient des tentatives d’initier l’enregistrement ou la récupération de passkeys depuis des appareils non reconnus, souvent suivies d’une flurry de demandes de support de la part d’utilisateurs légitimes prétendant que leurs comptes avaient été « piratés » malgré l’activation des passkeys.
Ce que nous avons découvert était une attaque en plusieurs étapes. Les bots n’essayaient pas de deviner les passkeys ; ils tentaient de tromper les utilisateurs pour qu’ils *génèrent* ou *approuvent* de nouvelles passkeys sur des appareils contrôlés par l’attaquant, ou les contraindre à réinitialiser celles existantes. C’est une variation de l’ancienne fatigue liée à la MFA du type « approuvez cette connexion », mais avec des enjeux plus élevés car une passkey compromise signifie un contrôle total du compte.
Détournements de Passkeys par les Bots : Comment Ça Fonctionne
Détaillons le nouveau manuel des bots pour la compromission des passkeys. Il ne s’agit pas de brute-forcing. Il s’agit d’ingénierie sociale sophistiquée à grande échelle, amplifiée par l’automatisation.
- Reconnaissance et Spear-Phishing léger : Les bots fouillent les données publiques, les réseaux sociaux, et même les dumps du dark web pour des adresses e-mail et des numéros de téléphone. Ils croisent ensuite ces informations avec les plateformes cibles. L’objectif n’est pas d’obtenir un mot de passe, mais d’identifier des utilisateurs actifs.
- Le piège du « Nouvel Appareil » : Un bot, imitant souvent un navigateur ou une application mobile légitime, tente d’initier une connexion ou un enregistrement de passkey pour un utilisateur connu sur la plateforme cible. Puisque l’utilisateur n’a pas de passkey enregistrée sur cet appareil spécifique (l’environnement simulé du bot), la plateforme demande souvent une méthode de vérification alternative ou de « ajouter une nouvelle passkey. »
- Ingénierie Sociale Automatisée (ASE) : C’est ici que la magie (ou plutôt, la menace) se produit. Le bot, ayant déclenché une notification système légitime (email, SMS, notification push de l’application elle-même), suit immédiatement avec une tentative de phishing ciblée. Ce n’est pas un e-mail générique de « réinitialisez votre mot de passe ». C’est hautement contextuel.
Imaginez ce scénario :
- Vous recevez une notification push légitime de votre application bancaire : « Tentative d’enregistrement de nouvelle passkey détectée depuis un appareil inconnu. Si c’était vous, approuvez. Sinon, cliquez ici pour sécuriser votre compte. »
- Simultanément, vous recevez un e-mail méticuleusement conçu, apparemment de l’équipe de sécurité de votre banque, avec un sujet tel que : « Urgent : Enregistrement de passkey non autorisé détecté – Action requise. »
- Le contenu de l’e-mail est ciblé, faisant peut-être même référence à l’heure spécifique de la tentative d’enregistrement. Il vous dirige vers une page de phishing qui ressemble à s’y méprendre au portail de sécurité de votre banque.
- Sur cette page de phishing, on vous demande de « vérifier votre identité » en entrant votre ancien mot de passe (si la banque le supporte encore pour la récupération), ou, plus sournoisement, de « révoquer les passkeys non autorisées » ce qui vous incite en fait à *enregistrer une nouvelle passkey* sur l’appareil de l’attaquant, déguisé en mesure de sécurité.
Le clé ici est le *temps* et le *contexte*. Les bots coordonnent ces actions à grande échelle, frappant des milliers d’utilisateurs simultanément. L’utilisateur, voyant une notification légitime de l’application et un e-mail très convaincant et opportun, est beaucoup plus susceptible de se faire avoir que par une escroquerie de phishing générique.
Stratégies de Défense Pratiques Contre l’Abus des Passkeys par les Bots
Alors, que pouvons-nous faire ? Nous ne pouvons pas jeter les passkeys ; elles représentent encore un immense progrès. Mais nous devons être plus intelligents sur la façon dont nous les déployons et les protégeons. Voici quelques conseils que j’ai donnés à mes clients, avec quelques exemples pratiques.
1. Renforcez Votre Flux d’Enregistrement de « Nouvelle Passkey »
C’est la vulnérabilité la plus critique. Si un attaquant peut convaincre un utilisateur d’enregistrer une nouvelle passkey sur son appareil, c’est la fin. Vous avez besoin de plusieurs couches de vérification ici, au-delà de la simple invite de passkey initiale.
- Deuxième facteur obligatoire pour les nouvelles enregistrements : Même si un utilisateur est déjà connecté, exiger une vérification supplémentaire hors bande (comme un code unique envoyé à un numéro de téléphone ou une adresse e-mail *pré-enregistrés*, pas celui fourni pendant la tentative d’enregistrement) pour *tout* nouvel enregistrement ou remplacement de passkey est crucial.
- Attestation de l’Appareil (lorsque cela est possible) : Bien que ce ne soit pas infaillible, l’incorporation de vérifications d’attestation d’appareil pendant l’enregistrement de la passkey peut aider à filtrer les machines virtuelles ou émulateurs évidents que les bots pourraient utiliser. Il ne s’agit pas de bloquer les utilisateurs légitimes, mais d’ajouter des frottements pour les environnements connus d’attaquants.
- Limitation de Taux et Détection d’Anomalies : Cela fait partie de la défense classique contre les bots, mais cela s’applique encore plus ici. Une limitation de taux agressive sur les tentatives d’enregistrement de passkeys provenant d’adresses IP uniques ou de plages d’IP, couplée avec la détection d’anomalies comportementales (par exemple, un utilisateur tentant soudainement d’enregistrer 5 nouvelles passkeys en une heure depuis différents endroits géographiques), peut signaler une activité suspecte.
// Exemple : Pseudocode pour un bon flux d'enregistrement de nouvelle passkey
function registerNewPasskey(userId, webauthnCredential) {
// 1. Vérifier la session existante et la force d'authentification
if (!isAuthenticatedStrongly(userId)) {
// Forcer la ré-authentification ou ajouter une MFA supplémentaire
initiateMFAChallenge(userId, "new_passkey_registration");
return; // Attendre la fin de la MFA
}
// 2. Validation de l'attestation FIDO2
if (!validateWebAuthnAttestation(webauthnCredential)) {
logSecurityAlert(userId, "Attestation WebAuthn invalide lors de l'enregistrement de la nouvelle passkey");
return;
}
// 3. Optionnel : Vérification de l'empreinte de l'appareil (côté serveur)
if (isSuspiciousDeviceFingerprint(request.headers['User-Agent'], request.ip)) {
logSecurityAlert(userId, "Empreinte de l'appareil suspecte pour l'enregistrement de la nouvelle passkey");
initiateMFAChallenge(userId, "suspicious_device_new_passkey");
return;
}
// 4. Vérification de limitation de taux pour les nouvelles passkeys par utilisateur/IP
if (rateLimitExceeded("new_passkey_registration", userId, request.ip)) {
logSecurityAlert(userId, "Limite de taux dépassée pour l'enregistrement de la nouvelle passkey");
return;
}
// 5. Stocker la nouvelle passkey
storeUserPasskey(userId, webauthnCredential);
sendUserNotification(userId, "Nouvelle passkey enregistrée avec succès.");
}
2. Améliorez les Processus de Récupération de Compte
La récupération de compte est une autre cible privilégiée. Si un attaquant peut initier un flux de récupération puis manipuler l’utilisateur pour qu’il l’approuve, il a une porte dérobée.
- Retarder la Récupération de Compte : Implémentez une période d’attente obligatoire (par exemple, 24-48 heures) pour les actions critiques de récupération de compte, en particulier celles impliquant le remplacement de toutes les passkeys existantes. Pendant ce temps, informez l’utilisateur de manière proactive via tous les canaux de communication connus. Cela donne une chance à l’utilisateur légitime d’intervenir.
- Vérification KYC Vidéo ou Agent en Direct pour Réinitialisation Complète : Pour les situations où un utilisateur a perdu toutes ses passkeys et autres méthodes de récupération, envisagez d’exiger une vérification vidéo en direct avec un agent de support. C’est une solution à fort frottement, mais pour des comptes critiques, c’est un puissant moyen de dissuasion contre l’ingénierie sociale automatisée.
- Passkeys « Casser le Verre » : Pour les comptes administratifs internes ou les systèmes hautement sensibles, envisagez d’avoir une passkey physique « casser le verre » stockée dans un endroit sécurisé et audité, nécessitant plusieurs approbations pour être utilisée. Ce n’est pas pour les comptes consommateurs, mais pour les cibles de grande valeur, c’est indispensable.
3. Sensibilisation des Utilisateurs qui Fonctionne Vraiment
Nous faisons de la « sensibilisation des utilisateurs » depuis des décennies, et honnêtement, la plupart du temps, cela ne fonctionne pas. Pour les passkeys, nous avons besoin d’instructions ciblées, opportunes et spécifiques.
- “Guides sur ce à quoi s’attendre” : Expliquez clairement aux utilisateurs à quoi ressemblent les notifications et les processus de récupération de passkey légitimes. Montrez des captures d’écran.
- “Alertes sur quoi NE PAS faire” : Avertissez spécifiquement les utilisateurs de ne pas approuver les enregistrements de passkey qu’ils n’ont pas initiés, ni de cliquer sur des liens dans des e-mails qui prétendent “révoquer” des passkeys, surtout s’ils n’ont pas eux-mêmes tenté une action de sécurité récemment.
- Contrôles de sécurité dans l’application : Fournissez une section facile à trouver dans votre application ou site Web où les utilisateurs peuvent voir toutes les passkeys enregistrées, leur origine (si possible), et les révoquer. Rendez cela simple et intuitif.
// Exemple : Alerte dans l'application pour activité suspecte
function displaySuspiciousActivityWarning(userId, activityDetails) {
const warningMessage = `
⚠ Activité suspecte détectée !
Nous avons détecté une tentative d'enregistrement d'une nouvelle passkey pour votre compte depuis un appareil non reconnu (${activityDetails.ipAddress} - ${activityDetails.location}) à ${activityDetails.timestamp}.
Si c'était vous, vous pouvez l'ignorer en toute sécurité. Si ce n'était PAS vous, veuillez agir immédiatement :
- Allez dans vos Paramètres de sécurité pour revoir et révoquer les passkeys.
- Changez vos autres méthodes de récupération (par exemple, mot de passe de l'email).
- Contactez le support si vous avez besoin d'aide.
`;
document.getElementById('security-alert-banner').innerHTML = warningMessage;
document.getElementById('security-alert-banner').style.display = 'block';
}
Ce type d’avertissement direct dans l’application, déclenché par la même activité de bot contre laquelle nous essayons de nous défendre, peut être incroyablement efficace.
Leçons pratiques pour les professionnels de la sécurité des bots
Le domaine des attaques de bots est en constante évolution. Les passkeys sont excellentes, mais elles ne sont pas une solution miracle, et les attaquants trouvent déjà de nouvelles façons d’exploiter l’élément humain qui les entoure. Voici ma liste d’actions pour vous :
- Auditez vos flux de passkey : Passez en revue chaque flux lié aux passkeys – enregistrement, connexion, récupération, révocation – avec l’état d’esprit d’un attaquant de bot. Où un bot pourrait-il intercepter une ingénierie sociale ?
- La vérification en plusieurs étapes est essentielle : Ne comptez jamais sur un seul facteur pour des actions à fort impact comme l’enregistrement d’une nouvelle passkey ou la récupération complète d’un compte. Ajoutez une MFA hors bande.
- Éduquez, ne vous contentez pas d’informer : Concevez une éducation utilisateur qui soit proactive, hautement spécifique aux menaces de passkey, et intégrée directement dans les fonctionnalités de sécurité de votre application.
- Surveillez les anomalies : Gardez un œil attentif sur vos journaux pour détecter des modèles inhabituels dans les tentatives d’enregistrement de passkey, les demandes de récupération et les tickets de support utilisateur associés. Les bots opèrent à grande échelle, et ces motifs vont émerger.
- Ne négligez pas les bases : Tout en vous concentrant sur les passkeys, n’oubliez pas vos défenses fondamentales contre les bots pour d’autres parties de votre application : limitation de débit stricte, réputation IP, analyse comportementale, et CAPTCHAs là où c’est approprié. Les bots peuvent évoluer, mais ils laissent toujours des traces.
Le futur de l’authentification est prometteur, mais seulement si nous anticipons comment les acteurs malveillants vont essayer de le subvertir. Restez vigilant, restez sécurisé, et je vous retrouverai la prochaine fois ici sur botsec.net.
Articles connexes
- Protection de la vie privée des données des bots IA
- Mon avis : OmniMind IA est un cauchemar de sécurité
- Actualités sur la sécurité de l’IA aujourd’hui : Mises à jour urgentes & Perspectives d’experts
🕒 Published: