Bonjour à tous, Pat Reeves ici, de retour sur botsec.net. Nous sommes en mars 2026, et si vous êtes comme moi, vous devez encore être un peu sous le choc de l’audace de certaines des activités de botnets 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, quelque chose d’autre a silencieusement bouillonné sous la 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 a dit que les passkeys sont l’avenir, n’est-ce pas ? Résistantes au phishing, cryptographiquement sécurisées, liées à un appareil. Et pour de bonnes raisons, elles traitent un tas de points de douleur anciens. 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’une faille dans la cryptographie elle-même, mais dans la manière dont elle est mise en œuvre et, surtout, dans la façon dont les bots apprennent à manipuler l’élément humain qui l’entoure ?
Le Paradoxe de la Passkey : Une Nouvelle Frontière pour les Bots
Pensez-y. La promesse des passkeys est qu’elles éliminent les secrets partagés (les 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 par dictionnaire simples. Mais les bots, que leurs petits cœurs numériques persistants, ne se laissent pas si facilement décourager. Ils s’adaptent. Et ce que j’ai remarqué, en particulier dans les tentatives de takeover de comptes (ATO) sur des plateformes qui ont pleinement adopté les passkeys, 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 plongé à fond dans les passkeys l’été dernier, m’a vraiment ouvert les yeux. Ils ont constaté une massive 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 augmentation des tentatives de « connexion échouée » qui étaient… différentes. Ce n’étaient pas des échecs de mot de passe ; ce étaient des tentatives d’initier l’enregistrement de passkey ou la récupération depuis des appareils non reconnus, souvent suivies d’une série de demandes de support de la part d’utilisateurs légitimes prétendant que leurs comptes étaient « piratés » alors qu’ils avaient des passkeys activées.
Ce que nous avons découvert était une attaque en plusieurs étapes. Les bots n’essayaient pas de deviner des passkeys ; ils essayaient de tromper les utilisateurs pour qu’ils *génèrent* ou *approuvent* de nouvelles passkeys sur des appareils contrôlés par les attaquants, ou les contraindre à réinitialiser celles existantes. C’est un twist sur la fatigue liée au MFA « approuver cette connexion », mais avec des enjeux plus élevés car une passkey compromise signifie un contrôle total du compte.
Le Détournement des Passkeys par les Bots : Comment Ça Fonctionne
Décomposons le nouveau manuel des bots pour la compromission de passkeys. Il ne s’agit pas de forcer brutalement l’accès. Il s’agit d’ingénierie sociale sophistiquée à grande échelle, amplifiée par l’automatisation.
- Reconnaissance et Spear-Phishing Léger : Les bots extraient des données publiques, des réseaux sociaux, et même des 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 ciblées. L’objectif n’est pas d’obtenir un mot de passe, mais d’identifier des utilisateurs actifs.
- Le Leurre du « Nouvel Appareil » : Un bot, souvent imitant 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. Comme l’utilisateur n’a pas de passkey enregistrée sur ce dispositif spécifique (l’environnement simulé du bot), la plateforme demande souvent un mode de vérification alternatif ou d’« ajouter une nouvelle passkey. »
- Ingénierie Sociale Automatisée (ASE) : C’est ici que se produit la magie (ou plutôt, la menace). Le bot, ayant déclenché une notification système légitime (e-mail, SMS, push notification 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 : « Nouvelle 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. »
- En simultané, vous recevez un e-mail méticuleusement élaboré, apparemment de l’équipe de sécurité de votre banque, avec un sujet comme : « Urgent : Enregistrement de Passkey Non Autorisé Détecté – Action Requise. »
- Le contenu de l’e-mail est adapté, peut-être en référant même à 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 prend encore en charge pour la récupération), ou, plus insidieusement, de « révoquer des passkeys non autorisées » qui vous incite en fait à *enregistrer une nouvelle passkey* sur le dispositif de l’attaquant, déguisé en mesure de sécurité.
L’élément clé ici est le *moment* et le *contexte*. Les bots coordonnent ces actions à grande échelle, touchant 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 tomber dans le panneau que face à une arnaque de phishing générique.
Stratégies de Défense Pratiques Contre l’Abus de Passkeys par des Bots
Alors, que pouvons-nous faire ? Nous ne pouvons pas abandonner les passkeys ; elles représentent encore un énorme progrès. Mais nous devons être plus intelligents dans la manière de les déployer et de les protéger. Voici quelques conseils que j’ai transmis à 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 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 Nouveaux Enregistrements : Même si un utilisateur est déjà connecté, exiger une vérification supplémentaire, en dehors du réseau (par exemple, un code unique envoyé à un numéro de téléphone ou un e-mail *préalablement enregistré*, et non fourni lors de la tentative d’enregistrement) pour *tout* nouvel enregistrement ou remplacement de passkey est crucial.
- Attestation de Dispositif (là où c’est possible) : Bien que cela ne soit pas infaillible, l’incorporation de vérifications d’attestation de dispositif lors de l’enregistrement de passkey peut aider à filtrer les machines virtuelles ou émulatrices évidentes que les bots pourraient utiliser. Il ne s’agit pas de bloquer les utilisateurs légitimes, mais d’ajouter des obstacles pour les environnements attaquants connus.
- Limitation de Taux et Détection d’Anomalies : C’est une défense classique contre les bots, mais cela s’applique encore plus ici. Une limitation de taux agressive sur les tentatives d’enregistrement de passkey provenant d’adresses IP uniques ou de plages d’adresses IP, combinée à une détection d’anomalies comportementales (par exemple, un utilisateur tentant soudainement d’enregistrer 5 nouvelles passkeys en une heure depuis différents lieux géographiques), peut signaler une activité suspecte.
// Exemple : Pseudocode pour un bon flux d'enregistrement de nouvelle passkey
function registerNewPasskey(userId, webauthnCredential) {
// 1. Vérifiez la session existante et la force de l'authentification
if (!isAuthenticatedStrongly(userId)) {
// Forcer une ré-authentification ou MFA supplémentaire
initiateMFAChallenge(userId, "new_passkey_registration");
return; // Attendre la complétion 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 du dispositif/attestation (côté serveur)
if (isSuspiciousDeviceFingerprint(request.headers['User-Agent'], request.ip)) {
logSecurityAlert(userId, "Empreinte de dispositif suspecte pour l'enregistrement de nouvelle passkey");
initiateMFAChallenge(userId, "suspicious_device_new_passkey");
return;
}
// 4. Vérification de limite 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. Enregistrer la nouvelle crédentielle de 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 importante. Si un attaquant peut initier un flux de récupération et ensuite manipuler l’utilisateur pour l’approuver, il a une porte dérobée.
- Retardez la Récupération de Compte : Mettez en œuvre une période d’attente obligatoire (par exemple, 24-48 heures) pour les actions critiques de récupération de compte, surtout celles qui impliquent le remplacement de toutes les passkeys existantes. Pendant ce temps, informez agressivement l’utilisateur par tous les canaux de communication connus. Cela donne à l’utilisateur légitime une chance d’intervenir.
- Vérification KYC par Vidéo ou Vérification par Agent en Direct pour Réinitialisation Complète : Pour les situations où un utilisateur a perdu toutes ses passkeys et d’autres méthodes de récupération, envisagez d’exiger une vérification en direct par vidéo avec un agent de support. C’est une solution de haute friction, mais pour les comptes critiques, c’est un fort moyen de dissuasion contre l’ingénierie sociale automatisée.
- Passkeys « Casser en Verre » : Pour les comptes administratifs internes ou les systèmes hautement sensibles, envisagez d’avoir une passkey physique « casser en 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. Éducation des Utilisateurs Efficace
Nous faisons de l’« éducation des utilisateurs » depuis des décennies, et honnêtement, la plupart du temps, cela ne fonctionne pas. Pour les passkeys, nous avons besoin de conseils ciblés, opportuns et spécifiques.
- “Guides sur ce à quoi s’attendre”: Expliquez clairement aux utilisateurs à quoi ressemblent les notifications de clé d’accès 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 clés d’accès qu’ils n’ont pas initiés, ni de cliquer sur des liens dans des e-mails qui prétendent “révoquer” des clés d’accès, surtout s’ils n’ont pas eux-mêmes tenté une action de sécurité.
- Contrôles de sécurité intégrés: Fournissez une section facile à trouver dans votre application ou votre site web où les utilisateurs peuvent voir toutes les clés d’accès enregistrées, leur origine (si possible) et les révoquer. Rendez cela simple et intuitif.
// Exemple : Alerte intégrée 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 clé d'accès pour votre compte à partir d'un appareil non reconnu (${activityDetails.ipAddress} - ${activityDetails.location}) à ${activityDetails.timestamp}.
Si c'était vous, vous pouvez ignorer cela. Si ce n'était PAS vous, veuillez agir immédiatement :
- Allez dans vos Paramètres de sécurité pour examiner et révoquer les clés d'accès.
- 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 incroyablement efficace.
Actions recommandées pour les professionnels de la sécurité des bots
Le domaine des attaques par bots est en constante évolution. Les clés d’accès sont excellentes, mais elles ne sont pas une solution miracle, et les attaquants trouvent déjà de nouveaux moyens d’exploiter l’élément humain qui les entoure. Voici ma liste d’actions pour vous :
- Auditez vos flux de clés d’accès : Examinez chaque flux lié aux clés d’accès – enregistrement, connexion, récupération, révocation – avec l’esprit d’un attaquant par bot. Où un bot peut-il intercepter une ingénierie sociale ?
- La vérification en plusieurs couches est essentielle : Ne comptez jamais sur un seul facteur pour des actions à fort impact comme l’enregistrement d’une nouvelle clé d’accès ou la récupération complète de compte. Ajoutez une authentification multifactorielle en dehors de la bande.
- Éduquez, ne vous contentez pas d’informer : Concevez une éducation des utilisateurs qui soit proactive, très spécifique aux menaces liées aux clés d’accès, 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 des modèles inhabituels dans les tentatives d’enregistrement de clés d’accès, les demandes de récupération et les tickets de support utilisateur liés à ceux-ci. Les bots opèrent à grande échelle, et ces modèles émergeront.
- Ne négligez pas les bases : Tout en vous concentrant sur les clés d’accès, ne négligez pas vos défenses fondamentales contre les bots pour d’autres parties de votre application : limitation de taux solide, réputation IP, analyse comportementale et CAPTCHAs lorsque c’est approprié. Les bots évoluent, mais ils laissent toujours des traces.
Le futur de l’authentification est prometteur, mais seulement si nous anticipons comment les acteurs malveillants essaieront de le subvertir. Restez vigilant, restez en sécurité, 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é des IA aujourd’hui : Mises à jour urgentes & Perspectives d’experts
🕒 Published: