emailr_
Tous les articles
usecase·9 min

E-mails de réinitialisation de mot de passe : meilleures pratiques de sécurité

authsecuritytransactional

Résumé

Les e-mails de réinitialisation de mot de passe sont critiques pour la sécurité. Utilisez des jetons à durée de vie courte et à usage unique. N'incluez jamais de mots de passe dans un e-mail. Envoyez immédiatement. Rendez le lien de réinitialisation évident. Informez les utilisateurs après une réinitialisation réussie. Un flux de réinitialisation compromis signifie des comptes compromis.

Parmi tous les e-mails que votre application envoie, ceux de réinitialisation de mot de passe sont les plus sensibles. S'ils sont mal conçus, vous créez une vulnérabilité que des attaquants exploiteront. S'ils sont bien faits, vous mettez en place un processus de récupération sécurisé et convivial qui inspire confiance.

Les e-mails de réinitialisation sont aussi parmi les plus sensibles au temps. Un utilisateur verrouillé hors de son compte est frustré et anxieux. Chaque minute d'attente est une minute où il peut abandonner, contacter le support, ou perdre confiance dans votre produit.

Les fondamentaux de la sécurité

Les e-mails de réinitialisation sont une cible de choix pour les attaquants car ils offrent une voie de prise de contrôle de compte. Votre flux de réinitialisation doit être sécurisé par conception.

N'envoyez jamais de mots de passe par e-mail. Ni temporaires, ni générés, ni aucun. L'e-mail n'est pas un canal sécurisé — il peut être intercepté, transféré, ou accessible à toute personne ayant accès à la boîte de réception. Utilisez toujours un lien de réinitialisation sécurisé qui permet aux utilisateurs de définir leur propre mot de passe.

Les jetons de réinitialisation doivent être aléatoires de manière cryptographique et impossibles à deviner. Utilisez le générateur de nombres aléatoires sécurisé de votre plateforme, pas des valeurs prévisibles comme des timestamps ou des IDs séquentiels. Un jeton devrait avoir au moins 128 bits d'entropie.

Les jetons doivent avoir une durée de vie courte. 15 minutes à 1 heure est raisonnable. Des fenêtres d'expiration plus longues donnent aux attaquants plus de temps pour intercepter ou deviner des jetons. Les utilisateurs qui ne réinitialisent pas dans ce délai peuvent demander un nouveau jeton.

Les jetons doivent être à usage unique. Une fois qu'un jeton a été utilisé pour réinitialiser un mot de passe, invalidez-le immédiatement. Cela empêche les attaques par rejeu où un attaquant utilise un jeton intercepté après l'utilisateur légitime.

Stockez les jetons de manière sécurisée. Hashez les jetons avant de les stocker dans votre base de données, comme pour les mots de passe. Si votre base est compromise, les attaquants ne devraient pas pouvoir utiliser les jetons stockés.

L'expérience utilisateur

Sécurité et ergonomie ne sont pas opposées — un flux de réinitialisation confus conduit à des tickets de support et à des contournements qui créent leurs propres problèmes de sécurité.

Envoyez les e-mails de réinitialisation immédiatement. Les utilisateurs attendent. Un e-mail de réinitialisation qui met 10 minutes à arriver paraît cassé. Donnez la priorité à ces e-mails dans votre file d'envoi — ils doivent partir en quelques secondes.

Rendez le lien de réinitialisation impossible à manquer. Un gros bouton évident qui dit 'Réinitialiser le mot de passe' fonctionne mieux qu'un lien texte noyé dans un paragraphe. Les utilisateurs cherchent l'action, ils ne lisent pas en détail.

Gardez l'e-mail concentré sur l'essentiel. Ce n'est pas le moment pour du contenu promotionnel, des liens sociaux, ou un design élaboré. L'utilisateur n'a qu'un objectif : réinitialiser son mot de passe. Tout le reste est une distraction.

Incluez du contexte sur la demande. Quand a-t-elle été faite ? Depuis quelle IP ou quel emplacement ? Cela aide les utilisateurs à déterminer si la demande est légitime ou si quelqu'un d'autre essaie d'accéder à leur compte.

Offrez une marche à suivre claire si l'utilisateur n'a pas demandé la réinitialisation. 'Si vous n'avez pas demandé ceci, vous pouvez ignorer cet e-mail' est rassurant. Certains utilisateurs recevront des e-mails qu'ils n'ont pas demandés (fautes de frappe, tentatives malveillantes) et doivent savoir qu'ils sont en sécurité.

Le flux de réinitialisation

Le flux complet de réinitialisation comporte plusieurs étapes, chacune avec des implications de sécurité :

La page de demande ne doit demander qu'une adresse e-mail. Ne confirmez pas si l'adresse existe dans votre système — cela divulgue des informations aux attaquants qui tentent d'énumérer les comptes. Affichez toujours le même message : 'Si un compte existe avec cet e-mail, nous avons envoyé des instructions de réinitialisation.'

Limitez le débit des demandes de réinitialisation. Un attaquant ne devrait pas pouvoir inonder une adresse d'e-mails de réinitialisation (harcèlement) ou essayer rapidement de nombreuses adresses (énumération). Limitez les demandes par e-mail et par IP.

La page de réinitialisation (où les utilisateurs arrivent après avoir cliqué sur le lien) doit valider le jeton avant d'afficher le formulaire de mot de passe. Si le jeton est invalide ou expiré, affichez une erreur claire et permettez de demander un nouveau jeton.

Après une réinitialisation réussie, invalidez le jeton, invalidez toutes les autres sessions de ce compte (l'utilisateur peut réinitialiser car il soupçonne une compromission), et envoyez un e-mail de confirmation l'informant que son mot de passe a été modifié.

L'e-mail de confirmation est une fonctionnalité de sécurité. Si quelqu'un d'autre a réinitialisé le mot de passe, l'utilisateur légitime verra cet e-mail et saura que son compte a été compromis. Incluez des informations sur la façon de récupérer le compte si ce n'était pas lui.

Erreurs courantes

Même des développeurs expérimentés font des erreurs avec les flux de réinitialisation de mot de passe :

Des jetons prévisibles sont étonnamment fréquents. Utiliser l'ID utilisateur, le hash de l'e-mail, ou le timestamp comme jeton (ou une partie) rend les jetons devinables. Utilisez toujours des valeurs aléatoires cryptographiquement sécurisées.

Ne pas expirer les jetons laisse une fenêtre ouverte indéfiniment. Si un utilisateur demande une réinitialisation mais ne la poursuit pas, ce jeton ne devrait pas fonctionner pour toujours. Implémentez l'expiration.

Ne pas invalider les jetons après usage permet des attaques par rejeu. Une fois qu'un jeton est utilisé, il ne doit plus jamais fonctionner, même s'il n'a pas encore expiré.

Confirmer l'existence d'un e-mail aide les attaquants. Si votre page de réinitialisation dit 'aucun compte trouvé' pour des e-mails invalides, les attaquants peuvent s'en servir pour construire une liste de comptes valides. Affichez toujours la même réponse.

Ne pas notifier après la réinitialisation laisse les utilisateurs dans l'ignorance d'une compromission potentielle. L'e-mail de confirmation est un contrôle de sécurité critique, pas seulement un plus.

Une livraison lente frustre les utilisateurs et les pousse vers des détours peu sûrs. Si les e-mails de réinitialisation sont lents, les utilisateurs peuvent essayer plusieurs fois, contacter le support pour des réinitialisations manuelles, ou abandonner complètement. La rapidité compte.

Le contenu de l'e-mail

L'e-mail de réinitialisation doit être simple et clair :

Objet : Restez simple. 'Réinitialisez votre mot de passe' ou 'Demande de réinitialisation de mot de passe' fonctionne. Évitez les tactiques d'urgence qui ressemblent à du phishing.

Expéditeur : Utilisez un nom et une adresse d'expéditeur reconnaissables. 'YourApp <[email protected]>' est préférable à '[email protected]'. Les utilisateurs doivent reconnaître immédiatement qui a envoyé l'e-mail.

Corps : Expliquez ce qui s'est passé ('Vous avez demandé une réinitialisation de mot de passe'), fournissez le bouton/le lien de réinitialisation, mentionnez l'expiration ('Ce lien expire dans 1 heure'), et expliquez quoi faire s'ils n'ont pas fait la demande.

N'incluez pas le nom d'utilisateur ni d'autres détails du compte. Si l'e-mail est intercepté, vous ne voulez pas offrir plus d'informations que nécessaire aux attaquants.

Envisagez d'inclure le contexte de la demande (IP, emplacement, heure) afin que les utilisateurs puissent vérifier que la demande était légitime. Mais équilibrez cela avec les préoccupations de confidentialité — certains utilisateurs ne veulent pas voir leur localisation dans un e-mail.

Frequently asked questions

Combien de temps les jetons de réinitialisation doivent-ils être valides ?

15 minutes à 1 heure est typique. Plus court est plus sécurisé mais peut frustrer les utilisateurs qui ne consultent pas leur e-mail immédiatement. 1 heure est un compromis raisonnable pour la plupart des applications.

Dois-je exiger l'ancien mot de passe pour en définir un nouveau ?

Non — tout l'intérêt de la réinitialisation est que l'utilisateur ne connaît pas son mot de passe actuel. Le jeton de réinitialisation sert de preuve d'identité. Exiger l'ancien mot de passe irait à l'encontre de l'objectif.

Que se passe-t-il si l'e-mail de l'utilisateur est compromis ?

La réinitialisation par e-mail suppose que le compte e-mail est sécurisé. S'il ne l'est pas, un attaquant peut réinitialiser les mots de passe de tous les comptes liés. Envisagez d'offrir des méthodes de récupération alternatives (SMS, codes de sauvegarde, questions de sécurité) pour les applications à haute sécurité.

Dois-je connecter automatiquement les utilisateurs après la réinitialisation ?

Les avis divergent. La connexion automatique est plus pratique mais signifie que toute personne ayant le lien de réinitialisation obtient l'accès. Exiger une connexion après la réinitialisation ajoute de la friction mais garantit que l'utilisateur sait que son nouveau mot de passe fonctionne. Pour les applications à haute sécurité, exigez une connexion.

e_

Écrit par l'équipe emailr

Nous construisons l'infrastructure email pour les développeurs

Prêt à commencer à envoyer ?

Obtenez votre clé API et envoyez votre premier email en moins de 5 minutes. Aucune carte de crédit requise.