Troy Hunt soulève d'excellents points dans son article, Tout ce que vous avez toujours voulu savoir sur la création d'une fonction de réinitialisation sécurisée du mot de passe. . Les extraits les plus pertinents sont les suivants :
[Il existe deux approches communes :
- Générez un nouveau mot de passe sur le serveur et envoyez-le par courriel.
- Envoyez par courriel une URL unique qui facilitera le processus de réinitialisation.
Malgré de nombreuses indications contraires, le premier point n'est vraiment pas celui où nous voulons être. Le problème, c'est que cela signifie qu'un mot de passe permanent - que vous pouvez utiliser à tout moment - a été envoyé par un canal non sécurisé et se trouve maintenant dans votre boîte de réception.
...
Mais la première approche présente un autre problème de taille : elle simplifie à l'extrême le verrouillage malveillant d'un compte. Si je connais l'adresse électronique d'une personne qui possède un compte sur un site Web, je peux la bloquer quand bon me semble en réinitialisant simplement son mot de passe ; c'est une attaque par déni de service servie sur un plateau d'argent ! C'est pourquoi une réinitialisation ne doit être effectuée qu'après avoir vérifié le droit du demandeur à le faire.
Lorsque nous parlons d'une URL de réinitialisation, nous parlons d'une adresse de site Web qui est unique pour cette instance spécifique du processus de réinitialisation.
...
Ce que nous voulons faire, c'est créer un jeton unique qui peut être envoyé dans un e-mail dans le cadre de l'URL de réinitialisation, puis être associé à un enregistrement sur le serveur avec le compte de l'utilisateur, confirmant ainsi que le propriétaire du compte e-mail est bien celui qui tente de réinitialiser le mot de passe. Par exemple, le jeton peut être "3ce7854015cd38c862cb9e14a1ae552b" et est stocké dans une table avec l'ID de l'utilisateur effectuant la réinitialisation et l'heure à laquelle le jeton a été généré (nous y reviendrons dans un instant). Lorsque l'e-mail est envoyé, il contient une URL telle que "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b" et lorsque l'utilisateur la charge, la page vérifie l'existence du jeton et confirme par conséquent l'identité de l'utilisateur et permet de modifier le mot de passe.
...
L'autre chose que nous voulons faire avec une URL de réinitialisation est de limiter dans le temps le jeton de sorte que le processus de réinitialisation doit être terminé dans une certaine durée, disons dans une heure.
...
Enfin, nous voulons nous assurer qu'il s'agit d'un processus unique. Une fois le processus de réinitialisation terminé, le jeton doit être supprimé afin que l'URL de réinitialisation ne soit plus fonctionnelle. Comme pour le point précédent, il s'agit de s'assurer qu'un attaquant dispose d'une fenêtre très limitée pour abuser de l'URL de réinitialisation. De plus, le jeton n'est plus nécessaire si le processus de réinitialisation s'est terminé avec succès.
Il soulève de nombreux autres points intéressants concernant la prévention des fuites d'informations, les CAPTCHA, l'authentification à deux facteurs et, bien sûr, les meilleures pratiques de base comme le hachage des mots de passe. Il est important de noter que je ne suis pas d'accord avec Troy sur l'utilité des questions de sécurité. Le scepticisme de Bruce Schneier à l'égard de cette pratique :
L'intérêt de toutes ces questions est le même : un mot de passe de secours. Si vous oubliez votre mot de passe, la question secrète peut vérifier votre identité afin que vous puissiez choisir un autre mot de passe ou que le site vous envoie votre mot de passe actuel par courrier électronique. C'est une excellente idée du point de vue du service clientèle - un utilisateur est moins susceptible d'oublier le nom de son premier animal de compagnie qu'un mot de passe aléatoire - mais c'est terrible pour la sécurité. La réponse à la question secrète est beaucoup plus facile à deviner qu'un bon mot de passe, et les informations sont beaucoup plus publiques.
