Quelles sont les meilleures pratiques pour les liens d'activation / inscription / réinitialisation de mot de passe dans les courriers électroniques avec nonce

Question

Les Applications d'envoyer des e-mails pour vérifier les comptes d'utilisateur ou de réinitialiser un mot de passe. Je crois que ce qui suit est la façon dont il devrait être et que je demande des références et des implémentations.

Si une application a envoyer un lien dans un e-mail pour vérifier l'adresse de l'utilisateur, selon mon point de vue, le lien de l'application et la transformation du lien doit avoir les caractéristiques suivantes:

1. Le lien contient un nonce dans l'URI de la demande (http://host/path?nonce).
2. En suivant le lien (GET), l'utilisateur est présenté un formulaire, éventuellement avec le nonce.
3. L'utilisateur confirme l'entrée (POST).
4. Le serveur reçoit la requête et
   • vérifie les paramètres d'entrée,
   • effectue le changement,
   • et invalide le nonce.

Cela devrait être correct par HTTP RFC sur la Sécurité et la Quantité de Méthodes.

Le problème est que ce processus implique une page supplémentaire ou une action de l'utilisateur (point 3), qui est considéré comme superflu (si ce n'est inutile) par beaucoup de gens. J'ai eu des problèmes de présentation de cette approche à des pairs et des clients, donc je fais une demande d'entrée sur ce d'un plus large du groupe technique. Le seul argument que j'avais de passer l'après étape était possible de pré-chargement du lien à partir du navigateur.

• Existe-il des références sur ce sujet qui pourrait mieux expliquer l'idée et convaincre même un non-technique de la personne (les meilleures pratiques de journaux, blogs, ...)?
• Existe-il des sites de référence (de préférence populaire et avec de nombreux utilisateurs) mise en œuvre de cette approche?
  • Si non, est-il documenté des raisons ou des alternatives équivalentes?

Merci,
Kariem

---

Détails épargné

J'ai gardé la partie principale court, mais de la réduire trop de discussion autour de l'détails qui m'avait intentionnellement laissé de côté, je vais ajouter quelques hypothèses:

• Le contenu de l'email n'est pas une partie de cette discussion. L'utilisateur sait qu'elle a de cliquez sur le lien pour effectuer l'action. Si l'utilisateur ne réagit pas, il ne se passera rien, qui est également connu.
• Nous n'avons pas à indiquer pourquoi nous sommes de diffusion de l'utilisateur, ni la politique de communication. Nous supposons que l'utilisateur s'attend à recevoir l'e-mail.
• Le nonce a une date d'expiration d'horodatage et est associée directement avec les bénéficiaires de l'adresse de courriel afin de réduire les doublons.

---

Notes

Avec OpenID et l'aime, normal les applications web sont exonérés de la mise en œuvre de la norme de gestion de comptes utilisateur (mot de passe, e-mail ...), mais encore de certains clients 'de leurs propres utilisateurs'

Assez étrangement, je n'ai pas trouvé une bonne question, ni réponse ici encore. Ce que j'ai trouvé jusqu'à présent:

• Réponse par Ne en HTTP POST avec des paramètres de requête URL - bonne idée ou pas?
• Question de Thomas -- Quand utilisez-vous POST et quand utilisez-vous OBTENIR?

Answer 1

Cette question est très similaire à la mise en Œuvre sécurisé, unique "à usage unique" activation de l'Url dans les ASP.NET (C#).

Ma réponse il y a près de votre régime, avec quelques problèmes mis en évidence - comme une courte période de validité, la manipulation des doubles inscriptions, etc.
Votre utilisation d'un chiffrement nonce est également important, que beaucoup ont tendance à sauter par-dessus - par exemple "vous permet d'utiliser un GUID"...

Un nouveau point de vous faire élever, et c'est important, ici, est wrt l'idempotence de l'OBTENIR.
Que je suis d'accord avec votre intention générale, c'est clair que idempotence est en contradiction directe avec un temps les liens, ce qui est une nécessité dans certaines situations comme ça.

Je voudrais avoir aimé postulons que cela ne marche pas vraiment violer les idempotentness de l'OBTENIR, mais, malheureusement, elle ne... d'autre part, le RFC a dit OBTENIR DEVRAIT être idempotent, ce n'est pas un must. Je dirais donc en profiter dans ce cas, et s'en tenir à l'auto-invalidée liens.

Si vous vraiment voulez viser la stricte conformité à la RFC, et ne pas tomber dans le non-idempotent(?) Obtient, vous pouvez avoir la page auto-soumettre l'après - type d'un vide autour de bits de la RFC, mais légitime, et vous n'exigent que l'utilisateur double-optin, et vous n'êtes pas à l'écoute de lui...

Vous n'avez pas vraiment à vous soucier de préchargement (êtes-vous talkng sur CSRF, ou d'un navigateur optimiseurs?)... CSRF est inutile en raison du nonce, et les optimiseurs souvent coutume processus de javascript (utilisé pour l'auto-submit) sur la préchargé page.

Answer 2

À propos de réinitialisation de mot de passe:

La pratique de le faire en envoyant un courriel à l'utilisateur adresse e-mail enregistrée est, bien que très commun dans la pratique, pas bon de sécurité. Ce faisant pleinement à l'externalisation de votre application de sécurité pour l'utilisateur du fournisseur de messagerie. Il n'a pas d'importance combien de temps les mots de passe dont vous avez besoin et quel que soit intelligent hachage de mot de passe que vous utilisez. Je vais être en mesure d'obtenir dans votre site par la lecture de l'e-mail envoyé à l'utilisateur, étant donné que j'ai accès au compte de messagerie ou suis capable de lire le courriel non chiffré n'importe où sur son chemin à l'utilisateur (pensez: mal les administrateurs système).

Cela peut ou peut ne pas être important selon les règles de sécurité du site en question, mais moi, en tant qu'utilisateur du site, voudrait à tout le moins être en mesure de désactiver une telle réinitialisation de mot de passe de la fonction car je considère qu'il est dangereux.

J'ai trouvé ce livre blanc qui traite le sujet.

La version courte de comment le faire de manière sécurisée:

1. Exiger des faits sur le compte

   1. nom d'utilisateur.
   2. adresse e-mail.
   3. Les 10 chiffres du numéro de compte ou d'autres informations comme le numéro de sécurité sociale.

2. Exiger que l'utilisateur répond à au moins trois questions prédéfinies (prédéfini par vous, ne pas permettre à l'utilisateur de créer ses propres questions) qui ne peut pas être trivial. Comme "Ce qui est votre lieu de vacances préféré", pas "Quelle est votre couleur préférée".

3. En option: Envoyer un code de confirmation à un prédéfini adresse de courriel ou un numéro de cellulaire (SMS) que l'utilisateur a à l'entrée.

4. Permettre à l'utilisateur de saisir un nouveau mot de passe.

EDIT 2014-01-06: correction de lien brisé de papier blanc.

Answer 3

Je suis généralement d'accord avec vous, avec quelques modifications suggérées ci-dessous.

1. L'utilisateur s'inscrit sur votre site fournissant un e-mail.
2. Vérification de l'email est envoyé pour le compte de l'utilisateur avec deux liens: a) Un lien avec le GUID pour vérifier l'enregistrement b) Un lien avec le GUID de rejeter la vérification
3. Lorsqu'ils visitent la vérification de l'url à partir de leur e-mail, ils sont automatiquement vérifiées et la vérification guid est marqué comme tel dans votre système.
4. Lors de la visite du rejet de l'url de leur e-mail, ils sont automatiquement supprimés de la file d'attente d'éventuelles vérifications, mais plus important encore, vous pouvez indiquer à l'internaute que vous êtes désolé pour l'e-mail d'inscription et de leur donner d'autres options comme la suppression de leurs e-mails à partir de votre système. Cela empêchera toute service personnalisé type de plaintes au sujet de quelqu'un d'entrer dans mon e-mail dans votre système...bla bla bla.

Oui, vous devez supposer que lorsqu'il clique sur le lien de vérification qu'ils sont vérifiés. Les incitant à cliquer sur un deuxième bouton dans une page est un peu beaucoup et nécessaire uniquement pour le double opt-in style d'inscription où vous prévoyez de spam de la personne qui a enregistré. Enregistrement Standard/systèmes de vérification n'a généralement pas besoin de cette.