如何保护重置密码功能？
我想实现重置密码功能，以防用户丢失密码。但我担心有人能够对不属于他的单个或多个电子邮件地址发出大量此类请求，这会让这些地址的实际所有者感到烦恼，而且我最终会被列入黑名单。
我可以采取什么措施来保护此功能？设置每个 ip 发送的有效电子邮件的限制？ （我想最多 3 封电子邮件就可以了）
I want to implement a reset password feature in case users lose their passwords. But I'm worried about someone being able to make a lot of these requests for a single or multiple email addresses that don't belong to him, which would be annoying for the actual owners of those addresses, and I would end up blacklisted.
What can I do to secure this feature against that? Set a limit of valid emails sent per ip? (3 emails max would be fine I guess)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
忘记密码页面保护：
输入无效电子邮件时显示成功消息。当有人输入无效电子邮件时，告诉用户重置密码链接已发送到您的电子邮件（但不要实际上让代码做任何事情）。这将防止黑客试图识别系统上的有效帐户。
使用验证码短语。避免恶意脚本触发大量电子邮件的许多重置密码请求。
特定电子邮件的重置密码链接每小时发送的次数不应超过 3 次（左右）。这将防止数据库表中存储的重置链接过多而淹没数据库并填满数据磁盘。
Forgot Password Page Protection:
Show a success message when an invalid email is entered. When someone enters an invalid email, tell the user that the reset password link has been sent to your email (but dont actually make the code do anything). This will protect from hackers trying to identify valid accounts on the system.
Use A Captcha Phrase. To avoid malicious scripts from triggering many reset password requests for a large list of emails.
Reset password link for a specific email should not be sent more than 3 times (or so) per hour. This will protect from flooding the database with too many reset links stored in the database table and filling up the data disk.
为什么不简单地将验证码添加到密码重置请求表单中？然后，您可以限制每个电子邮件地址以及每天/每周/每月的请求数量，但验证码可以让机器人远离。
Why not simply add a CAPTCHA to the password reset request form? You could then limit the number of requests per email address and per day/week/month, but a CAPTCHA would keep bots away.
假设您正在编写一个要在互联网上使用的应用程序，而您无法控制用户的注册，则可以对用户帐户上尝试的密码重置尝试次数设置滚动限制。
滚动限制将用于确保不会在短时间内发出过多的密码重置请求。您可以限制用户发出 3 次密码重置请求，但只能在 1 小时内，甚至可能是 1 天；您的企业应该能够确定最佳值，特别是如果用户还可以通过其他方式（通过发送电子邮件或致电服务台）发出密码重置请求。
此外，您可以将生成的令牌（我假设您在每封邮件中发送密码重置令牌）与预定义的到期日期相关联，并且所有此类令牌只能使用一次。理想情况下，令牌的持续时间不应超过几个小时。除了通常的身份验证尝试之外，高度敏感的应用程序还将审核所有密码重置请求。
最后，您还可以对源自特定 IP 的密码重置请求的数量设置限制（这是 DoS 预防攻击，无法抵御 DDoS 攻击）。不用说，如果尝试重置密码，则不应在此期间禁用关联帐户。这样做会导致成功的 DoS 攻击，攻击者只需针对已知电子邮件 ID 数据库发出密码重置请求即可禁用帐户。在建立限制时，您必须考虑 ISP 代理，否则您可能会在此过程中实际上伤害一些客户。
Assuming that you are writing an application meant to be used on the internet, where you cannot control registration of users, you can set a rolling limit on the number of password reset attempts that are attempted on a user account.
The rolling limit would be used to ensure that too many password reset requests are not sent out within a short duration. You can limit users to issuing 3 password reset requests, but only within 1 hour, or may be even 1 day; your business should be capable of determining the optimum value, especially if users can also issue password reset requests via other means (by sending emails or calling up a service desk).
Also, you can associate the generated tokens (I'm assuming that you are sending out password reset tokens with each mail) with a predefined expiry date, and all such tokens may be used only once. Tokens should ideally not last more than a few hours. Highly sensitive applications would also audit all password-reset requests in addition to the usual authentication attempts.
Finally, you can also establish limits on the number of password reset requests originating from a certain IP (this is a DoS prevention attack and wouldn't work against DDoS attacks). Needless to say, but the associated accounts should not be disabled in the interim, if an attempt was made to reset the password. Doing so, would enable a successful DoS attack where in an attacker can disable accounts by simply issuing password reset requests against a known email ID database. You will have to account for ISP proxies in establishing the limit, or you might actually hurt a few customers in the process.
我看到其他网络属性引入了新的密码重置系统（比验证码好得多），该系统提供某种形式的 2FA（双因素身份验证），您可以在其中远程签名到您的帐户，作为备份。用户收到发送到其单元格的一次性 PIN 码，然后将其输入。无需处理垃圾邮件过滤器，无需重新加载验证码表单等......更容易。防止批量注册、垃圾邮件，通常比其他解决方案更有效、更用户友好。
I have seen other web properties introduce a new password reset system (much better than CAPTCHA) which provides some form of 2FA (two-factor authentication) where you can telesign into your account, in place as a back-up. User gets a one-time pin code sent to their cell, and enters that in. No spam filters to deal with, captcha forms to reload, etc... much easier. Prevents bulk registrations, spam, and generally seems to be more effective and user-friendly than alternative solutions.
请注意 IP 的设置限制。您经常会遇到通过单个 IP（即企业网络）暴露大量用户的单个互联网网关。
如果您担心重置特定地址的请求数量，那么这更多的是可用性问题，而不是安全问题。我倾向于定义一个可接受的比率，它可以在不允许太多重置请求与执行重置变得太困难之间取得平衡（即原始电子邮件被垃圾邮件捕获，因此请求另一封电子邮件）。例如，记录请求的时间，并在 15 分钟内不允许另一个请求。
但实际上，我不会对此太担心。如果你真的想的话，有无数种通过电子邮件与某人搞砸的方法，所以除非利用你的重置功能有特别有吸引力的东西，否则我只会做大多数网站所做的事情，并在需要时允许重置，并且只有在之后才真正重置密码用户收到电子邮件并执行操作。
Be careful about settings limits by IP. You've often got a single internet gateway exposing large number of users through a single IP (i.e. corporate networks).
If you're worried about the number of requests made to reset a particular address, this is more of a usability issue than a security issue. I'd be inclined to define an acceptable rate which balances not allowing too many reset requests with not making it too difficult to perform a reset (i.e. original email gets caught in junk so another is requested). For example, log the time of the request and not allow another one for another 15 minutes.
Pragmatically though, I wouldn't be too worried about this. There are endless ways to screw with someone via email if you really want to so unless there is something particularly attractive about exploiting your reset feature, I'd just be doing what most sites do and allowing resets when required and only actually resetting the password after the user receives the email and actions it.