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)
向用户发送一封电子邮件,其中包含指向唯一隐藏网址的链接,该网址允许他更改密码(Gmail和亚马逊)
-
send the user an email with a new, randomly generated password (Wordpress)
向用户发送一封包含新的随机生成密码的电子邮件(Wordpress)
-
send the user his current password (www.teach12.com)
向用户发送他当前的密码(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?
选项#3似乎对用户来说最方便,但由于我将密码保存为MD5哈希,我不知道选项#3是如何可用的,因为MD5是不可逆的。这似乎也是一种不安全的选择,因为它意味着网站必须在某处以明文形式保存密码,并且至少明文密码是通过不安全的电子邮件发送给用户的。或者我在这里遗漏了什么?
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.
因此,如果我不能做选项#1,选项#2似乎是最简单的编程,因为我只需要更改用户的密码并将其发送给他。虽然这有点不安全,因为您必须通过不安全的电子邮件传递实时密码。然而,这也可能被麻烦制造者误用,通过输入随机电子邮件和不断更改各种用户的密码来纠缠用户。
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.
选项#1似乎是最安全的,但需要一些额外的编程来处理过期的隐藏URL等,但它似乎是大型网站使用的。
What experience have you had using/programming these various options? Are there any options I've missed?
您使用/编程这些不同选项有什么经验?有没有我错过的选择?
17 个解决方案
#1
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.
4)用两个随机金额贷记他们的银行账户并要求他们输入.5)蜗牛给他们发一些新密码并要求他们输入.6)让他们发短信或拨打一些电话并输入一些价值给手机他们在手机上注册的手机号码。 7)通过外包给Stack Overflow,Facebook,博客引擎等OpenID提供商,完全摆脱密码管理问题。
Outside of those, use option #1 or #2 with the added feature that both expire in an hour.
除此之外,使用选项#1或#2添加的功能都会在一小时后到期。
#2
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:
对于描述#1和#2等同的答案,我感到震惊。它们根本不存在。向用户发送短期链接以更改其密码是最方便,最常用且最安全的方法,不涉及带外交互(邮件,文本消息等)。原因如下:
- Setting a temporary password via a forgot password link allows users to effectively change a user's password and lock a user out of their account if they know the user's login. With a link, the user simply knows someone is messing around and their access isn't impacted.
- The password reset link is only valid for a short period, so there's a very small window for an attacker to strike. And even if they did, the user would know because the reset link would no longer work if the attacker intercepted the link and used it to change the password. If the new assigned password isn't changed by the user immediately, the attacker who intercepted the password can quietly impersonate the user indefinitely. So the big difference is, while a hacker can intercept the reset password link email, if they use the link to change the user's password, the user will know something is wrong because the link won't work and they'll generate another password reset request.
- Easier to use - the user simply clicks a link in their email rather than typing a new random password you've generated.
通过忘记密码链接设置临时密码允许用户有效地更改用户密码,并在用户知道用户登录时将其锁定在帐户之外。通过链接,用户只需知道有人在乱搞,他们的访问不会受到影响。
密码重置链接仅在短时间内有效,因此攻击者可以使用非常小的窗口进行攻击。即使他们这样做,用户也会知道,因为如果攻击者拦截了链接并使用它来更改密码,则重置链接将不再起作用。如果用户未立即更改新分配的密码,则截获密码的攻击者可以无限期地悄悄地冒充用户。所以最大的区别是,虽然黑客可以拦截重置密码链接电子邮件,如果他们使用该链接更改用户密码,用户将知道某些错误,因为链接将无法正常工作,他们将生成另一个密码重置请求。
易于使用 - 用户只需单击其电子邮件中的链接,而不是键入您生成的新随机密码。
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.
安全问题通常会使网站安全性降低,而不是更多 - 它们是另一种攻击媒介,通常是最薄弱的环节。我强烈建议您阅读Web应用程序黑客手册,以便对此主题进行精彩讨论。
#3
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.
请注意,选项#2还要求您跟踪旧密码,如果未在24小时内使用,则使新随机密码失效。
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.
此外,请避免要求“识别问题”。这些问题的答案通常比真实密码更容易猜测/查找 - 所以每个人都可以将自己标识为我。请参阅Sarah Palin的故事,了解最近的例子,了解这是多么不安全。
#4
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.
有一点需要提及#2:不要让进程覆盖当前帐户密码。如果发生这种情况,任何人都可以说他们忘记了任何帐户的密码,从而触发了大量不必要的密码更改。
#5
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.
选项1或2的安全性没有实际区别。选项1实际上与在表单中预加载新密码相同。
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.
事实上,随着网络钓鱼攻击的普遍存在,人们可能会争辩说,鼓励使用带有长URL的选项1可能会让人们对点击长神秘网址不那么警觉。
#6
Read the OWASP top ten to make sure your method is compliant.
阅读OWASP前十名以确保您的方法符合要求。
Here is the direct link.
这是直接链接。
#7
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.
只是快速说明一些与您的问题无关的内容。您提到您使用MD5来哈希存储的密码。无论您选择使用选项1还是2(由于显而易见的原因,3都是最不安全的),MD5是一种破解哈希算法,实际上可以让黑客很容易获得受保护的帐户的访问权限。 MD5哈希。
You can read more about the vulnerability it at the following URL: en.wikipedia.org/wiki/MD5
您可以通过以下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.
更好的散列解决方案就像SHA一样,它仍然是一种稳定而安全的散列算法。结合选项#1或#2,您应该拥有一个合理安全的系统来保护您的用户密码,除了最坚定的黑客之外的所有人。
#8
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可能是最好的。 #3是不安全的(我还建议使用比MD5更强大的东西,比如SHA1)。选项#2不好,因为它允许任何随机的人在您检查电子邮件之前将您锁定在帐户之外,除非您使用安全问题。安全问题通常比密码更容易破解。
#9
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.
与#2相比,选项#1有几个主要优点。如果随机用户在我的电子邮件地址中输入“我忘记了密码”框,则我的密码将不会被重置。此外,它更安全一点,因为永远不会永久记录存储在您的Gmail邮箱中的网站密码。
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
这里一个关键缺失的部分是你在#1中提供的链接应该仅适用于一次密码重置并且有时间限制
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.
我首选的方法是尽可能使用openid。密码管理是没有人似乎完全正确的地狱。将此问题交给其他人更容易。
#10
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.
选项4:要求用户通过输入其帐户名和电子邮件地址来重置密码。只要您没有在网站上披露真实姓名或电子邮件地址(您为什么在这个时代?),这是一种相当安全且防篡改的方法。发送重置页面的链接,而不是密码本身。
Option 5: Use OpenID and pass the responsibility to a 3rd-party to worry about it.
选项5:使用OpenID并将责任转交给第三方以担心它。
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.
老实说,尽管这比大多数网站要求的要多得多。我一个人通过电子邮件收到明文密码,因为我将它们存储在收件箱的“注册”文件夹中。这样,当我忘记它们时,我可以查找网站的密码(这种情况发生了很多!)。如果有人在阅读我的电子邮件,我担心的问题比使用我的推特账号的人要多(如果我有的话)。当然,银行和公司有更强的要求,但您没有指定您的网站是什么。这是最佳答案的关键。
#11
I agree with your comments about option #3 being insecure.
我同意你对选项#3不安全的评论。
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.
至于编程#1或#2,选项#2更容易编程,但#1并不难,并且两者都可能彼此安全。
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:
最简单的方法是:
- Have a "remind me of my username" link (enter email). Don't tell the user if an email was sent or not because people can use that to find out if an email address is of a member. Always tell the user to check their inbox for the reminder email but only send it if someone is a member; and
- Require both username and email to get sent a new one-time password. That password should only last an hour or so. When the user uses it, they should be forced to change their password immediately.
有一个“提醒我我的用户名”链接(输入电子邮件)。不要告诉用户是否发送了电子邮件,因为人们可以使用它来查明电子邮件地址是否属于成员。始终告诉用户在收件箱中查看提醒邮件,但只有在有人成为会员时才发送;和
需要用户名和电子邮件才能收到新的一次性密码。该密码应该只持续一个小时左右。当用户使用它时,应该强制他们立即更改密码。
#12
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.
选项1或2都可以。正如您所说,选项3是不安全的,因为您需要存储明文密码。您可能会喜欢并使用可逆加密算法来存储/检索密码,但是有更好的替代方案可供您使用,没有理由走这条路。
#13
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).
由于提醒不是密码本身,因此可以通过邮件发送(或者甚至可以直接在页面上显示)。
#14
If you are hashing them Option 3 is unavailable and if you are not hashing them, shame on you. :)
如果你正在哈希它们,那么选项3是不可用的,如果你没有哈希,那么你就会感到羞耻。 :)
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,发送重置密码链接发送到他们的电子邮件,允许他们(在有限的时间内)重置他们的密码。它确实需要更多工作,但它们很容易使用,并且最终与其电子邮件登录过程一样安全。
#15
You could made a mix between #1 and #2, taking advantages from both:
您可以在#1和#2之间进行混合,从以下两方面获益:
Send the user an email with a link to a unique, hidden URL that allows him to change a new randomly generated password.
向用户发送一封电子邮件,其中包含指向唯一隐藏URL的链接,该URL允许他更改新随机生成的密码。
That page could be SSL, and the password could expire in 12-24 hours.
该页面可能是SSL,密码可能会在12-24小时后过期。
#16
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:
我尝试了几种我并不满意的方法。我为下一个项目所做的就是:
- User enters username and email address
- Email sent with link containing url and guid param which has been stored in db with 48 hour expiry
- User confirms password to be reset
- New password is emailed to user
- Login with new password displays message or redirects to change password page.
用户输入用户名和电子邮件地址
通过包含url和guid param的链接发送的电子邮件,该链接已存储在db中,有效期为48小时
用户确认要重置的密码
新密码通过电子邮件发送给用户
使用新密码登录会显示消息或重定向以更改密码页面。
#17
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.
当然,这假设您的用户附近有办公室,并且该帐户的价值足以证明此过程的合理性。适用于例如银行。
#1
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.
4)用两个随机金额贷记他们的银行账户并要求他们输入.5)蜗牛给他们发一些新密码并要求他们输入.6)让他们发短信或拨打一些电话并输入一些价值给手机他们在手机上注册的手机号码。 7)通过外包给Stack Overflow,Facebook,博客引擎等OpenID提供商,完全摆脱密码管理问题。
Outside of those, use option #1 or #2 with the added feature that both expire in an hour.
除此之外,使用选项#1或#2添加的功能都会在一小时后到期。
#2
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:
对于描述#1和#2等同的答案,我感到震惊。它们根本不存在。向用户发送短期链接以更改其密码是最方便,最常用且最安全的方法,不涉及带外交互(邮件,文本消息等)。原因如下:
- Setting a temporary password via a forgot password link allows users to effectively change a user's password and lock a user out of their account if they know the user's login. With a link, the user simply knows someone is messing around and their access isn't impacted.
- The password reset link is only valid for a short period, so there's a very small window for an attacker to strike. And even if they did, the user would know because the reset link would no longer work if the attacker intercepted the link and used it to change the password. If the new assigned password isn't changed by the user immediately, the attacker who intercepted the password can quietly impersonate the user indefinitely. So the big difference is, while a hacker can intercept the reset password link email, if they use the link to change the user's password, the user will know something is wrong because the link won't work and they'll generate another password reset request.
- Easier to use - the user simply clicks a link in their email rather than typing a new random password you've generated.
通过忘记密码链接设置临时密码允许用户有效地更改用户密码,并在用户知道用户登录时将其锁定在帐户之外。通过链接,用户只需知道有人在乱搞,他们的访问不会受到影响。
密码重置链接仅在短时间内有效,因此攻击者可以使用非常小的窗口进行攻击。即使他们这样做,用户也会知道,因为如果攻击者拦截了链接并使用它来更改密码,则重置链接将不再起作用。如果用户未立即更改新分配的密码,则截获密码的攻击者可以无限期地悄悄地冒充用户。所以最大的区别是,虽然黑客可以拦截重置密码链接电子邮件,如果他们使用该链接更改用户密码,用户将知道某些错误,因为链接将无法正常工作,他们将生成另一个密码重置请求。
易于使用 - 用户只需单击其电子邮件中的链接,而不是键入您生成的新随机密码。
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.
安全问题通常会使网站安全性降低,而不是更多 - 它们是另一种攻击媒介,通常是最薄弱的环节。我强烈建议您阅读Web应用程序黑客手册,以便对此主题进行精彩讨论。
#3
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.
请注意,选项#2还要求您跟踪旧密码,如果未在24小时内使用,则使新随机密码失效。
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.
此外,请避免要求“识别问题”。这些问题的答案通常比真实密码更容易猜测/查找 - 所以每个人都可以将自己标识为我。请参阅Sarah Palin的故事,了解最近的例子,了解这是多么不安全。
#4
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.
有一点需要提及#2:不要让进程覆盖当前帐户密码。如果发生这种情况,任何人都可以说他们忘记了任何帐户的密码,从而触发了大量不必要的密码更改。
#5
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.
选项1或2的安全性没有实际区别。选项1实际上与在表单中预加载新密码相同。
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.
事实上,随着网络钓鱼攻击的普遍存在,人们可能会争辩说,鼓励使用带有长URL的选项1可能会让人们对点击长神秘网址不那么警觉。
#6
Read the OWASP top ten to make sure your method is compliant.
阅读OWASP前十名以确保您的方法符合要求。
Here is the direct link.
这是直接链接。
#7
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.
只是快速说明一些与您的问题无关的内容。您提到您使用MD5来哈希存储的密码。无论您选择使用选项1还是2(由于显而易见的原因,3都是最不安全的),MD5是一种破解哈希算法,实际上可以让黑客很容易获得受保护的帐户的访问权限。 MD5哈希。
You can read more about the vulnerability it at the following URL: en.wikipedia.org/wiki/MD5
您可以通过以下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.
更好的散列解决方案就像SHA一样,它仍然是一种稳定而安全的散列算法。结合选项#1或#2,您应该拥有一个合理安全的系统来保护您的用户密码,除了最坚定的黑客之外的所有人。
#8
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可能是最好的。 #3是不安全的(我还建议使用比MD5更强大的东西,比如SHA1)。选项#2不好,因为它允许任何随机的人在您检查电子邮件之前将您锁定在帐户之外,除非您使用安全问题。安全问题通常比密码更容易破解。
#9
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.
与#2相比,选项#1有几个主要优点。如果随机用户在我的电子邮件地址中输入“我忘记了密码”框,则我的密码将不会被重置。此外,它更安全一点,因为永远不会永久记录存储在您的Gmail邮箱中的网站密码。
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
这里一个关键缺失的部分是你在#1中提供的链接应该仅适用于一次密码重置并且有时间限制
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.
我首选的方法是尽可能使用openid。密码管理是没有人似乎完全正确的地狱。将此问题交给其他人更容易。
#10
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.
选项4:要求用户通过输入其帐户名和电子邮件地址来重置密码。只要您没有在网站上披露真实姓名或电子邮件地址(您为什么在这个时代?),这是一种相当安全且防篡改的方法。发送重置页面的链接,而不是密码本身。
Option 5: Use OpenID and pass the responsibility to a 3rd-party to worry about it.
选项5:使用OpenID并将责任转交给第三方以担心它。
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.
老实说,尽管这比大多数网站要求的要多得多。我一个人通过电子邮件收到明文密码,因为我将它们存储在收件箱的“注册”文件夹中。这样,当我忘记它们时,我可以查找网站的密码(这种情况发生了很多!)。如果有人在阅读我的电子邮件,我担心的问题比使用我的推特账号的人要多(如果我有的话)。当然,银行和公司有更强的要求,但您没有指定您的网站是什么。这是最佳答案的关键。
#11
I agree with your comments about option #3 being insecure.
我同意你对选项#3不安全的评论。
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.
至于编程#1或#2,选项#2更容易编程,但#1并不难,并且两者都可能彼此安全。
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:
最简单的方法是:
- Have a "remind me of my username" link (enter email). Don't tell the user if an email was sent or not because people can use that to find out if an email address is of a member. Always tell the user to check their inbox for the reminder email but only send it if someone is a member; and
- Require both username and email to get sent a new one-time password. That password should only last an hour or so. When the user uses it, they should be forced to change their password immediately.
有一个“提醒我我的用户名”链接(输入电子邮件)。不要告诉用户是否发送了电子邮件,因为人们可以使用它来查明电子邮件地址是否属于成员。始终告诉用户在收件箱中查看提醒邮件,但只有在有人成为会员时才发送;和
需要用户名和电子邮件才能收到新的一次性密码。该密码应该只持续一个小时左右。当用户使用它时,应该强制他们立即更改密码。
#12
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.
选项1或2都可以。正如您所说,选项3是不安全的,因为您需要存储明文密码。您可能会喜欢并使用可逆加密算法来存储/检索密码,但是有更好的替代方案可供您使用,没有理由走这条路。
#13
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).
由于提醒不是密码本身,因此可以通过邮件发送(或者甚至可以直接在页面上显示)。
#14
If you are hashing them Option 3 is unavailable and if you are not hashing them, shame on you. :)
如果你正在哈希它们,那么选项3是不可用的,如果你没有哈希,那么你就会感到羞耻。 :)
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,发送重置密码链接发送到他们的电子邮件,允许他们(在有限的时间内)重置他们的密码。它确实需要更多工作,但它们很容易使用,并且最终与其电子邮件登录过程一样安全。
#15
You could made a mix between #1 and #2, taking advantages from both:
您可以在#1和#2之间进行混合,从以下两方面获益:
Send the user an email with a link to a unique, hidden URL that allows him to change a new randomly generated password.
向用户发送一封电子邮件,其中包含指向唯一隐藏URL的链接,该URL允许他更改新随机生成的密码。
That page could be SSL, and the password could expire in 12-24 hours.
该页面可能是SSL,密码可能会在12-24小时后过期。
#16
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:
我尝试了几种我并不满意的方法。我为下一个项目所做的就是:
- User enters username and email address
- Email sent with link containing url and guid param which has been stored in db with 48 hour expiry
- User confirms password to be reset
- New password is emailed to user
- Login with new password displays message or redirects to change password page.
用户输入用户名和电子邮件地址
通过包含url和guid param的链接发送的电子邮件,该链接已存储在db中,有效期为48小时
用户确认要重置的密码
新密码通过电子邮件发送给用户
使用新密码登录会显示消息或重定向以更改密码页面。
#17
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.
当然,这假设您的用户附近有办公室,并且该帐户的价值足以证明此过程的合理性。适用于例如银行。