Une passkey authentifie une connexion. Elle ne dit rien de ce qui se passe après. Or le vol de session n'attaque pas l'authentification : il attend qu'elle réussisse, puis s'empare du jeton qu'elle produit. C'est l'angle mort structurel de FIDO2, et il est d'autant plus important qu'il devient, une fois le phishing d'identifiants neutralisé, le chemin d'attaque le plus rentable.
Le déplacement de l'attaque vers l'après-authentification
La logique est économique. Quand la collecte d'identifiants cesse de payer, l'effort se reporte sur ce qui reste accessible. Trois techniques dominent.
Le logiciel dérobeur d'informations installé sur le poste extrait les cookies de session directement depuis le navigateur, avec les identifiants enregistrés et les jetons applicatifs. L'utilisateur ne perçoit rien, et l'attaquant importe la session ailleurs. L'extension de navigateur malveillante ou compromise obtient les mêmes résultats avec une empreinte encore plus faible, en s'exécutant dans le contexte de la page. Enfin, le détournement d'autorisation applicative produit un jeton d'accès légitime, à durée de vie longue, accordé par la victime elle-même à une application contrôlée par l'attaquant.
Dans les trois cas, la passkey a fonctionné exactement comme prévu. Elle n'a simplement pas été sollicitée au moment qui comptait.
Pourquoi le renforcement de la connexion ne suffit pas
Le modèle dominant reste celui d'une authentification initiale suivie d'une longue période de confiance. Ce modèle suppose que la session soit incessible, ce qui est faux dès lors qu'un jeton existe sous forme transportable.
La publication NIST SP 800-207 sur l'architecture Zero Trust formule le principe qui s'applique ici : « ne jamais faire confiance, toujours vérifier ». La vérification ne doit pas être un événement d'entrée, mais une propriété continue. Dans les faits, la plupart des déploiements FIDO2 s'arrêtent au seuil : excellente porte, aucune serrure à l'intérieur.
| Mesure | Ce qu'elle apporte contre le vol de session | Limite |
|---|---|---|
| Passkey à la connexion | Aucun effet direct | L'attaque survient après |
| Sessions de courte durée | Réduit la fenêtre d'exploitation | Compromis avec l'expérience utilisateur |
| Liaison du jeton à l'appareil | Rend le jeton inutilisable ailleurs | Support inégal selon les composants |
| Réauthentification périodique | Interrompt une session volée | Prévisible, et souvent trop espacée |
| Détection contextuelle | Repère l'usage depuis un contexte différent | Détecte après coup |
| Validation par opération | Neutralise l'usage d'une session volée | Suppose un facteur non rejouable |
Détecter : ce qui trahit une session importée
Les signaux existent, à condition de comparer l'instant de l'authentification et l'instant de l'usage, ce que peu d'organisations font.
Quatre corrélations sont particulièrement discriminantes. Une session authentifiée depuis un poste d'entreprise et utilisée ensuite depuis une infrastructure d'hébergement. Une divergence d'agent utilisateur ou d'empreinte de navigateur en cours de session. Une géovélocité incompatible avec un déplacement physique. Enfin, l'enchaînement caractéristique d'une prise de contrôle : consultation des paramètres de sécurité, ajout d'un facteur, création d'une règle de redirection de messagerie, puis action à valeur financière.
Ces règles ont l'avantage d'être peu bruyantes et de ne pas dépendre du mécanisme d'authentification retenu.
Ramener le contrôle au niveau de l'action
La réponse de fond consiste à cesser de traiter la session comme une preuve. Deux mécanismes y concourent.
L'authentification transactionnelle exige une validation explicite au moment de l'opération sensible, portant sur ses paramètres réels : montant et bénéficiaire d'un virement, portée d'une élévation de privilèges, identité du compte créé. Une session volée devient alors insuffisante, puisque l'attaquant ne peut pas produire la validation.
Le principe de Moving Target Defense ajoute une propriété complémentaire : les paramètres varient en continu, ce qui rend inopérante toute réutilisation de ce qui a été capté. Un jeton observé à un instant donné ne conserve pas sa valeur.
Le facteur cognitif combine les deux : un challenge résolu au moment de l'action, dans un canal éphémère chiffré ouvert par un QR code dynamique à usage unique, sans secret réutilisable. La passkey protège l'entrée, la preuve d'intention protège l'opération. Le déploiement en overlay permet de n'appliquer cette seconde couche qu'aux gestes qui portent réellement un risque, sans dégrader le confort au quotidien.
FAQ
La liaison du jeton à l'appareil règle-t-elle le problème ?
Elle le réduit fortement en rendant un cookie volé inutilisable sur une autre machine, ce qui en fait une mesure très recommandable. Sa disponibilité dépend cependant des composants en présence, et elle ne protège pas contre un attaquant qui opère depuis le poste compromis lui-même.
Faut-il réduire drastiquement la durée des sessions ?
Sur les périmètres d'administration et les applications financières, oui. Sur les usages courants, une réduction agressive pousse les utilisateurs vers des contournements. Mieux vaut différencier selon la sensibilité, et prévoir une réauthentification déclenchée par le risque plutôt que par l'horloge.
Comment réagir à un vol de session avéré ?
Révoquer les jetons avant tout — un changement d'identifiants seul ne déloge pas l'attaquant. Vérifier ensuite les facteurs enrôlés, les autorisations applicatives accordées et les règles de messagerie, puis traiter le poste, qui est vraisemblablement compromis.
Les passkeys sont-elles moins utiles qu'annoncé ?
Non : elles suppriment un vecteur majeur et le font sans dépendre de la vigilance de l'utilisateur. Elles répondent simplement à une question précise, celle de la connexion. Le vol de session appelle une réponse distincte, qui se situe au niveau de l'opération.
Aller plus loin : le principe du facteur cognitif · vol de session et token theft · l'authentification transactionnelle · Moving Target Defense contre le vol de session