为什么挑战-响应方法对于忘记密码来说不是一个糟糕的解决方案？
我的公司正在开发在线人力资源和薪资应用程序，其中安全访问至关重要。 我清楚如何锁定大多数身份验证/授权过程，但“忘记密码”页面除外。
我最初的计划是要求用户输入电子邮件地址和对先前选择/输入的质询问题的答复，并将临时密码邮寄到列出的电子邮件（假设电子邮件有效）。 但我已阅读此处和这里（都在SO上）挑战-响应方法是不安全的。
如果我们只是通过电子邮件发送临时密码，那么它真的那么不安全吗？ 我能想到的唯一更安全的选择是要求用户致电他们的客户服务代表，这将极大地增加我们员工的负担。
我错过了什么......有更好的方法吗？ 谢谢！
My company is developing an online HR and Payroll application where securing access is critical. I'm clear on how to lock down most of the authentication/authorization processes, except for the 'Forgotten Password' page.
My initial plan was to require the user to enter both an e-mail address and a response to a previously selected/entered challenge question, with a temporary password being mailed to the e-mail listed (assuming the e-mail is valid). But I've read here and here (both on SO) that the challenge-response approach is insecure.
If we're only e-mailing a temp password though, is it really that insecure? The only more secure option I can think of would be to require the user to call their Customer Service Rep, which would greatly burden our employees.
What am I missing ... is there a better approach? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
不要通过电子邮件发送临时密码，而是通过电子邮件向用户发送 URL + 令牌以重置密码页面。 这样一来，任何未加密的密码都不会转手。 如果最终用户尝试访问该页面并且重置令牌已被使用，那么最终用户也可以立即明显地看出他们的帐户已被盗用。
从评论中添加：
我认为挑战-响应（“秘密问题”）方面实际上使事情变得不那么安全，因为它们通常可以通过研究有关目标的公共信息来发现。 总步骤越少，在无人知晓的情况下被破坏的步骤就越少。 尽早且经常进行重置电子邮件是让人们知道正在尝试的好方法。
Don't email a temp password, email the user a URL+token to a reset-password page. That way no password is ever changing hands unencrypted. It's also immediately obvious to the end-user that their account has been compromised if they try to go to that page and the reset token has already been used.
Added from the comments:
I think challenge-response ("secret question") aspects actually make things less secure, because they are generally things that can be discovered by researching public info about the target. The fewer steps total, the fewer that can be broken without anyone knowing. Letting reset emails go early and often is a good way to let a human know the attempt is being made.
正如这篇文章中所解释的，佩林州长电子邮件帐户最近被黑客使用先前提出的问题的答案。 来自文章：
As explained in this article, Governor Palin e-mail account was recently hacked using answers to previously asked questions. From the article:
有几种常见的方法来管理丢失的密码：
秘密问题：它实际上是一种较弱的身份验证形式，就像上面的人发布的那样。 用户可能会选择一些非常简单并且很容易猜测的东西。 我建议不要这样做，因为它不需要任何技术“黑客攻击”
邮寄新密码。 要规避此控制，需要访问电子邮件帐户或需要中间人 (MITM) 位置：您可以从用户的收件箱中读取临时密码，也可以在中间进行拦截。 这种方法很容易被滥用，因为如果用户无法阅读带有新密码的电子邮件，任何人都可以重置密码并强制用户退出系统。
邮寄密码重置哈希，为了规避此问题，您需要访问收件箱或 MITM，就像之前的情况一样，但在确认完成之前不会真正重置密码。 因此，即使用户没有阅读电子邮件，也不会被锁定在系统之外。 添加冷却计时器，每 8 小时重置一次，以防止您的系统淹没用户的收件箱。
考虑一些带外通信，例如，在打印的合同中写下 PIN。 然后让用户通过已知的电话号码致电您的帮助台（检查来电显示）并提供他的用户名和 PIN。
There are a few common ways to manage lost passwords:
The Secret Question: It is actually a weaker form of authentication, just like people above posted. User may choose something really simple and it is easy to guess. I advise against this, because it does not require any technical "hacking"
Mail a new password. To circumvent this control, access to the e-mail account is required or a Man-In-The-Middle (MITM) position is required: You either read the temporary password from user's inbox or intercept in the middle. This approach is ripe for misuse, because anybody can reset the password and force the user out of the system, if he can't read the e-mail with new password.
Mail a password reset hash, to circumvent this, you need access to inbox or MITM, just like in case before this, but no passwords are actually reset until confirmation is done. Thus, user can not be locked out of the system, even if he did not read the e-mail. Add a cooldown timer to one reset per 8 hours to prevent Your system from flooding user's inbox.
Consider some out of band communication, for example, in the printed contract, write down a PIN. Then have the user call Your helpdesk from a known phone number (check with Caller ID) and give his username and PIN.
像 SO 那样外包整个密码管理并使用 OpenId 或类似的东西不是很容易/可行吗？ 当然，这会增加另一个依赖性，但您可以用它来交换保存（和保护）密码并按照您所描述的方式处理它们的需要。
Wouldn't it be easy/feasible to outsource the whole password management just like SO did and use OpenId or similar? Of course this would add another dependency, but you'd trade that against the need to save (and secure) passwords and deal with them as you described.
您说这是一个在线人力资源和工资单应用程序。 您是否可以选择让用户表明他/她忘记了密码，并向人力资源代表或组织中的某些官员发送消息，由他们确认身份，然后发出密码重置命令？
You said it is an on-line HR and payroll application. Do you have the option of a user indicating he/she has forgotten his/her password and that generating a message to an HR representative or some official in the organization who can confirm identity and then issue a password reset?
简而言之，挑战性问题往往是最薄弱的环节。 它们比密码更容易猜测，并且可以有效地充当密码的代理，因此它们实际上降低了安全性，而不是通过提供另一种更容易破解的攻击向量来增强安全性。 Web 应用程序黑客手册提供了有关此领域的一些重要信息。
In short, challenge questions are often the weakest link. They're easier to guess than a password and effectively operate as a proxy for a password, so they actually reduce security rather than enhance it by providing another attack vector that's actually easier to break. The Web Application Hacker's Handbook has some great information on this area.