Salut tout le monde, Pat Reeves ici, de retour sur botsec.net. Nous sommes en mars 2026, et si vous êtes comme moi, vous ressentez probablement encore un peu les effets de l’audace pure de certaines activités de botnet que nous avons observées l’année dernière. Alors que les gros titres se concentraient sur les attaques DDoS et l’exfiltration de données, d’autres choses ont discrètement émergé, quelque chose qui, honnêtement, 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, en particulier avec la montée des passkeys.
On nous a dit que les passkeys sont l’avenir, n’est-ce pas ? Résistants au phishing, cryptographiquement sécurisés, liés à des appareils. Et pour de bonnes raisons, ils 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 par un défaut dans la cryptographie elle-même, mais dans la manière dont il est implémenté et, surtout, dans la façon dont les bots apprennent à manipuler l’élément humain autour de cela ?
Le paradoxe des passkeys : une nouvelle frontière pour les bots
Pensez-y. La promesse des passkeys est qu’ils éliminent les secrets partagés (mots de passe) et nécessitent une interaction utilisateur sur un appareil de confiance. Super ! Plus de credential stuffing, plus de spraying, plus d’attaques de dictionnaire simples. Mais les bots, ces petits cœurs numériques persistants, ne renoncent pas facilement. Ils s’adaptent. Et ce que j’ai observé, notamment dans les tentatives de takeover de comptes (ATO) sur des plateformes qui ont pleinement adopté les passkeys, c’est un virage vers l’ingénierie sociale à grande échelle, armée par l’automatisation.
Mon expérience récente avec un client, une plateforme e-commerce de taille moyenne qui a investi massivement dans les passkeys l’été dernier, m’a vraiment ouvert les yeux. Ils ont vu une chute massive 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 augmentation des tentatives de « connexion échouée » qui étaient… différentes. Ce n’étaient pas des échecs de mots de passe ; il s’agissait de tentatives d’initier l’enregistrement de passkeys ou de récupération depuis des appareils non reconnus, souvent suivies d’une multitude de demandes d’assistance de la part d’utilisateurs légitimes affirmant que leurs comptes étaient « 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 essayaient de tromper les utilisateurs en *générant* ou *approuvant* de nouvelles passkeys sur des appareils contrôlés par les attaquants, ou en les coercant à réinitialiser celles existantes. C’est une variante de la fatigue MFA « approuvez cette connexion », mais avec des enjeux plus élevés car une passkey compromise signifie un contrôle total du compte.
Les détournements de passkeys pilotés par des bots : comment cela fonctionne
Décomposons le nouveau manuel des bots pour la compromission des passkeys. Il ne s’agit pas de bruteforcing. Il s’agit d’une ingénierie sociale sophistiquée à grande échelle, amplifiée par l’automatisation.
- Reconnaissance et Spear-Phishing léger : Les bots récoltent des données publiques, des réseaux sociaux et même des dumps du dark web pour récupérer des adresses email et des numéros de téléphone. Ils croisent ensuite ces données avec les plateformes cibles. L’objectif n’est pas d’obtenir un mot de passe, mais d’identifier des utilisateurs actifs.
- L’appât du « Nouvel Appareil » : Un bot, mimant souvent un navigateur légitime ou une application mobile, tente d’initier une connexion ou un enregistrement de passkey pour un utilisateur connu sur la plateforme cible. Étant donné que 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 d’« 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 email générique « 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 : « Nouveau tentative d’enregistrement de 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 email méticuleusement rédigé, apparemment de l’équipe de sécurité de votre banque, avec un sujet comme : « Urgent : Enregistrement non autorisé de passkey détecté – Action requise. »
- Le contenu de l’email est personnalisé, peut-être même en faisant référence à l’heure précise de la tentative d’enregistrement. Il vous dirige vers une page de phishing qui ressemble identiquement 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 prend encore en charge pour la récupération), ou, plus insidieusement, de « révoquer des passkeys non autorisées » ce qui vous pousse en réalité à *enregistrer une nouvelle passkey* sur l’appareil de l’attaquant, déguisé en mesure de sécurité.
Le clé ici est le *moment* et le *contexte*. Les bots coordonnent ces actions à grande échelle, visant des milliers d’utilisateurs simultanément. L’utilisateur, voyant une notification légitime de l’application et un email très convaincant et opportun, est beaucoup plus susceptible de tomber dans le piège qu’avec un phishing générique.
Stratégies de défense pratiques contre l’abus de passkeys piloté par des bots
Alors, que pouvons-nous faire ? Nous ne pouvons pas jeter les passkeys ; elles représentent toujours un grand pas en avant. Mais nous devons être plus malins dans la façon dont nous les déployons et les protégeons. Voici quelques points que j’ai conseillés à mes clients, avec des exemples pratiques.
1. Renforcez votre flux d’enregistrement de « Nouvelle Passkey »
C’est la vulnérabilité la plus critique. Si un attaquant peut tromper un utilisateur pour qu’il enregistre une nouvelle passkey sur son appareil, c’est fini. Vous avez besoin de plusieurs couches de vérification ici, au-delà de l’invite initiale de passkey.
- Facteur Second Obligatoire pour les Nouvelles Enregistrations : 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 à un email *pré-enregistré*, pas celui fourni pendant la tentative d’enregistrement) pour *toute* nouvelle enregistrement ou remplacement de passkey est crucial.
- Attestation de l’Appareil (là où c’est possible) : Bien que pas infaillible, l’incorporation de vérifications d’attestation de l’appareil lors de l’enregistrement de passkeys peut aider à filtrer les machines virtuelles ou les émulateurs évidents que les bots pourraient utiliser. Il ne s’agit pas de bloquer les utilisateurs légitimes, mais d’ajouter du frottement pour les environnements d’attaquants connus.
- Limitation de Taux et Détection d’Anomalies : C’est une défense classique contre les bots, mais elle s’applique encore plus ici. Limiter agressivement le taux d’essais d’enregistrement de passkeys provenant d’adresses IP uniques ou de plages d’adresses IP, couplé à une détection d’anomalies comportementales (par exemple, un utilisateur tentant soudainement d’enregistrer 5 nouvelles passkeys en une heure depuis des emplacements géographiques différents), 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 une MFA supplémentaire
initiateMFAChallenge(userId, "new_passkey_registration");
return; // Attendre la fin de la MFA
}
// 2. Effectuer la validation d'attestation FIDO2
if (!validateWebAuthnAttestation(webauthnCredential)) {
logSecurityAlert(userId, "Attestation WebAuthn invalide lors de l'enregistrement de nouvelle passkey");
return;
}
// 3. Optionnel : Vérification de l'empreinte de l'appareil / attestation (côté serveur)
if (isSuspiciousDeviceFingerprint(request.headers['User-Agent'], request.ip)) {
logSecurityAlert(userId, "Empreinte d'appareil suspecte pour l'enregistrement de nouvelle passkey");
initiateMFAChallenge(userId, "suspicious_device_new_passkey");
return;
}
// 4. Vérification des limites 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 nouvelle passkey");
return;
}
// 5. Stocker la nouvelle passekey
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 principale. Si un attaquant peut initier un flux de récupération et ensuite manipuler l’utilisateur pour qu’il l’approuve, il a un accès secondaire.
- Retarder la récupération de compte : Mettez en place une période d’attente obligatoire (par exemple, 24 à 48 heures) pour les actions critiques de récupération de compte, en particulier celles qui impliquent le remplacement de toutes les passkeys existantes. Pendant ce temps, notifiez l’utilisateur de manière proactive via tous les canaux de communication connus. Cela donne à l’utilisateur légitime une chance d’intervenir.
- Vérification KYC par Vidéo ou par 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 de nécessiter 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 fort moyen de dissuasion contre l’ingénierie sociale automatisée.
- Passkeys de « Casse-Vitre » : Pour les comptes administrateurs internes ou les systèmes hautement sensibles, envisagez d’avoir une passkey physique de « casse-vitre » stockée dans un endroit sûr et audité, nécessitant plusieurs approbations pour être utilisée. Ce n’est pas pour les comptes consommateurs, mais pour des cibles de grande valeur, c’est indispensable.
3. Éducation des utilisateurs qui fonctionne réellement
Nous faisons de « l’éducation des utilisateurs » depuis des décennies, et honnêtement, la plupart de cela échoue. Pour les passkeys, nous avons besoin de conseils ciblés, opportuns et spécifiques.
- “À Quoi S’attendre” Guides: Expliquez clairement aux utilisateurs à quoi ressemblent les notifications de passkey légitimes et les processus de récupération. Montrez des captures d’écran.
- “Ce qu’il NE Faut PAS Faire” Alertes: 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 prétendant “révoquer” des passkeys, surtout s’ils n’ont pas eux-mêmes tenté une action de sécurité.
- Vérifications de Sécurité dans l’App: 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 examiner et révoquer les passkeys.
- Changez vos autres méthodes de récupération (par exemple, mot de passe 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 extrêmement efficace.
Conseils Actionnables pour les Experts en Sécurité des Bots
Le domaine des attaques par bots est toujours en évolution. Les passkeys sont excellentes, mais ce 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 de contrôle pour vous :
- Auditez vos Flux de Passkey : Passez en revue chaque flux lié aux passkeys �� enregistrement, connexion, récupération, révocation – avec l’esprit d’un attaquant par bot. Où un bot peut-il interférer avec l’ingénierie sociale ?
- La Vérification en Couches 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 du compte. Ajoutez une MFA hors bande.
- Éduquez, ne Vous Contentez Pas d’Informer : Concevez une éducation utilisateur qui soit proactive, très spécifique aux menaces de passkeys, 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 passkeys, les demandes de récupération et les tickets de support utilisateur associés. Les bots opèrent à grande échelle, et ces modèles vont émerger.
- Ne N’oubliez Pas les Bases : Tout en vous concentrant sur les passkeys, ne négligez pas vos défenses fondamentales contre les bots pour d’autres parties de votre application : limitation stricte des taux, réputation IP, analyse comportementale, et CAPTCHAs lorsque cela est approprié. Les bots peuvent évoluer, mais ils laissent encore des empreintes.
L’avenir de l’authentification est prometteur, mais seulement si nous anticipons comment les acteurs malveillants vont essayer de le contourner. 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 AI
- Mon Avis : OmniMind AI est un Cauchemar pour la Sécurité
- Actualités sur la Sécurité AI Aujourd’hui : Mises à Jour Urgentes & Perspectives d’Experts
🕒 Published: