Quelles sont les meilleures pratiques pour les liens d'activation / d'enregistrement / de réinitialisation de mot de passe dans les e-mails avec nonce
Les applications envoient des e-mails pour vérifier les comptes d'utilisateurs ou réinitialiser un mot de passe. Je crois que ce qui suit devrait être ainsi et je demande des références et des implémentations.
Si une application doit envoyer un lien dans un e-mail pour vérifier l'adresse de l'utilisateur, selon moi, le lien et le traitement du lien par l'application devraient avoir les caractéristiques suivantes:
- Le lien contient un nonce dans l'URI de la demande (
http://Host/path?nonce). - En suivant le lien (GET), l'utilisateur se voit présenter un formulaire, éventuellement avec le nonce.
- L'utilisateur confirme l'entrée (POST).
- Le serveur reçoit la demande et
- vérifie les paramètres d'entrée,
- effectue le changement,
- et invalide le nonce.
Cela devrait être correct par HTTP RFC sur les méthodes sûres et idempotentes .
Le problème est que ce processus implique une page supplémentaire ou une action de l'utilisateur (élément 3), qui est considérée comme superflue (sinon inutile) par beaucoup de gens. J'ai eu du mal à présenter cette approche aux pairs et aux clients, je demande donc l'avis d'un groupe technique plus large à ce sujet. Le seul argument que j'avais contre le fait de sauter l'étape POST était un préchargement possible du lien à partir du navigateur.
- Existe-t-il des références à ce sujet qui pourraient mieux expliquer l'idée et convaincre même une personne non technique (bonnes pratiques issues des revues, blogs, ...)?
- Y a-t-il des sites de référence (de préférence populaires et avec de nombreux utilisateurs) qui mettent en œuvre cette approche?
- Sinon, existe-t-il des raisons documentées ou des alternatives équivalentes?
Merci,
Kariem
Détails épargnés
J'ai gardé la partie principale courte, mais pour réduire trop de discussions autour des détails que j'avais intentionnellement omis, j'ajouterai quelques hypothèses:
- Le contenu de l'e-mail ne fait pas partie de cette discussion. L'utilisateur sait qu'elle doit cliquer sur le lien pour effectuer l'action. Si l'utilisateur ne réagit pas, rien ne se passera, ce qui est également connu.
- Nous n'avons pas à indiquer pourquoi nous envoyons un mail à l'utilisateur, ni la politique de communication. Nous supposons que l'utilisateur s'attend à recevoir l'e-mail.
- Le nonce a un horodatage d'expiration et est directement associé à l'adresse e-mail du destinataire pour réduire les doublons.
Notes
Avec OpenID et similaires, les applications Web normales ne sont plus obligées de mettre en œuvre une gestion de compte utilisateur standard (mot de passe, e-mail ...), mais certains clients veulent toujours ' leurs propres utilisateurs'
Curieusement, je n'ai pas encore trouvé de question satisfaisante ni de réponse. Ce que j'ai trouvé jusqu'à présent:
Cette question est très similaire à Implémentation d'URL d'activation sécurisées et uniques à usage unique dans ASP.NET (C #) .
Ma réponse est proche de votre schéma, avec quelques problèmes signalés - comme une courte période de validité, la gestion des doubles inscriptions, etc.
Votre utilisation d'un nonce cryptographique est également importante, que beaucoup ont tendance à ignorer - par exemple "permet simplement d'utiliser un GUID" ...
Un nouveau point que vous soulevez, et c'est important ici, est l'idempotence de GET.
Bien que je sois d'accord avec votre intention générale, il est clair que l'idempotence est en contradiction directe avec les liens à usage unique, ce qui est une nécessité dans certaines situations comme celle-ci.
J'aurais aimé affirmer que cela ne viole pas vraiment l'idempotence du GET, mais malheureusement c'est le cas ... D'un autre côté, le RFC dit GET [~ # ~] devrait [~ # ~] être idempotent, ce n'est pas un MUST. Je dirais donc renoncer à cela dans ce cas, et s'en tenir aux liens non valides une fois.
Si vous vraiment souhaitez viser une stricte conformité RFC et ne pas entrer dans des GET non idempotents (?), Vous pouvez demander à la page GET de soumettre automatiquement les POST - une sorte d'échappatoire autour de cette partie de la RFC, mais légitime, et vous n'avez pas besoin que l'utilisateur double-optine, et vous ne le dérangez pas ...
Vous n'avez pas vraiment à vous soucier du préchargement (parlez-vous de CSRF ou d'optimiseurs de navigateur?) ... CSRF est inutile à cause du nonce, et les optimiseurs ne traiteront généralement pas le javascript (utilisé pour la soumission automatique) sur la page préchargée.
À propos de la réinitialisation du mot de passe:
La pratique consistant à envoyer un e-mail à l'adresse e-mail enregistrée de l'utilisateur n'est pas une bonne sécurité, bien que très courante dans la pratique. Cela sous-traite entièrement la sécurité de votre application au fournisseur de messagerie de l'utilisateur. Peu importe la longueur des mots de passe dont vous avez besoin et quel que soit le hachage de mot de passe intelligent que vous utilisez. Je pourrai accéder à votre site en lisant l'e-mail envoyé à l'utilisateur, étant donné que j'ai accès au compte de messagerie ou que je peux lire l'e-mail non crypté n'importe où sur le chemin de l'utilisateur (pensez: evil sysadmins).
Cela peut ou non être important selon les exigences de sécurité du site en question, mais moi, en tant qu'utilisateur du site, je voudrais au moins pouvoir désactiver une telle fonction de réinitialisation de mot de passe car je considère que ce n'est pas sûr.
J'ai trouvé ce livre blanc qui traite du sujet.
La version courte de la façon de le faire de manière sécurisée:
Exiger des faits concrets sur le compte
- nom d'utilisateur.
- adresse e-mail.
- Numéro de compte à 10 chiffres ou autres informations comme le numéro de sécurité sociale.
Exiger que l'utilisateur réponde à au moins trois questions prédéfinies (prédéfinies par vous, ne laissez pas l'utilisateur créer ses propres questions) qui ne peuvent pas être triviales. Comme "Quel est votre lieu de vacances préféré", pas "Quelle est votre couleur préférée".
Facultativement: envoyez un code de confirmation à une adresse e-mail prédéfinie ou à un numéro de cellule (SMS) que l'utilisateur doit saisir.
Autorisez l'utilisateur à saisir un nouveau mot de passe.
Je suis généralement d'accord avec vous avec quelques modifications suggérées ci-dessous.
- L'utilisateur s'inscrit sur votre site en fournissant un e-mail.
- Un e-mail de vérification est envoyé au compte de l'utilisateur avec deux liens: a) Un lien avec le GUID pour vérifier l'enregistrement b) Un lien avec le GUID pour rejeter la vérification
- Lorsqu'ils visitent l'URL de vérification depuis leur e-mail, ils sont automatiquement vérifiés et le guide de vérification est marqué comme tel dans votre système.
- Lorsqu'ils visitent l'URL de rejet de leur e-mail, ils sont automatiquement supprimés de la file d'attente des vérifications possibles, mais plus important encore, vous pouvez dire à l'utilisateur que vous êtes désolé pour l'inscription par e-mail et leur donner d'autres options telles que la suppression de leur e-mail de votre système. Cela mettra fin à toute plainte de type de service personnalisé concernant une personne entrant mon e-mail dans votre système ... bla bla bla.
Oui, vous devez supposer que lorsqu'ils cliquent sur le lien de vérification, ils sont vérifiés. Leur faire cliquer sur un deuxième bouton dans une page est un peu trop et n'est nécessaire que pour l'enregistrement de style double opt dans lequel vous prévoyez de spammer la personne qui s'est inscrite. Les schémas d'enregistrement/de vérification standard n'exigent généralement pas cela.