Comment ajouter une double authentification à votre application

Pour ajouter une double authentification (2FA) à votre application, laissez les utilisateurs associer une application d'authentification en scannant un QR code, demandez le code à six chiffres qu'elle affiche après le mot de passe, et ne créez une session complète côté serveur qu'une fois ce code validé. Donnez à chaque utilisateur des codes de récupération à usage unique lorsqu'il active la 2FA, limitez le nombre de codes qu'une personne peut deviner, et exigez le mot de passe plus un code valide avant de pouvoir désactiver la 2FA. Si vous utilisez un fournisseur d'authentification hébergé, activez plutôt son option multifacteur intégrée au lieu de la construire vous-même.

Ce guide présente les choix, le déroulement exact, des requêtes à donner à un créateur d'applications par IA, et les erreurs qui donnent l'impression que la 2FA est en place sans rien protéger. Si le concept est nouveau, commencez par qu'est-ce que la double authentification.

Avant de commencer : il vous faut une connexion fonctionnelle

La 2FA se superpose à une connexion existante. Il vous faut d'abord l'une de ces deux options :

• Votre propre connexion, avec des utilisateurs et des mots de passe hachés stockés dans la base de données de votre application.
• Un fournisseur d'authentification hébergé qui gère les utilisateurs à votre place.

Si vous n'avez encore ni l'un ni l'autre, commencez par comment ajouter une connexion à votre application. La suite de ce guide suppose qu'une étape de mot de passe fonctionne déjà.

Choisir votre second facteur

TOTP signifie time-based one-time password (mot de passe à usage unique basé sur le temps), le standard (RFC 6238) qu'utilisent les applications d'authentification. Votre serveur et le téléphone de l'utilisateur partagent un secret ; chacun génère le même code court à partir de ce secret et de l'heure actuelle, généralement renouvelé toutes les 30 secondes. Aucune connexion réseau ni fournisseur de SMS n'est nécessaire.

Les clés d'accès remplacent ou complètent les mots de passe grâce à une clé cryptographique stockée sur l'appareil de l'utilisateur. Elles sont plus solides, mais plus complexes à construire soi-même ; beaucoup d'applications commencent donc par le TOTP et ajoutent les clés d'accès plus tard, ou les obtiennent auprès d'un fournisseur d'authentification.

Le construire ou l'activer ?

Consultez la documentation actuelle de votre fournisseur pour savoir quels facteurs il prend en charge et selon quelles formules. Dans tous les cas, n'écrivez jamais vous-même les calculs de génération de code ; utilisez une bibliothèque largement employée.

Définissez d'abord la politique

Répondez à ces questions avant de rédiger vos requêtes, car elles modifient la conception :

1. Qui doit l'utiliser ? Facultatif pour tous, obligatoire pour les administrateurs et le personnel, ou obligatoire pour tous. L'exiger de toute personne disposant de droits d'administration est courant. Voir contrôle d'accès basé sur les rôles.
2. À quelle fréquence les utilisateurs ressaisissent-ils un code ? À chaque connexion, ou une fois par appareil pendant 30 jours (« se souvenir de cet appareil »).
3. Quelles actions exigent une nouvelle vérification ? Modifier l'adresse e-mail, les coordonnées de versement ou désactiver la 2FA sont de bons candidats. On parle d'authentification renforcée (step-up).
4. Quelle est la procédure en cas de téléphone perdu ? Des codes de récupération, plus une solution de repli manuelle que vous êtes prêt à appliquer.

Étape par étape : 2FA par TOTP sur votre propre connexion

1. Stocker les bons champs

Chaque utilisateur a besoin de : l'état d'activation de la 2FA, le secret TOTP (chiffré au repos, jamais en clair), la date d'activation, et une liste de codes de récupération stockés hachés, comme les mots de passe. Prévoyez aussi un emplacement pour compter les tentatives échouées.

2. Activation

1. L'utilisateur ouvre les paramètres et clique sur Activer la double authentification.
2. Le serveur génère un nouveau secret et le renvoie sous forme de QR code, ainsi que sa version texte pour ceux qui ne peuvent pas scanner.
3. L'utilisateur le scanne dans une application d'authentification et saisit le code actuel.
4. Le serveur vérifie le code. Ce n'est que s'il est correct qu'il enregistre le secret et marque la 2FA comme activée.
5. L'application affiche une seule fois 8 à 10 codes de récupération et demande à l'utilisateur de les conserver.

L'étape 4 est essentielle : activer la 2FA avant de confirmer un code verrouille toute personne dont le scan a échoué.

3. Connexion avec une seconde étape

1. L'utilisateur soumet son e-mail et son mot de passe. Le serveur les vérifie.
2. Si la 2FA est activée, le serveur ne crée pas de session complète. Il crée à la place un état « second facteur en attente », de courte durée.
3. L'application affiche l'écran de code. Le serveur vérifie le code, en tolérant une petite marge pour le décalage d'horloge.
4. C'est seulement à ce moment que le serveur délivre la vraie session.

Chaque route protégée et chaque point de terminaison d'API doit rejeter l'état en attente. Un écran 2FA qui se contente de masquer des pages dans le navigateur peut être contourné en appelant directement l'API.

4. Limites et alertes

Un code à six chiffres a un million de combinaisons, ce qui peut être deviné sans limite. Limitez les tentatives, bloquez la seconde étape pendant une durée après plusieurs échecs, et envoyez un e-mail à l'utilisateur lorsque cela arrive. Voir limitation de débit et envoyer des e-mails depuis votre application.

5. Récupération et désactivation

• Un code de récupération ne fonctionne qu'une fois, puis il est supprimé.
• Désactiver la 2FA exige le mot de passe et un code actuel ou un code de récupération.
• Régénérer les codes de récupération invalide l'ancien jeu.
• Envoyez un e-mail à l'utilisateur chaque fois que la 2FA est activée ou désactivée.

Requêtes à donner à votre créateur d'applications par IA

Commencez par le déroulement principal :

Ajoute une double authentification facultative avec des applications d'authentification (TOTP) à notre connexion existante par e-mail et mot de passe. Utilise une bibliothèque TOTP reconnue, n'écris pas l'algorithme toi-même. Dans les paramètres, affiche un QR code et le secret en texte, et n'active la 2FA qu'après la saisie d'un code valide. Stocke le secret chiffré et ne l'affiche plus jamais après la configuration. Affiche 10 codes de récupération à usage unique une seule fois, et stocke-les hachés.

Puis l'application de la règle, qui est l'endroit où le code généré est le plus souvent insuffisant :

Applique la 2FA côté serveur. Après un mot de passe correct, les utilisateurs ayant la 2FA activée reçoivent un état en attente de courte durée, et non une session complète. Chaque page et chaque route d'API protégées doit rejeter l'état en attente. Limite les tentatives de code à 5, puis bloque la seconde étape pendant 15 minutes et envoie un e-mail à l'utilisateur.

Puis la politique :

Exige la 2FA pour les comptes administrateurs : un administrateur sans 2FA est redirigé vers la configuration et ne peut pas accéder au tableau de bord tant qu'elle n'est pas faite. Exige le mot de passe et un code actuel pour désactiver la 2FA ou modifier l'e-mail du compte. Envoie un e-mail à l'utilisateur lorsque la 2FA est activée ou désactivée.

Enfin, demandez à l'agent d'expliquer ce qu'il a construit :

Liste chaque route qui vérifie qu'un second facteur a été validé, indique où sont stockés le secret TOTP et les codes de récupération, et explique comment ils sont protégés.

Erreurs courantes

• Une session délivrée après le mot de passe. C'est le bogue le plus grave. Si la session complète existe avant la vérification du code, la 2FA n'est qu'une façade. Testez en appelant une API protégée après la seule étape de mot de passe.
• Aucune limite de tentatives. Des essais illimités rendent le code vulnérable à la force brute.
• Secrets ou codes de récupération en clair. Une fuite de la base livre alors le second facteur de tous les utilisateurs.
• Activer avant de vérifier. Les utilisateurs qui ont mal scanné sont verrouillés à la connexion suivante.
• Aucun chemin de récupération. Chaque téléphone perdu devient un ticket de support ou un client perdu.
• Désactivation trop facile. Si une session volée peut désactiver la 2FA sans code, la protection disparaît.
• Des codes dans les journaux. Assurez-vous que les codes et les secrets n'apparaissent jamais dans les journaux serveur ou les messages d'erreur.
• Une vérification uniquement sur la page de connexion. La réinitialisation du mot de passe, la connexion par « lien magique » et toute connexion sociale doivent aussi respecter la 2FA, faute de quoi elles deviennent un moyen de la contourner.

Liste de contrôle des tests

• L'activation n'aboutit qu'après un code valide
• Une connexion avec le bon mot de passe mais sans code ne donne accès à aucune page ni API protégée
• Un mauvais code est rejeté ; des codes erronés répétés déclenchent le verrouillage et un e-mail
• Un code datant de quelques minutes est rejeté
• Chaque code de récupération ne fonctionne qu'une seule fois
• Désactiver la 2FA exige le mot de passe et un code actuel
• La réinitialisation du mot de passe ne contourne pas la 2FA
• Les administrateurs sans 2FA ne peuvent pas accéder aux pages d'administration (si elle est obligatoire)
• Les secrets et codes de récupération sont chiffrés ou hachés dans la base
• Aucun code ni secret n'apparaît dans les journaux

Lancez aussi la liste de contrôle de sécurité pour les applications créées avec l'IA complète avant le lancement.

Ajouter la 2FA dans Mythex

Mythex n'inclut pas de système de connexion intégré pour les utilisateurs finaux de votre application : la 2FA fait donc partie de l'approche d'authentification que vous choisissez, soit votre propre connexion par e-mail et mot de passe utilisant la base du projet, soit un fournisseur hébergé prenant en charge le multifacteur. Vous décrivez ce que vous voulez dans le chat à l'aide de requêtes semblables à celles ci-dessus, et les clés des fournisseurs vont dans les secrets du projet (via /secrets, les paramètres du projet ou la carte de secrets que l'agent affiche) plutôt que dans la zone de message. La recette de la documentation Ajouter une connexion à votre application propose une requête de départ, et Sécurité pour les applications que vous créez couvre les bonnes pratiques concernant les clés et les permissions. Une fois que l'agent a terminé, testez chaque point de la liste de contrôle dans l'aperçu avant de publier.

Questions