🍪🔒 Implémente un 2FA (Two Factor Authentication)

Temps de lecture : 10 minutes

🚨 Cette édition est relativement longue, votre boîte mail risque de la tronquer. Je vous conseille de cliquer sur le titre ci-dessus pour l’ouvrir dans votre navigateur web. ☝️

Hello les petits Biscuits !

Bienvenue sur la 39ème édition de Ruby Biscuit.
Vous êtes maintenant 599 abonnés 🥳

Bonne lecture !

---

Bonjour à tous ! Aujourd’hui nous allons voir comment implémenter une feature de plus en plus populaire et demandée pour améliorer la sécurité de nos comptes, le 2FA. C’est parti 👇🏻

Mise en place

Nous allons avoir besoin de devise-two-factor (à supposer que vous ayez devise sur votre plateforme bien entendu).

La version la plus récente de devise-two-factor (6.1.0 à l’heure où j’écris ces lignes) n’est pas destinée aux versions de Rails qui précèdent la 7.0. Nous allons voir ici l’implémentation avec une version de Rails plus ancienne, celle de l’app sur laquelle je travaille actuellement, la 6.1.x. Pour cela nous allons devoir nous tourner vers la v4.x.

Nous verrons en fin d’article ce qu’il faut mettre en place pour les versions de Rails plus récentes.

Implémentation

• Déterminer sur quel modèle mettre en place le 2FA. Nous utiliserons la table users.

• Ajouter une config Devise à notre modèle User

• Lancer la migration pour ajouter les champs en ajoutant un default: false sur la colonne otp_required_for_login si vous voulez feature flaguer par utilisateur.

• Ajouter la durée de validité du code dans devise.rb :

• Enfin plus globalement, suivre la doc étape par étape est recommandée puisque cette dernière est très bien faite 👍

Nous allons désormais nous occuper de notre SessionsController et mettre en place nos conditions. On veut pouvoir require le two factor sous certaines conditions donc ajoutons cette logique avec 2 callbacks :

NB : si vous n’avez pas d’environnement de production cette configuration peut vous sembler inutile puisque vous souhaitez l’activer sans condition aucune.
Le require_no_authentication nous permet d’éviter un flash error de devise comme quoi nous sommes déjà connecté lors de l’authentification avec le 2FA.

Voilà pour la configuration globale de la gem !

Désormais nous allons ajouter notre logique métier et envoyer un mail avec un code de confirmation lorsque le 2FA est actif.

1ère étape :

La variable d’environnement 2FA_ENCRYPTION_KEY n’est pas là pour faire joli. La méthode generate_otp_secret de la gem sert à générer un secret sur l’objet visé. En effet, cela va générer des valeurs dans les champs que nous avons ajouté dans la migration. À savoir entre autre dans :

otp_secret, qui est trouvable dans la documentation, est obligatoire pour faire marcher le 2FA. Si vous tentez de vous connecter avec le two factor sans que votre utilisateur ai d’otp_secret alors vous aurez une 500.

Je vous conseille donc d’ajouter la ligne suivante à chaque création de User sur votre plateforme :

Si ensuite vous souhaitez feature flaguer par User vous pouvez ajouter 2 méthodes dans le modèle et les utiliser comme bon vous semble :

2ème étape :

Direction le SessionsController pour y ajouter du code :

Nous avons beaucoup de choses à décortiquer et nous allons regarder chaque étape de authenticate_with_two_factor pour comprendre.

• Tout d’abord si notre resource est vide nous voulons render le formulaire avec un message d’erreur.

• Ensuite nous allons vérifier si dans le cookie le param “remember me” (remember_2fa_id) est présent. Vous savez c’est la petite checkbox qui ressemble à ça habituellement 👇

Auquel cas si le mdp est correct, on ne redemandera pas de passer par une deuxième étape. Nous reviendrons sur cette histoire de cookie un peu plus tard.

• Sinon nous allons regarder si le param otp_attempt est présent. Il faut savoir que pour le 2FA nous avons 3 params obligatoires, l’email, le mdp et otp_attempt.
  Nous allons également checker si un param de session (otp_user_id) est présent (qu’on set par la suite), auquel cas nous consommons le token validate_and_consume_otp!, effaçons le param de session, enregistrons remember_2fa_id dans le cookie si l’utilisateur a coché la case et enfin l’authentifions.
  
  NB : la méthode validate_and_consume_otp! est trouvable dans la documentation.

• Dernière étape, créons un token de session qui nous servira pour le mail puis envoyons ce dernier. Néanmoins nous y ajoutons un lock pour ne pouvoir générer qu’un mail avec code unique par tranche horaire. C’est de la logique métier et non obligatoire, vous pouvez vous en passer.

• Si aucunes des conditions préalables n’ont été réunies cela signifie que le mdp est incorrect et nous affichons un message d’erreur.

Avec cela nous avons terminé la première étape du 2FA. Étape suivante, si je dois me connecter et rentrer un code de connexion alors j’ai besoin que l’on m’affiche un formulaire !

3ème étape :

Créer un fichier HTML (ici nous rentrons dans “users/sessions/two_factor”) pour y intégrer le formulaire. Libre à vous de choisir comment le présenter, mais cela peut ressembler à cela :

Une fois le mail reçu ainsi que le code qu’il contient (il vous faudra afficher current_otp à votre utilisateur) nous allons rentrer ce code et repasser dans le SessionController puisque le formulaire est une requête POST sur ce dernier.
Tout le chemin du authenticate_with_two_factor va donc être répété et vous pouvez désormais comprendre l’intérêt de remember_2fa_id. Si ce dernier était présent à la première étape alors nous ne serions pas passés par ce formulaire et le controller nous aurait redirigé.

Nous remarquons ici néanmoins le bouton “Renvoyer le code” et nous allons comprendre pourquoi nous avons mis en cache le otp_token :

C’est ici qu’intervient notre controller d’envoi de mail.

Pour éviter d’envoyer le mail à une mauvaise adresse nous allons vérifier que la valeur en cache est égale au param passé au controller, si tel est le cas on ajoute un lock (pour éviter le spam) et on envoie le mail, sinon on redirige.

Pour une meilleure expérience utilisateur, gérer cet envoi en AJAX est recommandé 👍

Tests

Pour les tests il y a beaucoup de cas à tester mais les plus globaux sont ceux-ci pour le SessionsController (n’hésitez pas à tester tous les cas) :

Et pour le SendOtpPasswordEmailsController :

En conclusion

Vous avez maintenant toutes les cartes en main pour mettre en oeuvre votre 2FA au sign in sur votre app ! Reste à décider, selon vos besoins et logiques métier, comment vous souhaitez organiser tout cela.
Pensez bien à tester tous les cas de figures que vos utilisateurs pourraient avoir envie d’essayer. Notre otp_user_id par exemple sert, entre autre, à conserver le bon id pour vérifier que si à l’étape du 2FA je fais un retour arrière et qu’ensuite je rentre une autre adresse mail (car je peux avoir 2 comptes différents), alors le mail s’envoie à la nouvelle adresse mail et non pas à l’ancienne !

Merci pour votre lecture et j’espère que l’article vous a plu 🚀

Bonus : ce qu’il faut faire pour Rails 7+

• Ajouter d’autres variables d’environnement

  

• La migration est différente.

• Retirer database_authenticatable de votre modèle puisque les 2 modules sont incompatibles. Cela se fait normalement tout seul avec la version 4.x.

Mais pour plus de précisions je vous invite à regarder la documentation.

— Stanislas