Mettre en œuvre la meilleure pratique de récupération de mot de passe
Je souhaite implémenter la récupération de mot de passe dans mon application Web.
J'aimerais éviter d'utiliser des questions secrètes.
Je pourrais juste envoyer le mot de passe par e-mail mais je pense que ce serait risqué.
Je pourrais peut-être générer un nouveau mot de passe aléatoire temporaire et l'envoyer par courrier électronique, mais je pense que c'est aussi risqué que le point ci-dessus.
Puis-je envoyer une URL par courrier électronique, par exemple http://example.com/token=xxxx Où xxxx est un jeton aléatoire associé à l'utilisateur. Ainsi, lorsque l'utilisateur accède à cette URL, il peut réinitialiser le mot de passe.
Tout d’abord, faites pas stockez une copie en texte brut du mot de passe de l’utilisateur, ou même une version chiffrée. Vous souhaitez uniquement conserver une copie hachée du mot de passe de l'utilisateur.
En ce qui concerne les solutions de récupération, je trouve que le lien de récupération permettant de modifier le mot de passe de l'utilisateur est la meilleure solution de mon expérience. Ce sera probablement un peu plus pratique pour l'utilisateur, tout en étant, en termes de sécurité, sensiblement identique à celui d'envoyer un nouveau mot de passe aléatoire à changer après la prochaine connexion. Je recommanderais quand même que l'URL de récupération expire après une courte période de temps, et ne soit utilisable qu'une seule fois.
Lorsque j'étais dans l'armée de l'air, la règle de sécurité que nous avions était la suivante: lors de la définition ou de la réinitialisation des mots de passe, n'envoyez pas l'identifiant de l'utilisateur et le mot de passe dans le même courrier électronique. Ainsi, si quelqu'un intercepte des courriers électroniques recherchant des mots de passe, il doit réussir à intercepter les DEUX courriers électroniques et être en mesure de les connecter, de manière à violer la sécurité.
J'ai vu beaucoup de sites qui utilisent le "allez à cette URL pour réinitialiser votre mot de passe". Peut-être me manque quelque chose - je ne prétends pas être un expert en sécurité - mais je ne vois pas en quoi cela est plus sûr que de simplement inventer un nouveau mot de passe temporaire et de l'envoyer. Si un pirate informatique intercepte le courrier électronique, pourquoi ne peut-il pas accéder à ce lien et voir le nouveau mot de passe aussi bien que l'utilisateur légitime le pourrait? Cela me semble être un problème supplémentaire pour l'utilisateur, sans aucun gain de sécurité.
À propos, félicitations de ne pas utiliser les questions de sécurité. La logique de cet appareil m'échappe. Depuis l'aube de la sécurité informatique, nous disons aux gens: "NE PAS créer de mot de passe informant sur vous-même qu'un pirate informatique pourrait découvrir ou deviner, comme le nom de votre lycée ou votre couleur préférée. Un pirate informatique pourrait peut-être pour rechercher le nom de votre lycée, ou même s’ils ne vous connaissent pas ou ne savent rien de vous, si vous habitez toujours près de l’école où vous êtes allé à l’école, ils pourront le faire en essayant les écoles locales jusqu’à ce qu’ils le touchent un petit nombre de couleurs probablement préférées afin qu'un pirate informatique puisse le deviner. Etc. Au lieu de cela, un mot de passe devrait être une combinaison insignifiante de lettres, de chiffres et de ponctuation. " Mais maintenant, nous leur disons aussi: "Mais si vous avez du mal à vous souvenir de cette combinaison insignifiante de lettres, de chiffres et de ponctuation, pas de problème! Prenez des informations sur vous que vous pouvez facilement vous rappeler - comme le nom de votre lycée. ou votre couleur préférée - et vous pouvez l’utiliser comme réponse à une «question de sécurité», c’est-à-dire comme mot de passe alternatif. "
En effet, les questions de sécurité rendent le piratage encore plus facile que si vous veniez de choisir un mauvais mot de passe. Au moins, si vous utilisiez simplement une information personnelle comme mot de passe, un pirate informatique ne saurait nécessairement savoir quelle information personnelle vous avez utilisée. Avez-vous utilisé le nom de votre chien? Ta date de naissance? Votre saveur de glace préférée? Il devrait tous les essayer. Mais avec les questions de sécurité, nous disons au pirate quelles informations personnelles vous avez utilisées comme mot de passe!
Au lieu d'utiliser des questions de sécurité, pourquoi ne pas simplement dire: "Si vous oubliez votre mot de passe, celui-ci est affiché en bas de l'écran. Si vous essayez de pirater le compte de quelqu'un d'autre, il vous est absolument interdit de défilement vers le bas." Ce ne serait que légèrement moins sécurisé.
De peur que vous ne vous demandiez, lorsque des sites me demandent la ville où je suis né ou le fabricant de ma première voiture, je ne réponds pas à la question. Je donne un mot de passe sans signification.
</ rant>
Difficile de dire ce que vous devriez faire, car pratiquement toute solution à ce problème affaiblira la sécurité. À moins que vous ne souhaitiez peut-être envisager d’envoyer un SMS, une vérification de rappel, des générateurs de mot de passe à utilisation unique, ou d’autres systèmes du même type qui prennent la récupération de mot de passe sur un autre support.
Cependant, ce que vous ne devriez pas faire:
Envoyez le mot de passe - car après tout, comme on l'a déjà mentionné, vous ne l'avez pas.
Générez un nouveau mot de passe temporaire - non seulement cela est aussi peu sûr que l'envoi du mot de passe, mais vous avez également la possibilité d'une attaque par déni de service. Je peux aller sur le site, prétendre être vous-même, demander un nouveau mot de passe, puis (si vous n'avez pas vérifié votre email), vous ne pouvez pas vous connecter, vous ne savez pas pourquoi et devez demander un nouveau mot de passe. .
Le jeton est probablement la voie à suivre. Le recevoir signale une demande de mot de passe oublié, mais ne prend aucune mesure à moins que vous ne le confirmiez. Vous en feriez également un jeton ponctuel avec un délai d'expiration relativement court pour limiter les risques.
Bien sûr, beaucoup dépend de l'application. Évidemment, protéger les informations financières et autres informations sensibles est plus essentiel que d'empêcher votre compte d'être piraté sur mytwitteringfacetube.com, car s'il est gênant, si quelqu'un veut voler l'identité de quelqu'un sur un site de réseau social, il lui suffit d'ouvrir son propre compte et de se faire passer pour une personne volée. l'information quand même.
De toute évidence, vous ne pouvez pas envoyer le mot de passe original par courrier électronique, car vous ne le stockez pas (non?!). L'envoi d'un mot de passe temporaire (qui doit être modifié, car cela ne fonctionne que pour une seule connexion), ainsi qu'un lien pour réinitialiser le mot de passe sont équivalents du point de vue de la sécurité.
Je ne comprends pas l’attitude envers la méthode de la question secrète. Ce n'est pas comme si je vais faire mon mot de passe "BlueHouse" puis poser ma question de sécurité "Quelles sont tes deux choses préférées?" et la réponse "Bleu et Maisons". La question de sécurité n'est pas la clé magique pour obtenir le mot de passe actuel. C'est généralement un moyen d'obtenir un nouveau mot de passe envoyé à l'adresse e-mail enregistrée. Je ne sais pas comment vous le faites autrement, mais on dirait que vous faites l'une des deux choses.
1) L'utilisateur clique sur le bouton "J'ai oublié mon mot de passe" et le nouveau mot de passe est envoyé à l'utilisateur.
2) L'utilisateur clique sur le bouton "J'ai oublié mon mot de passe", puis doit répondre à une question de sécurité avant de recevoir le nouveau mot de passe par courrier électronique à l'adresse indiquée.
Il me semble que l'option numéro 2 est plus sécurisée.
Pourquoi l'envoi d'un jeton est-il plus sécurisé que l'envoi du mot de passe? Si un compte de messagerie a été piraté, il l'a été. Peu importe s'il existe un lien pour réinitialiser le mot de passe, un jeton ou un nouveau mot de passe. N'oubliez pas que la plupart des sites ne disent pas "Le nouveau mot de passe a été envoyé à l'adresse de messagerie suivante pour que vous puissiez le pirater". Un pirate informatique aurait besoin de deviner l'adresse e-mail à pirater.
Je suis d'accord avec Andy. Les questions de sécurité ne sont-elles pas normalement indépendantes du mot de passe? (Les miens sont) Cela signifie qu'ils ont une question et une réponse et qu'ils ne sont pas liés au mot de passe. Il semble que cela soit utilisé pour empêcher les demandes de réinitialisation de mot de passe illicites et ait effectivement une utilité.
Imaginez - quelqu'un pourrait accéder à l'utilitaire de "mot de passe oublié" d'un site et entrer un zillion d'adresses électroniques - ou simplement une personne qu'il/elle voudrait ennuyer. Si le mot de passe est réinitialisé à ce moment-là, les personnes appartenant à ces adresses de messagerie devront alors noter dans leur adresse e-mail le mot de passe réinitialisé et se connecter au site avec le mot de passe de réinitialisation lors de leur prochaine visite. Avec la question de la sécurité, ce n'est pas aussi facile à faire.
Je vois que Amazon envoie un lien vers l'e-mail donné. Ils vous demandent également de saisir un captcha pour empêcher les attaques par DOS. Comme il s’agit d’un lien, j’imagine que cela signifie qu’ils n’ont pas réinitialisé le mot de passe immédiatement et qu’il le serait dès que l’utilisateur clique sur le lien. Avec le scénario ci-dessus, l’utilisateur verrait simplement le courrier électronique et noterait que «non, je ne le faisais pas», et se contentait de ne pas avoir à changer son mot de passe inutilement. Une question de sécurité aurait pu empêcher la tentative au début et permettre à l'utilisateur légitime de recevoir le courrier électronique en premier lieu.
Voici un livre blanc à ce sujet: http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html
Celui-ci recommande en fait des questions secrètes comme une partie importante du processus d'authentification. Et l'envoi d'un code d'authentification par courrier électronique et sa demande constituent simplement une couche supplémentaire que vous pouvez éventuellement inclure.
Cela dépend vraiment du niveau de sécurité que vous souhaitez avoir. L’un des extrêmes est un processus de réinitialisation de mot de passe qui implique de contacter et de certifier que vous êtes bien ce que vous prétendez être, par exemple. via id, car votre boîte aux lettres pourrait également être compromise. En fait, comme les gens ont tendance à utiliser le même mot de passe partout, cela est très probable. À l’autre extrémité, il existe une approche standard consistant simplement à envoyer un courrier électronique avec un nouveau mot de passe aléatoire.
Les questions et réponses "secrètes" ne sont qu’une autre forme de nom d’utilisateur et de mots de passe, avec le défaut fatal qu’elles sont en général incroyablement faciles à deviner, si bonnes que vous ne voulez pas les utiliser.
En ce qui concerne le jeton, je ne pense pas que cela fasse une grande différence en termes de sécurité globale. Que vous envoyiez un jeton permettant à un utilisateur de changer le mot de passe ou que vous envoyiez immédiatement un mot de passe aléatoire ne fait pas une grande différence.
Assurez-vous simplement que le jeton ne peut être utilisé qu'une seule fois et de préférence uniquement dans un laps de temps limité, par exemple. + 24h après la demande.
Et, comme le soulignaient les réponses précédentes, ne stockez JAMAIS les mots de passe en clair. Hachez-les. Ajoutez de préférence sel .
Voici comment je l'ai résolu:
J'ai ajouté des champs retrieve_token et retrieve_expiration à ma table 'utilisateurs'.
L'utilisateur demande une réinitialisation du mot de passe en fournissant son adresse e-mail et en remplissant le champ captcha. Une valeur hachée aléatoire est générée pour leur champ retrieve_token - c'est-à-dire md5($user_id.time()), alors que retrieve_expiration sera défini sur une date/heure qui expirera dans les 45 prochaines minutes. Un email est envoyé à l'utilisateur avec un lien:
https://example.com/reset-password?retrieve_token=912ec803b2ce49e4a541068d495ab570
SSL devrait être obligatoire lorsque l'authentification est requise. Vous pouvez également ajouter une table pour la journalisation des demandes de réinitialisation, qui stocke le courrier électronique et l'adresse IP. Cela vous aidera à détecter d'éventuelles attaques brutales et vous pourrez bloquer l'adresse IP de l'attaquant si nécessaire.
Vous pouvez implémenter une question de sécurité pour demander la réinitialisation du mot de passe, mais j'estime que le captcha suffirait à décourager quiconque de répéter la demande plusieurs fois.
@Geai. La raison pour laquelle vous accédez à une URL pour réinitialiser votre mot de passe au lieu d'envoyer simplement un nouveau mot de passe temporaire à quelqu'un est plus qu'une simple sécurité. Sans quelque chose comme une URL avec un jeton, une personne pourrait réinitialiser le mot de passe d'une autre personne. Il n'est pas nécessaire d'avoir accès au courrier électronique. Si quelqu'un avait un problème à régler avec quelqu'un, il pourrait simplement continuer à lancer une nouvelle réinitialisation du mot de passe. Ensuite, la cible pauvre doit se connecter et changer le mot de passe encore et encore.
En envoyant un jeton, le mot de passe de l'utilisateur ne change pas jusqu'à ce qu'il se connecte avec et le confirme. Le spam des emails de réinitialisation peut être ignoré. Les jetons sont tout aussi faciles (sinon plus faciles) à générer en tant que nouveau mot de passe à l'aide d'un GUID, ce n'est pas vraiment compliqué pour le développeur.
De plus, comme le GUID est unique (un mot de passe généré peut ne pas l'être), un jeton peut être lié à un nom d'utilisateur. Si le nom d'utilisateur incorrect est indiqué sur l'URL, le jeton peut être annulé (c'est-à-dire lorsqu'une personne différente l'initie et que quelqu'un l'intercepte .. en supposant que le nom d'utilisateur n'est pas le même que l'e-mail).
@Geai. L'utilisation correcte des questions de sécurité consiste à lancer un courrier électronique de réinitialisation de mot de passe, et non à réinitialiser le mot de passe. Sans un mécanisme tel qu'une question de sécurité, on pourrait initier une réinitialisation du mot de passe. Bien que cela semble apparemment être le cas, l'envoi d'un courrier électronique de réinitialisation pourrait être envoyé à un courrier électronique qui n'appartiendrait peut-être plus au propriétaire d'origine. Ce n'est pas rare. Par exemple, lorsque des employés quittent une entreprise, ces courriers sont souvent envoyés à un autre employé. Une question de sécurité ajoute un faible niveau d'obstruction à ce scénario. Cela réduit également les problèmes dans lesquels une personne continue à lancer une réinitialisation de mot de passe sur le mauvais compte, ce qui entraîne la spammation involontaire d'un mauvais fichier. Les questions de sécurité ne sont vraiment pas censées être véritablement sécurisées, elles visent simplement à réduire les scénarios tels que ceux-là. Quiconque utilise une question de sécurité pour réinitialiser le mot de passe le fait mal.
Voici un exemple de la façon dont quelqu'un l'a fait avec Node.js, générez un jeton aléatoire, une heure d'expiration, envoyez le lien avec le jeton attaché, utilisez un itinéraire reset/:token qui garantit qu'un utilisateur existe avec ce jeton (qui n'est pas non plus expiré). ) et, si tel est le cas, redirigez-le vers une page de réinitialisation du mot de passe.
http://sahatyalkabov.com/how-to-implement-password-reset-in-nodejs/
Concernant la question/réponse de sécurité. En tant qu'utilisateur de sites Web, je ne les utilise pas personnellement (j'y mets des ordures). Mais ils ne sont certainement pas inutiles ou dénués de sens, comme certains le disent ici.
Considérez cette situation: Un utilisateur de votre site a quitté son bureau pour déjeuner et n'a pas verrouillé son poste de travail. Un utilisateur néfaste peut maintenant visiter la page de récupération/réinitialisation du mot de passe et entrer son nom d'utilisateur. Le système enverra ensuite par courrier électronique le mot de passe récupéré/réinitialisé sans demander la réponse de sécurité.