设置会员商店密码

发布于 2024-08-06 13:28:16 字数 441 浏览 4 评论 0原文

我正在将一个应用程序从 ColdFusion 迁移到 ASP.Net MVC,但遇到了一个小问题,我似乎无法理解。原始应用程序以 MD5 哈希格式存储用户密码,数据库中不加盐。我正在使用 ASP.Net 会员商店,并希望为现有用户提供尽可能无缝的过渡。这是我想到的可能性...

1)由于我无法解密他们当前密码的值,我正在考虑将这个旧密码存储在表中,在登录时检查它...如果它不为空并且他们的密码匹配时,我提示他们更新密码,然后在 ASP.NET 成员资格表中正确设置密码并清除旧密码,不再检查。

2)用户使用他们的电子邮件登录,而不是他们的屏幕名称,所以我正在考虑将每个人的密码重置为他们的屏幕名称,并强制他们在第一次登录后更改它。唯一的问题是我不确定是否可以在没有当前密码的情况下通过 SQL 更新他们的密码。执行 aspnet_Membership_SetPassword 过程似乎不会自行加密密码。

你说的话?

I'm migrating an application from ColdFusion to ASP.Net MVC and have a little problem I cannot seem to get my head around. The original application stores user's passwords in a MD5 hash format with no salt in the database. I'm using the ASP.Net membership store and would like to allow for as seamless a transition for the existing users as possible. Here's the possibilities I was thinking of...

1) Since I cannot decrypt the values of their current passwords, I was thinking of storing this old password in a table, checking against it on login... if it's not empty and their password matches, I prompt them to update their password, which would then set the password properly in the asp.net membership table and wipe out their old password, never to be checked again.

2) Users login with their email, not their screen name, so I was thinking of resetting everyone's password to their screen name and forcing them to change it after first login. The only problem is that I'm not sure I can update their password via SQL without the current password. Executing the aspnet_Membership_SetPassword proc doesn't appear to encrypt the password in its own.

What you say?

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

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

发布评论

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

评论(3

狼性发作 2024-08-13 13:28:16

我在实际应用程序中使用了 #1 的变体。它效果很好,据我所知,用户从未注意到这种变化。

一些改进:

  • 您不需要提示他们更新密码;他们为您提供了登录的明文(并且您知道这是正确的明文,因为它已正确散列),因此只需继续将其设置为他们的密码即可。
  • 如果他们使用密码重置功能,请确保清除旧密码哈希。

我在任何情况下都不会使用选项 2;这是非常不安全的。

另一件事——可以在不知道当前密码的情况下设置密码,只需要两个步骤。

  1. 重置用户密码。您现在知道重置密码了。
  2. 使用新重置的密码将密码设置为已知值。

I've used a variant of #1 in a live application. It worked great, users never noticed the change as far as I was aware.

A couple of refinements:

  • You don't need to prompt them to update their password; they provided you the cleartext to log in (and you know it's the correct cleartext since it hashed correctly), so just go ahead and set that as their password.
  • Make sure you clear the legacy password hash if they use the password reset functionality.

I would under no circumstances use option 2; it's wildly insecure.

One other thing -- it is possible to set a password without knowing their current one, it just requires two steps.

  1. Reset the user's password. You now know the reset password.
  2. Use the newly reset password to set the password to a known value.
一页 2024-08-13 13:28:16

我最近遇到了类似的情况 - 我的一个旧应用程序使用了 salted MD5,我非常想在不影响我的用户的情况下进行升级。我最终所做的是将原始哈希包装在更好的哈希中,然后重新加盐以减轻分辨率的损失。

例如,我的初始哈希是 MD5(pass + salt),

我将所有内容升级为 SHA256(MD5(pass+salt) +salt) - 这样我的应用程序是安全的,我不需要找出原始密码或重置任何内容。

新的身份验证过程到位后,只需对数据库中的所有现有用户运行更新脚本即可。这有点麻烦,但对于用户来说基本上是无缝的。

--

呸- 我很抱歉,这并不是真正为 ASP.net 会员量身定制的,因为我在我的应用程序上使用自定义身份验证类。我仍然认为这是执行升级的更合理的方法之一,但我不确定 ASP.net 会员资格的具体情况。

I had a similar situation recently- An old application of mine used a salted MD5 and I very much wanted to upgrade without affecting my users. What I ended up doing was wrapping the original hash in a better hash and then re-salting it to mitigate the loss of resolution.

For example my initial hash was MD5(pass + salt)

I upgraded everything to SHA256(MD5(pass+salt) +salt) - that way my app is secure and I never needed to find out the original passwords or reset anything.

Once your new authentication process is in place simply run an update script over all existing users in the DB. It is a little bit of a pain but is essentially seamless for you users.

--

Bah- I apologize, this isn't really tailored to ASP.net membership as I'm using a custom auth class on my application. I still think it is one of the more sound methods for performing the upgrade, but i'm not sure of the ASP.net membership specifics.

菩提树下叶撕阳。 2024-08-13 13:28:16

选项2是一个相当大的安全风险。如果任何人知道屏幕名称的电子邮件,则可以在合法所有者登录之前劫持该帐户。了解或猜测最受欢迎的网站用户(即最容易劫持的用户)的电子邮件可能比您想象的更普遍。

Option 2 is a pretty big security risk. If anyone knows the email of a screen name can log hijack that account before the rightful owner logs in. Knowing or guessing the email of most popular site users (ie. most tempting ones to hijack) may be more prevalent than you think.

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