L'OTP par e-mail est le parcours de secours le plus répandu, et le plus mal évalué. Il n'exige aucun matériel, fonctionne partout, et coûte presque rien. En contrepartie, il installe une dépendance structurelle : la boîte mail devient le facteur racine de tous les comptes qui l'utilisent en secours. Quiconque en prend le contrôle reconstitue le reste.
La chaîne de dépendance, déroulée
Le raisonnement à tenir ne porte pas sur le code lui-même, mais sur ce qui protège la messagerie.
| Maillon | Question à poser | Conséquence si le maillon cède |
|---|---|---|
| Le compte applicatif | quel est son facteur principal ? | contourné par le parcours de secours |
| Le parcours de secours | code envoyé à quelle adresse ? | l'attaque se déplace vers la messagerie |
| La messagerie | comment est-elle authentifiée ? | si mot de passe seul, toute la chaîne tombe |
| Le secours de la messagerie | code SMS ? question secrète ? | définit le vrai plancher, souvent très bas |
| Le fournisseur de messagerie | qui peut réinitialiser ce compte ? | son support devient un acteur de votre sécurité |
Une organisation qui déploie des passkeys sur son SI tout en gardant l'OTP e-mail comme secours a, en réalité, un niveau de sécurité défini par la ligne la plus basse de ce tableau. C'est une information à faire remonter telle quelle dans une analyse de risque.
Trois attaques qui n'ont pas besoin de casser le code
Le relais en temps réel. Un code e-mail est une valeur que l'utilisateur recopie. Une page contrefaite peut lui demander de la saisir et la retransmettre au service légitime dans la seconde. Contrairement à une signature FIDO2, rien ne lie le code au domaine sur lequel il est saisi. La durée de validité courte ne change rien : l'attaque est synchrone.
Le spear phishing de la messagerie. L'attaquant ne s'intéresse pas au compte cible mais à la boîte mail. Un message crédible, une page de connexion imitée, et la totalité des comptes recourant à ce secours devient accessible — souvent sans qu'aucune alerte ne soit levée sur les applications concernées.
La règle discrète. Après compromission d'une messagerie, la manœuvre classique consiste à créer une règle qui déplace ou supprime les messages contenant certains mots — « code », « vérification », « sécurité ». Les demandes de récupération deviennent alors invisibles pour le propriétaire légitime, qui ne détecte rien pendant des semaines.
Ce qu'on peut durcir, et ce qui reste ouvert
Il existe de vraies améliorations. Il faut simplement savoir ce qu'elles corrigent.
| Durcissement | Ce qu'il corrige | Ce qu'il ne corrige pas |
|---|---|---|
| Code court, validité de quelques minutes | fenêtre de rejeu différé | relais en temps réel |
| Limitation stricte des tentatives | recherche exhaustive du code | interception du message |
| Affichage du contexte dans le message | validation distraite | manipulation d'un utilisateur pressé |
| Code à saisir sur l'écran d'origine uniquement | saisie sur un autre parcours | attaque qui pilote l'écran d'origine |
| Notification sur un second canal | attaque silencieuse | compromission des deux canaux |
| Délai d'attente avant effet | rapidité de l'attaque | attaquant patient |
| Blocage des opérations sensibles après récupération | valeur immédiate de l'attaque | reprise d'accès elle-même |
La lecture d'ensemble est claire : on peut réduire la probabilité, on ne supprime pas la propriété gênante. Un code envoyé par e-mail reste une valeur transmissible, donc relayable.
Quand l'OTP e-mail reste acceptable
Le rejeter partout serait dogmatique. Il conserve une place légitime :
- sur des comptes à faible enjeu, où l'impact d'une reprise frauduleuse est limité ;
- comme signal complémentaire, jamais comme condition unique ;
- pour des parcours de notification — informer d'une action en cours et permettre de s'y opposer, ce qui est un usage défensif et non une preuve d'identité ;
- en secours de dernier recours assorti d'un délai d'attente et d'un gel des opérations sensibles.
En revanche, il n'a pas sa place comme secours d'un compte d'administration, d'un compte donnant accès à des paiements, ni de tout compte dont la compromission ouvre un accès à des données sensibles. Sur ces périmètres, le principe reste le même que pour n'importe quel facteur de secours : il ne doit pas être plus faible que le facteur principal.
Vers quoi le remplacer
Trois trajectoires, selon la maturité et le budget :
- Second justificatif inscrit d'avance. L'option la moins coûteuse : elle rend le parcours de secours rare au lieu de le rendre solide. La plupart des demandes de récupération disparaissent.
- Identité attestée par un tiers qualifié. Le portefeuille européen prévu par eIDAS 2 va rendre cette voie progressivement accessible pour les services grand public.
- Preuve non transmissible. Un challenge cognitif résolu par une méthode personnelle acquise à l'enrôlement ne circule pas dans un message, donc ne peut être ni intercepté, ni recopié sur une page contrefaite, ni obtenu par persuasion.
FAQ
Un lien de récupération vaut-il mieux qu'un code à recopier ?
Le lien évite la recopie manuelle, ce qui supprime certaines saisies sur des pages contrefaites. Mais il reste un jeton porteur transmissible : transféré, prévisualisé par un outil de sécurité ou capté dans une boîte compromise, il produit le même effet.
Faut-il exiger une authentification forte sur la messagerie interne ?
C'est la mesure la plus rentable si vous conservez l'OTP e-mail. Tant que la messagerie est le facteur racine, elle doit être protégée au niveau du compte le plus sensible qui dépend d'elle.
Comment détecter qu'un parcours de récupération est abusé ?
En surveillant les motifs plutôt que les événements isolés : demandes répétées, demandes suivant de près un échec de connexion, contexte inhabituel, création de règles de messagerie. Ces signaux alimentent utilement un score de risque contextuel.
Le code e-mail satisfait-il une exigence d'authentification forte ?
Il relève de la possession, au même titre que le SMS, mais avec une dépendance à un compte plutôt qu'à un objet. Utilisé seul, il ne constitue pas une authentification à deux facteurs de catégories distinctes au sens de la DSP2.
Aller plus loin : pilier : authentification cognitive · récupération de compte avec passkey · magic link : sécuriser la connexion · OTP e-mail face au spear phishing