Comment ajouter l'authentification à deux facteurs à votre application

Pour ajouter l'authentification à deux facteurs (2FA) à votre app, permettez aux utilisateurs de lier une application d'authentification en numérisant un code QR, demandez le code à six chiffres qu'elle affiche après le mot de passe, et créez une session complète sur le serveur seulement 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 tentatives de devinette, et exigez le mot de passe et un code valide avant de désactiver la 2FA. Si vous utilisez un fournisseur d'authentification hébergé, activez plutôt son option multifactorielle intégrée au lieu de créer la vôtre.

Ce guide décrit les choix, le déroulement exact, des invites à donner à un outil de création par IA, et les erreurs qui font croire que la 2FA est présente alors qu'elle ne fait rien. Si le concept est nouveau pour vous, commencez par qu'est-ce que l'authentification à deux facteurs.

Avant de commencer : il vous faut une connexion fonctionnelle

La 2FA s'ajoute à une connexion existante. Il vous faut d'abord l'un de ces éléments :

• Votre propre système de connexion, avec des utilisateurs et des mots de passe hachés stockés dans la base de données de votre app.
• 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 app. Le reste 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), la norme (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, en général 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 à créer soi-même : beaucoup d'apps 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.

Créer le système ou l'activer?

Vérifiez la documentation actuelle de votre fournisseur pour savoir quels facteurs il prend en charge et sur quels forfaits. Dans tous les cas, n'écrivez jamais vous-même les calculs de génération de codes : utilisez une bibliothèque largement reconnue.

Décidez de la politique d'abord

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. Exiger la 2FA pour toute personne ayant des pouvoirs d'administration est courant. Voir le contrôle d'accès basé sur les rôles.
2. À quelle fréquence les utilisateurs saisissent-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 le courriel, les coordonnées de versement ou désactiver la 2FA sont de bons candidats. On parle d'authentification de niveau supérieur (step-up authentication).
4. Quelle est la procédure en cas de perte du téléphone? Des codes de récupération, plus une solution manuelle de secours 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'indication que la 2FA est activée, le secret TOTP (chiffré au repos, pas en texte brut), la date d'activation, et une liste de codes de récupération hachés, comme les mots de passe. Prévoyez aussi un endroit pour compter les tentatives échouées.

2. Inscription

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

L'étape 4 est importante : activer la 2FA avant de confirmer un code verrouille toute personne dont la numérisation a échoué.

3. Connexion avec une seconde étape

1. L'utilisateur soumet son courriel 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 plutôt un état court de « second facteur en attente ».
3. L'app affiche l'écran de code. Le serveur vérifie le code, en tolérant une petite marge de décalage d'horloge.
4. Ce n'est qu'alors que le serveur émet la vraie session.

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

4. Limites et alertes

Un code à six chiffres compte un million de combinaisons, ce qui se devine sans limite. Plafonnez les tentatives, verrouillez la seconde étape pendant un certain temps après plusieurs échecs, et envoyez un courriel à l'utilisateur lorsque cela se produit. Voir la limitation de débit et l'envoi de courriels depuis votre app.

5. Récupération et désactivation

• Un code de récupération fonctionne une seule 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 ensemble.
• Envoyez un courriel à l'utilisateur chaque fois que la 2FA est activée ou désactivée.

Invites à donner à votre outil de création par IA

Commencez par le cœur du système :

Ajoute l'authentification à deux facteurs facultative avec des applications d'authentification (TOTP) à notre connexion courriel et mot de passe existante. Utilise une bibliothèque TOTP reconnue, n'écris pas l'algorithme toi-même. Dans les paramètres, affiche un code QR et le secret en texte, et n'active la 2FA qu'après que l'utilisateur a saisi un code valide. Stocke le secret chiffré et ne le réaffiche 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, 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 valide, les utilisateurs ayant la 2FA activée obtiennent un état de « second facteur en attente » de courte durée, et non une session complète. Chaque page et chaque route d'API protégée doit rejeter cet état en attente. Limite les tentatives de code à 5, puis verrouille la seconde étape pendant 15 minutes et envoie un courriel à l'utilisateur.

Ensuite la politique :

Exige la 2FA pour les comptes administrateurs : un administrateur sans 2FA est dirigé vers la configuration et ne peut pas accéder au tableau de bord tant qu'elle n'est pas terminée. Exige le mot de passe et un code actuel pour désactiver la 2FA ou modifier le courriel du compte. Envoie un courriel à 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é complété, l'endroit où le secret TOTP et les codes de récupération sont stockés, et la façon dont ils sont protégés.

Erreurs courantes

• Session émise 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 que décorative. Testez en appelant une API protégée après la seule étape du 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 texte brut. Une fuite de la base de données donnerait alors le second facteur de tout le monde.
• Activer avant de vérifier. Les utilisateurs qui ont mal numérisé le code sont verrouillés à leur prochaine connexion.
• Aucune procédure de récupération. Chaque téléphone perdu devient un billet de soutien ou un client perdu.
• Désactivation trop facile. Si une session volée peut désactiver la 2FA sans code, la protection disparaît.
• Codes dans les journaux. Assurez-vous que les codes et les secrets n'apparaissent jamais dans les journaux du serveur ni dans les messages d'erreur.
• Vérifier seulement 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, sinon elles deviennent un contournement.

Liste de contrôle des tests

• L'inscription ne se termine qu'après un code valide
• Une connexion avec un mot de passe correct mais sans code ne donne accès à aucune page ni API protégée
• Un mauvais code est rejeté; des mauvais codes répétés déclenchent le verrouillage et un courriel
• Un code datant de quelques minutes est rejeté
• Chaque code de récupération fonctionne exactement une 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 exigée)
• Les secrets et les codes de récupération sont chiffrés ou hachés dans la base de données
• Aucun code ni secret n'apparaît dans les journaux

Exécutez aussi la liste de contrôle de sécurité pour les apps 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 app : la 2FA fait donc partie de la méthode d'authentification que vous choisissez — votre propre connexion courriel et mot de passe utilisant la base de données du projet, ou un fournisseur hébergé avec prise en charge multifactorielle. Décrivez ce que vous voulez dans le clavardage à l'aide de requêtes semblables à celles ci-dessus, et stockez les clés du fournisseur dans les secrets du projet (par /secrets, dans les paramètres du projet, ou dans la carte des secrets que l'agent affiche) plutôt que dans la zone de saisie. La recette de la documentation Ajouter une connexion à votre app propose une requête de départ, et Sécurité pour les apps que vous créez explique les bonnes habitudes concernant les clés et les permissions. Une fois que l'agent a terminé, testez chaque élément de la liste de contrôle dans l'aperçu avant de publier.

Questions