根据角色要求某些用户使用更强的密码
我有一个 MVC 3 应用程序。关于安全主要有两个区域。第一个主要是为了防止公众访问,但不是真正的敏感信息。密码强度可能较弱,因为实际上也没有太大的危害。
第二个区域(区域)受到限制。用户必须申请访问。如果用户获得访问权限,它将获得特定的角色。因此,每个控制器方法都会根据该角色对用户进行授权。
我希望这些用户必须在下次登录时将密码更改为强密码,然后才能进一步访问受限内容。
示例:
用户A申请访问。 授予访问权限。密码策略为 只要该用户具有访问权限,就会发生更改。他们必须 下次登录时更改密码,并且无法改回来 只要他们具有该角色,就可以使用较弱的密码。
有没有使用 ASP.NET 实现这一点的安全方法?
更新
我实际上已经使用了 Chris 提出的解决方案并且它有效,但是为了处理密码本身的验证,我实际上也从 Micah 提出的解决方案中得到了一些灵感。然而,事实证明,重写 MembershipProvider.OnValidatingPassword 确实意味着还必须实现 10 个以上的抽象方法,而我确实不需要解决这个问题。
在我看来,更好的解决方案是连接 Membership.ValidatingPassword 事件。我在 App_Start 中执行此操作,然后在事件处理程序中实现自己的密码验证,这解决了我的问题。
只是为了与您分享解决方案,我将其与克里斯解决方案一起展示在这里,这解决了我的问题,并希望也能解决其他人的问题:
void App_Start()
{
//To do custom validation on certain passwords set new event handler
Membership.ValidatingPassword += Membership_ValidatingPassword;
}
private void Membership_ValidatingPassword(object sender, ValidatePasswordEventArgs e)
{
//If the user is a new user, we let registration happen without strong password
if (e.IsNewUser) return;
MembershipUser membershipUser = Membership.GetUser(e.UserName);
Guid userId = Guid.Parse(membershipUser.ProviderUserKey.ToString());
//First check if the pwd is strong enough to be flagged, if so we flag it
//using regex to validate the password (20 char, 2 uppercase so on)
if (MyValidationClass.IsStrongPassword(e.Password, 20, 2, 4, 1))
{
//if the user does not already have a flag we set one
MyValidationClass.SetStrongPasswordFlag(userId);
}
else
{
//If the user needs strong pwd, we cancel the operation and throw exception
if (MyValidationClass.NeedsStrongPassword(e.UserName))
{
e.FailureInformation =
new MembershipPasswordException("Password does not satisfy reqirements!");
e.Cancel = true;
}
else
{
MyValidationClass.RemoveStrongPasswordFlag(userId);
}
}
}
I have a MVC 3 app. There are mainly two zones regarding security. The first one is mostly to prevent public access, but not really sensitive information. Password strength might be weak since there is not really much harm to do either.
Second zone(Area) is restricted. user must apply for access. If user gets access it gets a certain role(s). So each controller method autorizes the user based on that role.
I want these users to have to change password to a strong password on the next logon before they can go further and access the restricted content.
Example:
User A applies for access.
Access is granted. The password policy for
that user is changed as long as it has access. They MUST
change their password on the next logon, and they cannot change back
to a weaker password as long as they have that role.
Is there any secure way to implement this using the ASP.NET?
Update
I've actually used Chris proposed solution and it works, but to handle the verification of the password itself I actually got some inspiration from Micah's proposed solution too. However, it turns out that overriding MembershipProvider.OnValidatingPassword does imply also having to implement 10 + abstract methods that I really do not need to solve this.
A better solution in my eyes was hooking on to the Membership.ValidatingPassword EVENT. I do this inn App_Start, then I implement my own password validation in the event handler and that solved my problem.
Just to share the solution with you i present it here, toghether with Chris solution this solved my problem and hopefully for someone else too:
void App_Start()
{
//To do custom validation on certain passwords set new event handler
Membership.ValidatingPassword += Membership_ValidatingPassword;
}
private void Membership_ValidatingPassword(object sender, ValidatePasswordEventArgs e)
{
//If the user is a new user, we let registration happen without strong password
if (e.IsNewUser) return;
MembershipUser membershipUser = Membership.GetUser(e.UserName);
Guid userId = Guid.Parse(membershipUser.ProviderUserKey.ToString());
//First check if the pwd is strong enough to be flagged, if so we flag it
//using regex to validate the password (20 char, 2 uppercase so on)
if (MyValidationClass.IsStrongPassword(e.Password, 20, 2, 4, 1))
{
//if the user does not already have a flag we set one
MyValidationClass.SetStrongPasswordFlag(userId);
}
else
{
//If the user needs strong pwd, we cancel the operation and throw exception
if (MyValidationClass.NeedsStrongPassword(e.UserName))
{
e.FailureInformation =
new MembershipPasswordException("Password does not satisfy reqirements!");
e.Cancel = true;
}
else
{
MyValidationClass.RemoveStrongPasswordFlag(userId);
}
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以编写自己的授权属性来容纳两者。您只需在应用程序的相关部分使用它即可:
例如:
上面的代码将检查用户是否已安全地更改了密码。如果没有,它会将他们重定向到一个新页面,在其中更改密码。一旦他们更改了它,请将标志设置为已更改。
然后您可以像这样使用它:
您显然可以将这两个属性集成为一个,但为了显示示例,它们在上面被分开。
You could write your own Authorize Attribute to accommodate both. You simply need to then use it on the relevant sections of your application:
For example:
The above will check that the user has securely changed their password. If not it will redirect them to a new page in which to change their password. Once they change it, set the flag as changed.
You can then use it like this:
You could obviously integrate both of these attributes into one, but for the sake of showing the example they are seperated above.
您需要覆盖 MembershipProvider.OnValidatingPassword
http:// /msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.onvalidatingpassword.aspx
you will need override the MembershipProvider.OnValidatingPassword
http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.onvalidatingpassword.aspx
可能更简单的方法是当用户尝试输入新密码时检查客户端的密码强度。查看此列表一些使用 JQuery 的例子。
关于升级和重置密码的事务,这是您的代码可以处理的,即用户表中的一个标志,将用户重定向到新的注册页面。但是,当他们设置密码(并且可能与适当的强度匹配)时,就可以提交......
Probably a simpler method would be check the strength of the password on the client-side when you user is attempting to enter a new password. Check out this list for some examples using JQuery.
In regard the transaction of upgrading and resetting the password, that's something your code can handle, i.e. a flag in the users table that redirects the user to a new registration page. But when they set the password (and presumably it matches the appropriate strength) it can then be submitted...