La plupart des comparaisons entre ces deux options se résument à opposer le confort d'usage à la sécurité, avec une affirmation vague selon laquelle les clés seraient "plus sûres". Il existe une réponse plus précise, et elle est écrite noir sur blanc dans une norme.
La phrase qui tranche la question du phishing
Le NIST SP 800-63B, section 5.2.5, est direct sur ce point. Les authentificateurs qui impliquent la saisie manuelle d'une sortie d'authentificateur, tels que les authentificateurs hors bande et OTP, ne doivent pas être considérés comme résistants à l'usurpation du vérifieur, parce que la saisie manuelle ne lie pas la sortie de l'authentificateur à la session spécifique en cours d'authentification.
La même section explique l'attaque au lieu de la laisser implicite : dans une attaque de type machine-in-the-middle, un faux vérifieur pourrait rejouer la sortie de l'authentificateur OTP vers le vrai vérifieur et s'authentifier avec succès.
C'est tout le mécanisme. Votre code à six chiffres est correct. Il est simplement correct partout, y compris sur une page qui ressemble seulement à celle de votre banque.
Pourquoi la liaison est la vraie différence
La norme définit la résistance à l'usurpation du vérifieur comme le fait d'établir un canal protégé authentifié avec le vérifieur, puis de lier fortement et irréversiblement un identifiant de canal à la sortie de l'authentificateur, par exemple en signant les deux valeurs ensemble avec une clé privée.
Confrontez cela à ce que chaque méthode fait physiquement.
Une application d'authentification génère un nombre à partir d'un secret partagé et d'une horloge. Elle n'apprend jamais sur quel site vous vous trouvez. C'est vous qui faites office de couche de transport, et vous pouvez être détourné.
Une clé de sécurité signe un défi en même temps que l'identité de la session. La FIDO Alliance décrit les passkeys comme utilisant les techniques standard de cryptographie à clé publique pour fournir une authentification résistante au phishing. Il n'y a aucun nombre à lire à voix haute, et donc rien qu'un attaquant puisse relayer.
À quoi ressemble l'attaque de votre côté
L'abstraction masque à quel point la chose est ordinaire, il vaut donc la peine de la dérouler.
Vous recevez un message au sujet de votre compte. Le lien mène à une page qui s'affiche correctement, parce que le serveur de l'attaquant récupère la vraie page et la fait transiter. Vous saisissez votre mot de passe. Le serveur de l'attaquant le soumet immédiatement au vrai site. Le vrai site demande un second facteur, donc la fausse page vous le demande à son tour.
Vous ouvrez votre application et lisez six chiffres. Le serveur de l'attaquant les saisit sur le vrai site dans la même fenêtre de trente secondes. Le vrai site voit un mot de passe valide et un code valide, et délivre une session. L'attaquant détient désormais cette session.
Remarquez ce qui ne s'est jamais produit. Rien n'a été cassé, aucun secret n'a été volé sur votre téléphone, et votre application s'est comportée exactement comme prévu. Le code était authentique. Il a simplement été utilisé à un endroit que vous n'aviez pas prévu, et ni vous ni l'application n'aviez le moyen de le remarquer, parce que le code ne transporte aucune information sur sa destination.
Répétez la même séquence avec une clé de sécurité et cela s'arrête au second facteur. La clé ne produit aucun nombre que vous puissiez relayer. Elle signe une réponse liée au site qui fait réellement la demande, si bien que le serveur de l'attaquant reçoit quelque chose qui ne fonctionne que sur son propre domaine, ce qui n'a aucune valeur pour lui.
Là où une clé n'aide pas non plus
Être précis sur les limites compte autant que sur les points forts, car une clé n'est pas un bouclier universel.
Elle ne protège pas une session déjà délivrée. Si un logiciel malveillant présent sur votre machine vole un cookie de session après que vous vous êtes connecté légitimement, l'étape de connexion est derrière vous et la clé n'intervient plus.
Elle ne protège pas le chemin de récupération. Un compte qui peut être réinitialisé par e-mail ou par un agent du support ne vaut que ce que vaut ce chemin. C'est précisément pour cela que le compte e-mail est le premier à protéger, et que les questions de récupération de compte restent une cible facile.
Elle ne protège pas ce que voit un appareil compromis. Si le poste est entièrement compromis, l'attaquant se trouve dans la session authentifiée avec vous.
Elle ne couvre pas les services qui ne la prennent pas en charge. C'est la limite pratique pour la plupart des gens, et la raison pour laquelle une clé s'ajoute à une application d'authentification plutôt qu'elle ne la remplace.
La nuance que la plupart des comparaisons laissent tomber
C'est ici que beaucoup d'écrits sur la sécurité vont trop loin, il vaut donc la peine de le dire clairement.
La résistance à l'usurpation du vérifieur n'est exigée qu'à AAL3 dans le cadre du NIST. À AAL1 et AAL2, elle n'est pas imposée. Une application TOTP est donc un second facteur conforme pour une très grande partie des comptes ordinaires, et elle reste une amélioration majeure par rapport aux codes SMS ou à l'absence totale de second facteur.
La formulation honnête n'est donc pas "les applications sont cassées". C'est que les applications ont une faiblesse spécifique, le phishing en temps réel, et que cette faiblesse est structurelle plutôt qu'un défaut d'une application particulière. Aucune mise à jour de votre application d'authentification ne la corrigera, parce que l'écart se situe dans l'étape de saisie manuelle elle-même.
Choisir sans se compliquer la vie
La décision découle de ce qu'obtient un attaquant si un compte donné tombe.
Utilisez une clé de sécurité là où une compromission est irrattrapable. Votre compte e-mail d'abord, parce qu'il est le chemin de réinitialisation du mot de passe de tout le reste. Puis votre gestionnaire de mots de passe. Puis tout ce qui touche à la finance et qui prend en charge les clés.
Gardez l'application pour la couverture. La plupart des services ne prennent toujours pas en charge les clés de sécurité. Une application d'authentification sur ces comptes vaut infiniment mieux que rien, et elle ne coûte rien.
N'utilisez pas une clé unique sans solution de repli. Enregistrez-en une deuxième, ou gardez des codes de récupération imprimés et stockés hors ligne. Perdre votre unique clé est un blocage que vous vous infligez vous-même, et c'est une défaillance plus fréquente que de se faire hameçonner.
Si vous cherchez à décider quelle clé acheter, nous comparons les modèles actuels dans notre comparatif de clés de sécurité hardware.
Côte à côte
| Application d'authentification | Clé de sécurité | |
|---|---|---|
| Résiste au phishing en temps réel | Non, selon le NIST 5.2.5 | Oui, réponse liée à la session |
| Ce que vous manipulez | Un code que vous lisez et retapez | Rien, l'appareil signe |
| Exigé à AAL3 | Pas suffisant seul | Répond à l'exigence |
| Fonctionne sur la plupart des services | Oui | Uniquement là où c'est pris en charge |
| Coût | Gratuit | Environ 25 à 60 unités monétaires par clé |
| Principal mode de défaillance | Vous êtes hameçonné et saisissez un code valide | Vous perdez la clé sans sauvegarde enregistrée |
| Récupération en cas de perte | Réinstaller depuis une sauvegarde des secrets | Enregistrer une deuxième clé, ou des codes de récupération |
Les deux dernières lignes sont celles que l'on sous-estime le plus. Le risque dominant dans la vraie vie avec une application est de se faire piéger et de l'utiliser correctement au mauvais moment. Le risque dominant dans la vraie vie avec une clé est de la perdre après n'en avoir enregistré qu'une seule.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Rangez les codes de récupération là où vous les aurez encoreLes codes de récupération sont ce qui vous permet de revenir quand une clé est perdue. Un gestionnaire de mots de passe les garde en dehors de l'appareil que vous essayez justement de récupérer, et c'est tout l'intérêt.→La version courte
La question du phishing n'est pas une affaire d'opinion. Le NIST affirme que les authentificateurs OTP ne peuvent pas être considérés comme résistants à l'usurpation du vérifieur, et explique pourquoi : la saisie manuelle ne lie pas le code à la session. Une clé de sécurité signe la session elle-même, il n'y a donc rien à relayer.
Mais l'exigence s'applique à AAL3, pas partout. Une application d'authentification reste un second facteur légitime pour la plupart des comptes. Placez les clés là où une perte serait irrattrapable, gardez l'application pour la longue traîne, et assurez-vous d'avoir un moyen de revenir.
Les définitions et exigences décrites ici sont tirées de la NIST Special Publication 800-63B, et la caractérisation des passkeys du matériel publié par la FIDO Alliance elle-même, tous deux vérifiés au moment de la rédaction. Les normes sont révisées ; vérifiez par rapport au texte en vigueur avant de vous appuyer sur une clause précise. Les liens commerciaux portent l'attribut rel="sponsored nofollow" ; une commission d'affiliation peut s'appliquer sans coût supplémentaire pour vous.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Un gestionnaire avec 2FA et passkeys intégrés → NordPassStocke TOTP et passkeys · XChaCha20 · offre gratuite→Questions fréquentes
Une clé de sécurité est-elle vraiment plus résistante au phishing qu'une application d'authentification ?
Sur ce point précis, la norme est sans ambiguïté. Le NIST SP 800-63B indique que les authentificateurs impliquant la saisie manuelle d'une sortie, tels que les authentificateurs hors bande et OTP, ne doivent pas être considérés comme résistants à l'usurpation du vérifieur, parce que la saisie manuelle ne lie pas la sortie à la session spécifique en cours d'authentification. Un authentificateur cryptographique signe un identifiant de canal en même temps que sa réponse, ce que fait une clé de sécurité et ce qu'un code à six chiffres ne peut pas faire.
Pourquoi le fait de taper le code compte-t-il autant ?
Parce que le code n'a aucune idée de l'endroit où vous le tapez. Le NIST décrit l'attaque directement : un faux vérifieur peut rejouer la sortie de l'authentificateur OTP vers le vrai vérifieur et s'authentifier avec succès. Une fausse page de connexion collecte votre code et l'utilise dans sa fenêtre de validité. Le code est valide, le site ne l'est pas, et rien dans le processus ne détecte la différence.
Cela veut-il dire que les applications d'authentification ne sont pas sûres ?
Non, et il vaut la peine d'être précis. La résistance à l'usurpation du vérifieur n'est exigée qu'à AAL3 dans le cadre du NIST. À AAL1 et AAL2, elle n'est pas imposée, donc une application TOTP reste un second facteur conforme pour une grande partie des comptes ordinaires. C'est une très nette amélioration par rapport au SMS et par rapport à l'absence totale de second facteur. L'écart est spécifique : il concerne le phishing en temps réel, pas la solidité générale de la méthode.
Qu'est-ce qui rend une clé de sécurité résistante là où un code ne l'est pas ?
L'identifiant est cryptographique plutôt qu'un nombre recopié. La FIDO Alliance décrit les passkeys comme utilisant les techniques standard de cryptographie à clé publique pour fournir une authentification résistante au phishing. La réponse est produite par l'appareil et liée à la session, il n'y a donc rien à lire à voix haute et rien qu'un attaquant puisse relayer.
Faut-il utiliser les deux ?
C'est généralement la réponse pratique. Utilisez une clé de sécurité sur les comptes qu'il serait le plus grave de perdre, typiquement votre messagerie et votre gestionnaire de mots de passe, puisque l'e-mail est le chemin de réinitialisation de tout le reste. Gardez une application d'authentification pour les nombreux services qui ne prennent pas en charge les clés. Enregistrez une deuxième clé ou conservez des codes de récupération hors ligne, car une clé unique sans solution de repli constitue son propre risque.
