ASP.NET Forms身份验证的授权安全
我在 ASP.NET MVC 网站中使用表单身份验证，并将用户帐户登录名存储在 AuthCookie 中，如下所示：
FormsAuthentication.SetAuthCookie(account.Login, false);
我想问客户端的用户是否有可能以某种方式设法在 AuthCookie 中更改其登录名，从而例如，他将被冒充为具有更高特权的人，并被授权执行比正常情况下更多的行动。另外，在此 cookie 中保存用户帐户登录名还是用户帐户 ID 号更好？
I'm using Forms authentication in ASP.NET MVC website and I store user account login name in AuthCookie like this:
FormsAuthentication.SetAuthCookie(account.Login, false);
I want to ask if there is a possibility that user on client side will somehow manage to change his login name in AuthCookie and thus he will be for example impersonated as someone with higher privileges and authorized to do more actions than he is normally supposed to have. Also is it better to save in this cookie user account login name or user account ID number?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
cookie 将在服务器端进行加密和解密，因此除非用户可以破解加密密钥，否则他或她将无法做到这一点。
只要您存储的信息唯一地标识您的用户，对该信息的选择完全取决于特定应用程序的要求。
The cookie will be encrypted and decrypted on the server side, so unless the user can crack the encryption key, he or she won't be able to do this.
As long as the information you store uniquely identifies your user, the choice as to what that information is is entirely down to the requirements of the particular application.
不，这是不可能的（理论上也许可以，但实际上是不可行的）。身份验证 cookie 的值经过加密，因此用户无法篡改。最好将（唯一的）登录名存储在身份验证 cookie 中，因为当恢复
IIdentity对象 (HttpContext.Current.User) 时，该值将被恢复。您传递给SetAuthCookie用于IIdentity的Name属性。例如，如果您使用LoginStatusControl，则会显示Name属性，因此最好让Name属性的值有意义给用户。No it is not possible (well, in theory maybe but it's not feasible in practice). The value of the authentication cookie is encrypted so the user can not tamper with it. It is a good idea to store the (unique) login name in the authentication cookie, because when the
IIdentityobject (HttpContext.Current.User) is restored, the value that you passed toSetAuthCookieis used for theNameproperty of theIIdentity. TheNameproperty will be shown if you use theLoginStatusControl, for example, so it's a good idea that the value of theNameproperty makes sense to the user.Cookie 已加密，因此出现这种情况的可能性很小。但仍然。
不止一种属性方法
如果您想让安全性更加严格，您可以保存用户名以及用户 ID 或其他一些无法从用户名中猜出的数据。这些的组合使它更安全，因为如果你能猜出一个，就很难猜出其他的并使用它们的正确组合。 IE。如果您猜测其他用户的电子邮件/用户名，则猜测同一用户的 ID 会有点困难，因为它们不相关。因此，组合的不相关属性越多，获得正确组合所需的步骤就越多。
登录安全令牌方法
您可以使用此场景中描述的替代方法：
LastLogonDate信息）是很常见的。这样，从长远来看，它会变得更安全，因为此信息会在每次登录时发生变化，如果用户手动注销，您始终可以从存储中清除该令牌，因此根本不可能注入其他人的身份。这确实使使用永久 cookie 变得更加复杂，但仍然可以做到。
这种方法并非万无一失，但它提供了额外的安全级别，可以在一个帐户遭到破坏时防止反复发生相同的攻击。而且，当一个帐户受到威胁时，并不意味着其他帐户也会受到威胁。如果您的安全令牌足够长，那么在您的网站上发起暴力攻击就会困难得多，并且虽然执行这种攻击，但安全令牌会发生变化，因此绝对更安全。
Cookies are encrypted so chances for that a quite slim. But still.
More than one property approach
If you'd like to make your security even tighter you could save username as well as user ID or some other data that can't be guessed from the username. The combination of these makes it safer because if you can guess one it harder to guess others and use the correct combination of them. Ie. If you guess other user's email/username it's a bit harder to guess the same user's ID, because they're not related. So the more unrelated properties you combine the more steps it takes to get the right combination.
Logon security token approach
You could use an alternative approach described in this scenario:
LastLogonDateinfo.This way it will make it safer on the long run, because this information will change on each login and if user does manually logout you can always clear that token from the store, so it won't at all be possible to inject someone else's identity. This does make it a but more complicated to use permanent cookies though but it can still be done.
This approach is not bullet proof but it provides additional security level that prevents the same attack over and over again when one account has been compromised. And also when one account is compromised it doesn't mean that others can be as well. If your security tokens are long enough it would be much harder to start a brute force attack on your site and while this kind of attack would be executed security tokens will change so it is definitely safer.