Limitée dans le temps, ou un temps d'utilisation, la réinitialisation de mot de passe de jetons?

Utilisateurs oublier les mots de passe, et (presque) tous les sites d'adhésion besoin d'un moyen pour aider les utilisateurs à accéder de nouveau.

J'aimerais mettre en œuvre le scénario commun:

  1. Utilisateur hits site, essaie d'ouvrir une session, ne peut pas, et se rend compte qu'ils ont oublié mot de passe de la merde!
  2. Utilisateur entre l'adresse email et clique sur "mot de passe oublié"
  3. L'utilisateur reçoit un email avec un lien de réinitialisation de mot de passe

Voici comment j'ai l'intention de mettre en œuvre des ce (C#/ASP.NET MVC):

  1. Lorsque l'utilisateur entre e-mail et hits "mot de passe oublié" sur le bouton de mon site va générer un GUID, de le stocker sur le membre de l'entité dans la base de données (member.ResetToken), et de les envoyer par courriel un lien avec ce GUID dans l'url (l'e-mail envoyé les informe qu'ils peuvent utiliser ce lien pour un temps seulement)
  2. Utilisateur clique sur le lien et mon site à la recherche de leur compte en se fondant sur que member.ResetToken à partir de l'url. Si leur compte est trouvé leur montrer un formulaire de réinitialisation de mot de passe, et quand ils ont terminé la réinitialisation efface le member.ResetToken à partir de leur compte.

Voici ma question: gardez-le comme ceci (dans lequel ils peuvent réinitialiser leur mot de passe avec ce lien à tout moment, maintenant ou dans l'avenir), ou ajouter un horodatage à la limite de combien de temps ils ont pour réinitialiser leur mot de passe?

À partir d'un UX point de vue de la possibilité de réinitialiser votre mot de passe chaque fois que vous êtes prêt est grand, mais je veux m'assurer que je ne suis pas passer à côté des questions de sécurité, cela pourrait soulever.

Générer une demande de réinitialisation et de l'e-mail et de le rendre limitée dans le temps, mais ne changez pas le mot de passe. En changeant de mot de passe et de l'envoi de la réinitialisation, il est facile de souffler quelqu'mot de passe 🙂
Ce n'est pas ce que j'ai décrit. 😉 Le mot de passe est changé par l'utilisateur. Une url avec réinitialisation de mot de passe est envoyé lorsqu'ils cliquent sur "j'ai oublié mon mot de passe". Le GUID est la réinitialisation de mot de passe (même si je vais probablement pas utiliser un GUID, mais quelque chose de plus aléatoire). Je me demande si une fois de jeton de sécurité suffisante par rapport à un temps limité jeton. Merci bien.
Ouais, j'ai compris ce que vous disiez, découvrez ma réponse.

OriginalL'auteur Chaddeus | 2013-10-09

  1. 9

    Votre système fonctionne réellement, mais il y a certains points qui pourraient être améliorés. Mais d'abord à votre question de départ sur le temps limite:

    Posons-nous la question opposée: Pourquoi un jeton restent valables infinit?

    Il n'y a aucun avantage, lorsque la réinitialisation-link peut être cliqué deux ans plus tard, l'utilisateur clique sur le lien dans environ une heure ou il a probablement oublié le lien (et pouvez en demander un nouveau si nécessaire). D'autre part, être capable de lire les e-mails ne veut pas nécessairement dire qu'un attaquant doit pirater le compte e-mail, il y a par exemple l'open e-mail du client dans le bureau, la perte d'un téléphone mobile, une sauvegarde sur le (perdu) lecteur USB...

    L'amélioration la plus importante est que vous ne devez stocker une de hachage du token dans votre base de données. Quelqu'un ayant accès à la base de données (SQL injection), pourrait, sinon, la demande de réinitialisation du mot de passe de l'adresse e-mail qu'il aime, et parce qu'il peut voir le nouveau jeton, il pourrait l'utiliser pour définir son propre mot de passe.

    Alors je voudrais stocker ces réinitialiser les informations dans une table séparée. De là, vous pouvez stocker le nom d'utilisateur, le haché de jeton, une date d'expiration, et les informations de déterminer si le lien a déjà été utilisé. L'utilisateur n'est pas dans un état spécial, puis.

    Peut-être que j'ai mal compris ce point, mais le lien de réinitialisation doit pointer vers une page spéciale pour les réinitialisations de mot de passe. Lorsque l'utilisateur accède à la page de connexion, il ne devrait pas être un traitement spécial, la page de connexion ne doit pas être au courant qu'il y a une attente de réinitialisation de mot de passe.

    Le token doit être imprévisible, ce qui peut être réalisé le meilleur avec un code aléatoire, la lecture de l'aléatoire de la source du système d'exploitation.

    Idée intéressante que de stocker le jeton de hachage. Cela nécessiterait un attaquant d'avoir accès à l'algorithme de hachage de la clé dans le but de générer un jeton. Merci.
    Un algorithme de hachage n'a pas besoin d'une clé, c'est une façon de l'opération, de sorte qu'il n'est pas possible d'obtenir le texte original si vous avez uniquement le hachage. Ce que vous avez probablement à l'esprit est le cryptage, c'est une opération et a besoin d'une clé.
    Vous avez raison bien sûr, l'algorithme de hachage lui-même n'utilise pas la clé, mais si vous avez un HMAC fonction, vous pouvez générer un signé de hachage avec une clé secrète. Je pensais de l'aide de l'algorithme HMAC-SHA256 tels que le PHP est hash_hmac.
    Il est également intéressant de noter que si vous utilisez cette méthode, vous devez utiliser un lent fonction de comparaison lors de la vérification du hachage afin d'éviter le moment des attaques.
    Oui, vous pouvez utiliser un HMAC mais l'avantage n'est pas très grand, important, c'est seulement qu'on ne peut pas forger un jeton résultant dans le même hash que celui stocké. Un timing d'attaque n'est pas un problème ici, car le serveur est celui de la comparaison de hachage valeurs, pas le texte brut des jetons. À partir d'un analogue de hachage de la valeur, vous ne pouvez pas tirer des conclusions au sujet de la similitude des jetons.

    OriginalL'auteur martinstoeckli

  2. 2

    Donc, il y a quelques problèmes avec cette approche que j'essayais d'échapper à mon commentaire. Lorsque vous stockez la "confirmation jeton" dans le mot de passe des utilisateurs, vous avez juste fondamentalement détruit leur mot de passe.

    J', une personne malveillante peut alors prendre un grand géant liste des adresses e-mail et un bot net et l'inondation de votre serveur avec les demandes de réinitialisation de mot de passe et verrouiller vos utilisateurs à partir de leur compte. Bien sûr, vos utilisateurs recevrez un e-mail pour le réinitialiser, mais si je peux réinitialiser les mots de passe assez vite, il peut y avoir un retard d'e-mails (ou, si vous le faites de façon synchrone, je peux probablement DoS l'ensemble de l'application).

    Je, un utilisateur normal de votre système, il peut tenter de réinitialiser mon mot de passe, et ne peut pas comprendre pourquoi je ne reçois pas le mail de réinitialisation parce que je ne sais même pas sur un dossier de spam (ou il n'est jamais arrivé). Heureusement, je viens de me rappeler que le mot de passe a été, mais il ne fonctionne plus car le mot de passe est maintenant opaque GUID, et je suis à la base morts dans l'eau jusqu'à ce que je peux trouver l'e-mail de réinitialisation.

    Voici le processus que vous devrait utilisation.

    1. Générer une demande de réinitialisation de mot de passe qui vous recherchez à l'aide d'un GUID, et vous pourriez probablement aussi obtenir ce par le malaxage de cette valeur avec certaines données privées et de passage que dans l'URL afin d'éviter une attaque rapide. Vous pouvez également verrouiller cette demande vers le bas en le faisant uniquement valable pour un certain laps de temps.
    2. Une fois que quelqu'un suit ce lien avec un jeton valide et tous les autres paramètres que vous spécifiez, ils peuvent changer le mot de passe, à quel point vous pouvez maintenant modifier le mot de passe des utilisateurs.
    3. Drapeau de la demande de mot de passe comme ayant été accomplies, ou de le supprimer. Vous pouvez également suivre les informations, comme l'adresse IP ou quelque chose de similaire si vous êtes vraiment préoccupé par qui a changé le mot de passe si vous êtes vraiment intéressé à ce sujet.
    4. Envoyer à l'utilisateur un courrier électronique confirmant qu'ils ont modifié leur mot de passe.

    Aussi, juste au cas où ce n'est pas le cas, assurez-vous que vous êtes le hachage et le salage le mot de passe des utilisateurs. Il ne sonne pas comme vous le faisiez que, lorsque vous étiez juste de remplacer le mot de passe avec un GUID, alors il suffit de double vérification.

    Le jeton n'est pas de remplacer le mot de passe utilisateur. C'est un des biens distincts de l'objet membre (member.ResetToken). Lorsque l'utilisateur clique sur le réinitialiser le mot de passe de l'url dans leur e-mail, mon site de recherche de leur compte par les ResetToken. Si le compte est à découvert, de leur montrer un mot de passe réinitialiser le formulaire. Une fois que le membre réinitialisations de mot de passe, retirez le jeton à partir de leur compte. Si ils ont essayé d'utiliser la réinitialisation du mot de passe de l'url de nouveau, il ne serait pas travailler parce que leur compte ne soit pas trouvé. Merci, désolé si ma formulation confuse.
    J'ai mis à jour ma question pour clarifier les choses.

    OriginalL'auteur Darren Kopp

  3. 1

    Utilisateurs oublie aussi de réinitialiser les mots de passe (les choses se). Être paranoïaque à propos des mots de passe, je vous suggère de limiter le lien de la durée de vie de 24 heures. Cela devrait être plus que suffisant. Ça ne résout pas le problème de malveillant intercepter, mais c'est mieux que rien.

    OriginalL'auteur Alexander L. Belikoff

  4. 1

    Je voudrais faire les suggestions suivantes:

    1. Nécessitent une information avant que l'utilisateur est autorisé à cliquer sur le lien " oublié le mot de passe bouton. Par exemple, besoin d'une adresse électronique et date de naissance.

      Idéalement votre interface utilisateur ne doit pas fournir de la rétroaction qui permet à un hacker pour déterminer si sa demande de réinitialisation a réussi. Vous ne voulez pas qu'ils l'élevage de votre page pour les adresses e-mail ou DOBs. C'est cependant une convivialité compromis, donc si vous faites cela dépend de la sécurité de combien vous avez vraiment besoin.

      Vous pouvez également en compte nécessitant un captcha qui fait la force brute et la demande les attaques DoS beaucoup plus difficile.

    2. Expire le jeton le plus rapidement possible. Quelques heures suffisent à mon avis. Vous devriez ne jamais tenir compte de messagerie privé, il n'est pas, sauf si vous utilisez une messagerie sécurisée de la technologie (par exemple, PGP) sur le protocole de base (la plupart des gens ne sont pas). La dernière chose que vous voulez est pour un marché noir pour l'ouvrir jusqu'où votre Guid sont achetés et vendus, ce qui est exactement ce qui pourrait arriver si elles ont durée de vie infinie.

    3. Ne pas utiliser de Guid. Ils ne sont pas chiffrée de manière aléatoire et sont deviner. Je vous suggère d'utiliser un chiffrement générateur de nombre aléatoire et de le traduire en base64.

    OriginalL'auteur John Wu