最好的“忘记密码”是什么？ 方法？
可能的重复：
忘记密码：什么是实现忘记密码功能的最佳方法？
我正在编写一个社区网站。
我想建立一个“忘记密码”功能。
环顾不同的网站，我发现他们采用三个选项之一：
向用户发送一封电子邮件，其中包含指向唯一的隐藏 URL 的链接，该链接允许他更改密码（Gmail 和 Amazon）
向用户发送一封包含随机生成的新密码的电子邮件 (Wordpress)
向用户发送当前密码 (www.teach12.com)
选项# 3 对用户来说似乎最方便，但由于我将密码保存为 MD5 哈希，因此我不知道如何使用选项 #3，因为 MD5 是不可逆的。 这似乎也是不安全选项，因为它意味着网站必须在某处以明文形式保存密码，并且至少明文密码通过不安全的电子邮件发送给用户。 或者我在这里遗漏了什么？
因此，如果我不能执行选项 #1，选项 #2 似乎是最简单的编程，因为我只需更改用户的密码并将其发送给他即可。 尽管这有点不安全，因为您必须通过不安全的电子邮件传递实时密码。 然而，麻烦制造者也可能会滥用这一点，通过输入随机电子邮件并不断更改各个用户的密码来纠缠用户。
选项 #1 似乎是最安全，但需要一些额外的编程来处理过期的隐藏 URL 等，但这似乎是大型网站所使用的。
您有哪些使用/编程这些不同选项的经验？ 我是否错过了任何选项？
Possible Duplicate:
Forgot Password: what is the best method of implementing a forgot password function?
I'm programming a community website.
I want to build a "forgot my password" feature.
Looking around at different sites, I've found they employ one of three options:
send the user an email with a link to a unique, hidden URL that allows him to change his password (Gmail and Amazon)
send the user an email with a new, randomly generated password (Wordpress)
send the user his current password (www.teach12.com)
Option #3 seems the most convenient to the user but since I save passwords as an MD5 hash, I don't see how option #3 would be available to me since MD5 is irreversible. This also seems to be insecure option since it means that the website must be saving the password in clear text somewhere, and at the least the clear-text password is being sent over insecure e-mail to the user. Or am I missing something here?
So if I can't do option #1, option #2 seems to be the simplest to program since I just have to change the user's password and send it to him. Although this is somewhat insecure since you have to have a live password being communicated via insecure e-mail. However, this could also be misused by trouble-makers to pester users by typing in random e-mails and constantly changing passwords of various users.
Option #1 seems to be the most secure but requires a little extra programming to deal with a hidden URL that expires etc., but it seems to be what the big sites use.
What experience have you had using/programming these various options? Are there any options I've missed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（17）
4) 将两个随机金额记入他们的银行帐户，并要求他们输入这些金额。
5) Snail 向他们邮寄一些新密码并要求他们输入。
6) 让他们用他们注册的手机发短信或拨打某个号码，然后在电话号码中输入一些值。
7) 将密码管理外包给 Stack Overflow、Facebook、博客引擎等 OpenID 提供商，以及其他正在开始做的事情，从而完全摆脱密码管理问题。
除此之外，使用选项 #1 或 #2 以及附加功能，两者都会在一小时内过期。
4) Crediting their bank account with two random amounts and ask them to enter those in.
5) Snail mail them some new password and ask them to enter it in.
6) Have them text or call some number and enter some value to a phone number with the mobile phone they registered on file.
7) Get out of the password management problem altogether by outsourcing it to OpenID providers like Stack Overflow, Facebook, blog engines, and others are starting to do.
Outside of those, use option #1 or #2 with the added feature that both expire in an hour.
我对将 #1 和 #2 描述为等效的答案的赞成票感到震惊。 他们根本不是。 向用户发送短期链接以更改其密码是最方便、最常用且最安全的方法，且不涉及带外交互（邮件、短信等）。 有几个原因：
安全问题通常会降低网站的安全性，而不是增加安全性 - 它们是另一个攻击媒介，而且通常是最薄弱的环节。 我强烈建议您阅读Web 应用程序黑客手册，了解有关此主题的精彩讨论。
I'm shocked at the upvotes on answers describing #1 and #2 as equivalent. They aren't at all. Sending the user a short term link to change their password is the most convenient, most commonly used, and most secure approach that doesn't involve an out of band interaction (mail, text msg, etc.). A few reasons:
And security questions often make a site less secure, not more - they're another attack vector and often the weakest link. I highly recommend reading The Web Application Hacker's Handbook for an excellent discussion on this topic.
请注意，选项 #2 还要求您跟踪旧密码，并在新的随机密码（例如 24 小时）内未使用时使其过期。
否则，我可能会反复向您发出新的随机密码，从而惹恼您 - 如果您不在电子邮件附近，您可能不知道为什么无法使用正常密码登录。
另外，请避免要求“身份问题”。 这些问题的答案通常比真正的密码更容易猜测/查找 - 因此每个人都可以识别自己是我。 请参阅 Sarah Palin 故事，了解最近的示例，了解这种情况是多么不安全。
Note that Option #2 also requires you to keep track of the old password and expire the new random password if it isn't used within, say 24 hours.
Otherwise I could annoy you by repeatedly issuing you a new random password -- if you are not near your email you might not know why you cannot log in with your normal password.
Also, please avoid requiring an "identification question". The answers to these questions are typically much easier to guess/lookup than real passwords -- so everybody can identify themselves as me. See the Sarah Palin story for a recent example of how insecure this is.
选项 1 和 2 彼此不安全。
那里。 我说了。 如果用户的电子邮件帐户被泄露，则没有合理的安全方法可以做到这一点，除非您收集更多的私人数据，例如他们的地址、母亲的婚前姓名 - 所有这些都可以被猜测。
我见过的最好的（尽管最烦人的）版本是你需要记住一个秘密问题和一个秘密答案。 这意味着用户必须记住他们问的是哪个问题，当然，这也总是可能被忘记！
如果他们忘记了这个问题，而你是一家“真正的”公司，那么总是可以选择通过帖子向用户发送令牌，并附有如何重置所有安全性的说明……黑客不太可能获得访问权限到他们现实生活中的邮件。
一个偏差是在用户创建帐户时收集电话号码。 如果存在这种情况并且他们不记得自己的任何详细信息，您可以设置某种自动呼叫系统来告诉他们如何重置其详细信息。
关于#2 需要提及的一件事是：不要让该进程覆盖当前帐户密码。 如果发生这种情况，任何人都可以说他们忘记了任何帐户的密码，从而引发大量不必要的密码更改。
Options 1 and 2 as insecure as each other.
There. I said it. If the user's email account has been breached, there's no reasonable secure way to do things unless you collect more private data like their address, mother's maiden name - all of which can be guessed.
The best (albeit most annoying) version I have seen is where you need to remember a secret question and a secret answer. It means the user has to remember which question they asked, which, of course, can always be forgotten too!
If they forget the question and you're a "real" company, there's always the option of sending the user a token through the post, with instructions on how to reset all their security... It's very unlikely that a hacker will have access to their real life mail.
A skew on that would be to collect a telephone number when the user created the account. If that existed and they couldn't remember any of their details, you could set up some sort of automated calling system that told them how to reset their details.
And one thing to mention about #2: Don't let the process overwrite the current account password. If that happened anybody could say they forgot any account's password, triggering lots of unwanted password changes.
选项 1 或 2 的安全性没有真正的区别。选项 1 实际上与在表单中预加载新密码相同。
事实上，随着网络钓鱼攻击的盛行，人们可能会争辩说，鼓励使用带有长 URL 的选项 1 可能会降低人们对点击长而神秘的 URL 的警惕性。
There's no real difference between the security of option 1 or 2. Option 1 is effectively the same as preloading the new password in the form.
In fact, with the prevalence of phishing attacks, one could argue that encouraging use of option 1 with long URLs could make people less alert about clicking on long mysterious URLs.
阅读 OWASP 前十名，确保您的方法符合要求。
这里是直接链接。
Read the OWASP top ten to make sure your method is compliant.
Here is the direct link.
只是简单说明一下与您的问题无关的事情。 您提到您使用 MD5 来散列存储的密码。 无论您选择使用选项 1 还是选项 2（出于显而易见的原因，选项 3 将是最不安全的），MD5 是一种破解的哈希算法，实际上可以使黑客相当容易地访问受受保护的帐户。 MD5 哈希。
您可以通过以下 URL 阅读有关该漏洞的更多信息：en.wikipedia.org/wiki/MD5
更好的散列解决方案是 SHA，它仍然是一种稳定且安全的散列算法。 结合选项 #1 或 #2，您应该有一个相当安全的系统来保护您的用户密码，除了最坚定的黑客之外，其他人都无法使用。
Just a quick note on something not specifically in regards to your question. You mentioned you used MD5 to hash stored passwords. Regardless of whether you choose to use Options 1 or 2 (3 is going to be the least secure as, for obvious reasons), MD5 is a cracked hashing algorithm, and can actually make it fairly easy for hackers to gain access to accounts protected by MD5 hashing.
You can read more about the vulnerability it at the following URL: en.wikipedia.org/wiki/MD5
A better hashing solution would be something like SHA, which is still a stable and secure hashing algorithm. Combined with option #1 or #2, you should have a reasonably secure system in place to protect your users passwords, barring all but the most determined hackers.
选项#1 可能是最好的。 #3 不安全（我还建议使用比 MD5 更强的东西，例如 SHA1）。 选项 #2 不好，因为它允许任何随机的人将您锁定在您的帐户之外，直到您检查电子邮件为止，除非您使用安全问题。 而且安全问题通常比密码更容易破解。
Option #1 is probably the best. #3 is insecure (and I also suggest using something stronger than MD5, such as SHA1). Option #2 is not good because it allows any random person to lock you out of your account until you check your email, unless you use a security question. And security questions are often easier to crack than passwords.
选项 #1 比选项 #2 有几个主要优点。 如果随机用户在“我忘记了密码”框中输入我的电子邮件地址，则我的密码将不会被重置。 此外，它更安全一些，因为您的 Gmail 收件箱中不会永远存储该网站密码的永久记录。
这里缺少的一个关键部分是，您在 #1 中提供的链接只能用于一次密码重置，并且有时间限制
所有这些解决方案意味着您将电子邮件收件箱视为“一环”这统治着他们所有人。 无论如何，现在大多数在线服务似乎都在这样做。
我首选的方法是尽可能使用 openid。 密码管理是地狱，似乎没有人能完全正确。 把这个问题交给别人会更容易。
Option #1 has a couple of major advantages over #2. If a random user types in my email address into the "I have forgotten my password" box, then my password will not be reset. Also, it is slightly more secure in that there is no permanent record of the site's password stored in your gmail inbox forever.
A critical missing piece here is that the link you provide in #1 should only work for one password reset and have a time limit
All these solutions mean that you are treating your email inbox as the "one ring" that rules them all. Most online services seem to be doing this now days anyway.
My preferred approach is to go with openid where possible. Password management is hell that no one seems to get quite right. It's easier to hand this problem to someone else.
选项 4：要求用户通过输入帐户名和电子邮件地址来重置密码。 只要您不在网站上透露真实姓名或电子邮件地址（在当今时代您为什么要这样做？），这就是一种相当安全且防篡改的方法。 发送重置页面的链接，而不是密码本身。
选项 5：使用 OpenID 并将责任交给第三方来处理。
老实说，这比大多数网站所需的工作量要多得多。 我喜欢通过电子邮件接收明文密码，因为我将它们存储在收件箱的“注册”文件夹中。 这样，当我忘记网站密码时，我可以查找它们（这种情况经常发生！）。 如果有人正在阅读我的电子邮件，那么我比使用我的 Twitter 帐户（如果我有的话）的人要担心的问题更大。 当然，银行和企业有更严格的要求，但您没有指定您的网站是什么。 这是最佳答案的关键。
Option 4: Require user to reset password by entering their account name AND email address. As long as you aren't disclosing real names or email addresses on the site (WHY would you in this day and age?) this is a reasonably secure and tamper-proof method. Send a link to a reset page, not the password itself.
Option 5: Use OpenID and pass the responsibility to a 3rd-party to worry about it.
Honestly though this is a lot more effort than most sites require. I for one LIKE receiving plaintext passwords by email because I store them in a "registrations" folder in my inbox. That way I can lookup passwords for sites when I forget them (which happens a lot!). If somebody is reading my email I have bigger problems to worry about than people using my twitter account (if I had one). Of course banks and corporations have stronger requirements but you didn't specify what your site is. That's the key to the best answer.
我同意你关于选项 #3 不安全的评论。
至于编程 #1 或 #2，选项 #2 更容易编程，但选项 #1 并不难，并且两者可能彼此一样安全。
无论您选择哪个选项，您还可以考虑将个人信息请求（您在注册过程中获得）作为忘记密码过程的一部分，以使其更加安全。
我已经对系统进行了编程，您有一个用户名，要获得新密码，您必须输入您的用户名和电子邮件地址。 您可能会收到有关您的用户名的提醒，但主要的一点是，有人可能无法猜出您的用户名和电子邮件，但如果您仅通过电子邮件进行操作，安全性就会降低。
秘密问题是针对个人信息部分的一种方法。 我个人认为它们并没有提供太多价值，因为人们倾向于选择很多人都知道答案、能够猜测或能够找到答案的问题。 不过，只要将它与已经相对安全的方法结合使用，总比没有好。
显然，你做的事情越多，编程工作就越多。
最简单的方法是：
I agree with your comments about option #3 being insecure.
As for programming either #1 or #2, option #2 is easier to program but #1 isn't much harder and both are probably about as secure as each other.
Whichever option you choose, you can also consider making it more secure by including requests for personal information (that you obtain during registration) as part of the forgotten password process.
I've programmed systems where you have a username and to get a new password you have to enter both your username and your email address. You can get sent a reminder of your username but the main point is that someone probably won't be able to guess your username and your email but if you do it just on email, there's less secure.
Secret questions are an approach to the personal information part. I personally think they don't offer a lot of value as people tend to choose questions that many people will either know the answer to, be able to guess or be able to find out. It is better than nothing however so long as you use it in conjunction with an already relatively secure method.
Obviously the more of this you do, the more programming work it is.
The simplest method is:
选项 1 或 2 都可以。 正如您所说，选项 3 不安全，因为您需要存储明文密码。 您可能会喜欢并使用可逆加密算法来存储/检索密码，但是如果您有更好的替代方案，就没有理由走这条路。
Either option 1 or 2 would be fine. As you said, option 3 is insecure as you would need to store the clear text password. You could probably get fancy and use a reversible encryption algorithm to store/retrieve the password, but with better alternatives available to you there's no reason to go down that road.
还有一个附加选项，您可以与您提到的任何选项结合使用：
您可以让用户为其密码编写提醒，当他们忘记密码时，您将其作为第一步发送给他们。 如果提醒对用户没有帮助，您可以继续下一个选项。
由于提醒不是密码本身，因此可以安全地通过邮件发送（甚至可能直接显示在页面上）。
There is an additional option that you can use in combination with any of the options that you mention:
You can let the user write a reminder for their password, that you send to them as the first step when they have forgotten the password. If the reminder doesn't help the user, you can go on to the next option.
As the reminder isn't the password itself, it's safe to send by mail (or perhaps even display directly on the page).
如果你对它们进行散列，则选项 3 不可用，如果你不对它们进行散列，那你就太丢脸了。 :)
我更喜欢选项 1，将重置密码链接发送到他们的电子邮件，允许他们（在有限的时间内）重置密码。 它确实需要更多的工作，但对他们来说很容易使用，并且最终与他们的电子邮件登录过程一样安全。
If you are hashing them Option 3 is unavailable and if you are not hashing them, shame on you. :)
I prefer option 1, sending a reset password link sent to their email which allows them (for a limited time) to reset their password. It does require more work, but it's easy for them to use and ultimately as secure as their email login process.
您可以混合使用 #1 和 #2，充分利用两者的优点：
向用户发送一封电子邮件，其中包含指向唯一的隐藏 URL 的链接，该 URL 允许用户更改新的随机生成的密码。
该页面可能是 SSL，密码可能会在 12-24 小时内过期。
You could made a mix between #1 and #2, taking advantages from both:
Send the user an email with a link to a unique, hidden URL that allows him to change a new randomly generated password.
That page could be SSL, and the password could expire in 12-24 hours.
我尝试了几种我不太满意的方法。 我为下一个项目确定的是：
I've tried a couple of methods that I've not really been happy with. What I've settled on for the next project is to:
指示用户亲自前往您的办公室并使用身份证或护照证明其身份。
当然，这是假设您的办公室靠近您的用户，并且该帐户的价值足以证明此过程的合理性。 适用于银行等。
Instruct the user come personally to your offices and prove her identity with id card or passport.
This, of course, assumes that you have offices near your users and that the account are valuable enough to justify this procedure. Suitable for example banks.