ASP.NET 应用程序中密码重置的安全性

发布于 2024-10-15 05:12:22 字数 492 浏览 1 评论 0原文

我有一个允许用户重置密码的 ASP.NET。

该过程是

  1. 用户通过电子邮件单击重置链接。该链接包含一个安全令牌。
  2. 用户将进入应用程序的第 1 页并回答安全问题。
  3. 如果问题正确,则进入第 2 页并重置密码。

所有数据都安全地存储在数据库等中。我主要关心的是页面 1 和 2 之间的交互,并确保人们无法直接转到页面 2 来更改密码

为了防止这种情况,我计划这样做。

  1. 在第 2 页上时,始终检查引用页面是否为第 1 页,如果不是,则退回
  2. 将电子邮件链接中的安全令牌放入第 1 页的会话中,并且仅允许使用第 2 页(如果该页面仍在会话中)。
  3. 会话超时时间较短,因此输入密码的时间有限。还可以在数据库中记录他们完成第 1 页的时间。

我的问题是。 这是一个狡猾的计划还是有人能看出其中的缺陷?

I have an ASP.NET that allows users to reset passwords.

The process is

  1. User clicks on reset link via email. The link contains a security token.
  2. User gets taken to page 1 of app and answers security questions
  3. If questions right then proceed to page 2 and reset passwords.

All data is stored securely in a database etc. My main concern is the interaction between page 1 and 2 and ensuring that people cant go directly to page 2, to change their password.

To protect against this I plan to.

  1. Always check the referring page is page 1 when on page 2 and bounce if its not
  2. Put the security token that comes in the email link in the session on page 1 and only allow to use page 2 if this is still in the session.
  3. Have low session timeout so have limited time to enter password. Could also record in the database, the time that they completed page 1.

My question is. Is this a cunning plan or can anyone see a flaw in it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

梦在夏天 2024-10-22 05:12:22

您计划的第 1 步可能不会很好地发挥作用,不建议依赖可用的引荐来源网址值,因为它 a) 容易欺骗,b) 经常被偏执的用户禁用。

第 2 步听起来像是您想要实现 CSRF 令牌类型方法,这是一个好主意。

主要要保护的是电子邮件中发送的安全令牌,只要攻击者在不阅读电子邮件的情况下无法确定该令牌,那么就相对安全。如果攻击者可以读取用户的电子邮件,那么几乎任何密码恢复方案都将被破坏。

Step 1 of your plan will probably not work very well, relying on referrer values to be available isn't recommend since it's a) easy to spoof, b) often disabled by paranoid users.

Step 2 sounds like you want to implement a CSRF token type approach, this is a good idea.

The main thing to protect is the security token sent in the email, as long as the attacker can't determine that token without reading email it is relatively safe. If the attacker can read the users email then just about any password recovery scheme will be broken.

夜司空 2024-10-22 05:12:22

我认为令牌应该存储在数据库中并在以下情况下失效:

  • 经过一定时间跨度
  • 生成新电子邮件
  • 用户重置密码

I thought the token should be stored in the database and invalidated if:

  • a certain timespan elapses
  • a new email is generated
  • user resets the password
属性 2024-10-22 05:12:22

为什么不让用户保持在同一页面上呢?
我会使用 WizardControl

如果您决定继续使用两页方法,则可以在正确回答给定令牌的安全问题时在数据库中设置一个标志。在第 2 页中,您检查标志是否已设置,如果未设置 ->重定向到第 1 页。

Why don't you keep the user on the same page instead?
I would use a WizardControl.

If you decide to stay with the two page approach, you can set a flag in your database when the security questions for a given token have been answered correctly. In page 2 you check if the flag is set, if it is not -> redirect to page 1.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文