Le système demande un deuxième facteur d'authentification

La situation. La connexion fonctionne, et ensuite, le système demande un code de six chiffres. L’origine de ce code détermine laquelle des trois options vous seront proposées.

Le code est généré à partir d’une graine que vous possédez

TOTP standard — le type de code généré par une application d’authentification. Si vous avez enregistré la clé de base32 dans le répertoire chiffré sous totp_cle, Dinoer génère le code actuel lui-même :

{"type": "remplir", "selecteur": "input[name=\"otp\"]",
 "valeur": "depuis_secrets_totp"}

Aucun humain, aucun presse-papiers, rien n’est chronométré. La clé reste dans le répertoire chiffré et le code est calculé à l’intérieur du processus du navigateur, comme n’importe quelle autre information d’identification.

C’est l’itinéraire à privilégier chaque fois qu’il est disponible.

Le code arrive par SMS ou par e-mail

Vous ne pouvez pas le générer — il vous est envoyé. attendre_mfa_ntfy attend que le code soit poussé via un canal de notification, remplit le champ et soumet :

[
  {"type": "cliquer", "selecteur": "#send-code"},
  {"type": "attendre_mfa_ntfy", "selecteur": "input[name=\"otp\"]", "timeout": 120}
]

selecteur est l’entrée du code OTP ; timeout est le délai en secondes, par défaut 120. Cette route nécessite que l’intégration de notification soit configurée au préalable — elle ne lit pas le répertoire, car le code n’existe qu’une fois qu’il a été envoyé.

Aucune des deux ne s’applique — un humain l’a tapé

[
  {"type": "remplir", "selecteur": "input[name=\"otp\"]", "valeur": "123456"},
  {"type": "cliquer", "selecteur": "#confirm"}
]

Solution de secours honnête : quelqu’un lit le code et modifie le scénario avant de l’exécuter. Cela fonctionne, mais ce n’est pas évolutif. Il est utile de savoir qu’elle existe, mais il ne faut pas la considérer comme une base pour un développement ultérieur.

Le cas que rien de ce qui précède ne couvre

Inscription. Le tout premier code, au moment où le secret est créé.

Lorsque vous activez l’authentification à deux facteurs (2FA), le serveur génère la clé de sécurité et vous la présente une seule fois. À cet instant précis, elle n’existe nulle part ailleurs : ni dans votre répertoire chiffré, ni dans une notification. depuis_secrets_totp n’a rien à lire, et attendre_mfa_ntfy n’a rien à attendre.

Il n’existe aucun outil pour cela. Ce qui fonctionne, c’est de réaliser toute l’inscription dans un seul scénario : lire la valeur initiale depuis la page, calculer le premier code, le soumettre, et seulement ensuite enregistrer la valeur initiale, afin que rien ne doive être conservé entre deux appels. C’est possible, cela a déjà été fait, et c’est vraiment maladroit.

Indiqué ici plutôt que découvert au milieu de l’inscription, avec une page qui ne vous permettra pas de revenir en arrière.

Un piège qu’il est bon de connaître

Calculer un TOTP vous-même à l’intérieur de evaluer nécessite l’API crypto du navigateur, qui n’existe que dans un contexte sécurisé : HTTPS ou localhost. Sur une cible HTTP simple, elle est tout simplement absente, et vous obtenez Cannot read properties of undefined au lieu d’un message utile.

Si vous utilisez HTTP par choix — une machine de test, un appareil local –, cette option est désactivée. Utilisez le répertoire chiffré.

En bref

• Insérer la clé dans le répertoire chiffré → depuis_secrets_totp. Privilégier cette méthode.
• Le code est poussé vers vous → attendre_mfa_ntfy avec le sélecteur propre du champ.
• Ni l’un ni l’autre → un humain le saisit, et c’est acceptable pour une utilisation ponctuelle.
• L’inscription est un problème distinct : un seul scénario, sans persistance entre les appels.
• Pas de cryptographie côté navigateur sur une cible HTTP non sécurisée.