FormsAuthentication：安全吗？
使用asp.net中内置的FormsAuthentication，可以非常快速、轻松地创建一个登录系统，为经过身份验证的用户创建 cookie：
FormsAuthentication.SetAuthCookie(uniqueUsername, false);
与 Web 中的一些代码配合使用。配置文件：
<authentication mode="Forms">
<forms loginUrl="Login.aspx" timeout="30" defaultUrl="Dashboard.aspx" protection="All" />
</authentication>
<authorization>
<deny users="?" />
</authorization>
这会将所有请求退回到 Login.aspx，直到用户获得批准并使用 SetAuthCookie() 方法调用创建 cookie。
这足够安全吗？
我使用的经验法则是，我不会在客户端上存储他们未发送给我的任何数据。所以我过去所做的是将用户名和密码保存在 cookie 中，然后对每个请求重新进行身份验证。
使用这种方法每次都需要重新进行身份验证，这会带来额外的开销，但这也意味着我没有在客户端上存储任何服务器数据。
我的担心
我担心的是，通过使用 SetAuthCookie() 方法调用，用户名将存储在客户端计算机上。那么有人是否有可能破解正在使用的加密并用另一个存储的用户名替换呢？
我认为我过于偏执，并且所使用的加密类型和级别是足够的，但我认为我会得到一些有关该主题的专家意见。
Using FormsAuthentication build into asp.net it's very quick and easy to create a login system that creates a cookie for authenticated users:
FormsAuthentication.SetAuthCookie(uniqueUsername, false);
Paired with some code in the Web.Config file:
<authentication mode="Forms">
<forms loginUrl="Login.aspx" timeout="30" defaultUrl="Dashboard.aspx" protection="All" />
</authentication>
<authorization>
<deny users="?" />
</authorization>
This will bounce all requests back to Login.aspx until the user is approved and a cookie is created using the SetAuthCookie() method call.
Is this secure enough?
The rule of thumb I use is that I don't store any data on the client that they've not sent me. So what I've done in the past is hold the username and password used in a cookie, then re-authentic this with every request.
There's the extra overhead of re-authenticating everytime with this approach, but it also means I've not storing any server data on the client.
My worry
My concern is that by using the SetAuthCookie() method call, that the username is being stored on the client machine. Is it then possible for someone to break the encryption being used and substitute the username being stored for another?
I think I'm being overly paranoid and that the type and level of encryption being used is adequate, but thought I'd get some expert input on the topic.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您不应该不使用这种方法。密码不应存储在身份验证票证中。原因是如果身份验证票证被泄露，那么攻击者就拥有了用户的密码。可以通过加密身份验证票证 cookie 来减轻此风险，但我假设您以纯文本形式存储 cookie。
正如 Shiraz 所指出的，如果您创建持久性 cookie，则 cookie 仅会保留在客户端计算机上。 （
SetAuthCookie的参数之一指示是否创建这样的 cookie。即使有人破坏加密方案来修改 cookie 以提供不同的用户名，他们也会遇到问题，因为身份验证票证也是经过数字签名的，这意味着 ASP.NET 可以检测 cookie 的内容是否已被修改。要伪造数字签名，攻击者需要知道服务器使用的盐，如果用户能够知道这一点，则意味着他是攻击者。可以访问您的网络服务器的文件系统，所以现在您需要
了解的另一件事是身份验证票证有有效期，这使得票证的有效期有限，因此即使有人窃取。用户的 cookie 中，攻击者使用被盗票据的时间将根据您为表单身份验证系统指定的超时值（默认为 30 分钟）进行限制。
总之，官方 ASP。 .NET 表单身份验证系统将比单独的开发人员能够实现的安全得多。出于多种原因，开发人员应该努力使用表单身份验证系统，而不是推出自己的解决方案，包括更好的安全性、不必重新发明轮子、采用标准实践，这样加入团队的其他开发人员就不会学到太多东西曲线以加快速度，等等。
有关表单身份验证系统以及如何保护票证、各种
You should not use this approach. The password should not be stored in an authentication ticket. The reason being is if the authentication ticket is compromised then the attacker has the user's password. This risk can be mitigated by encrypting the authentication ticket cookie, but I presume you were storing the cookie in plain-text.
As Shiraz noted, the cookie is only persisted on the client machine if you create a persistent cookie. (One of the parameters to
SetAuthCookieindicates whether or not to create such a cookie.Even if someone broke the encryption scheme to modify the cookie to supply a different username they'd run into problems because the authentication ticket is also digitally signed, meaning ASP.NET can detect if the contents of the cookie have been modified. To forge a digital signature the attacker would need to know the salt used by the server, and if the user can figure that out it implies he has access to your web server's file system, so now you've got bigger problems.
Another thing to understand is that the authentication ticket has an expiry, which puts a finite lifetime on the validity of the ticket. So even if someone were to steal a user's cookies, the time the attacker would have to use that stolen ticket would be limited based on the
timeoutvalue you specify for the forms authentication system (30 minutes by default).In conclusion, the official ASP.NET forms authentication system is going to be much more secure than something a lone developer will be able to implement. Developers should strive to use the forms authentication system rather than roll their own solution for a myriad of reasons, including better security, not having to reinvent the wheel, adopting standard practices so other developers who join the team don't have as large a learning curve to get up to speed, and so on.
For more nitty gritty details on the forms authentication system and how the ticket is secured, how the various
<forms>configuration settings work, and so on, see: Forms Authentication Configuration and Advanced Topics.只是一些关于你的思维过程的随机陈述，但关于
@Scott Mitchell 已经提出了这一点，并讨论了由于安全隐患而不这样做的原因。
我觉得值得指出为什么这没有意义（即使不考虑泄露信息的安全影响）。您生成表单身份验证票证（cookie）的原因是您让 ASP.NET 使用该票证在该用户浏览器上标记，让您确认这是已通过身份验证的指定用户。
通过向他们发出票据，您这样做是为了暗示他们不需要像之前那样进行身份验证。
一个很好的类比是，您去一家酒吧，在进去的路上，保镖扫描了您的身份证，以确保您的身份证是合法的并且您已年满 21 岁。 确认后，他们会给您一条腕带，是某种颜色/设计。
使用腕带，您可以离开大楼吸烟，然后绕开队伍返回大楼内，并且需要扫描您的身份证件，以便您当天返回。现在，如果您回家，但上床睡觉时没有摘下腕带（例如让浏览器整夜打开），您第二天会回到酒吧并尝试出示腕带以绕过排队。此时，您被拒绝了，因为您有昨晚的腕带，并被告知要排到队伍后面并再次获得授权。
Just some random statements about your thought process, but in regards to
@Scott Mitchell brought this up already and discussed reasons to not do this due to security implications of this.
I felt it would be worth pointing out why this would not make sense (even disregarding security implications of leaking information). The reason you are generating a forms authentication ticket (the cookie) is that you letting ASP.NET stamp this users browser with that ticket that lets you acknowledge this is the specified user that has already been authenticated.
By issuing them a ticket you are doing so to imply they do not need to be authenticated as they have already been previously.
A good analogy to this is you goto a bar, on your way in you get your id scanned by the bouncer to make sure your id is legitimate and that you're over 21. Upon confirmation of this, they give you a wrist band that is a certain color / design.
With your wrist band you are able to leave the building to smoke and return inside circumventing the line and the need to have your id scanned allowing you to return that day. Now should you go home, but not take the wrist band off when you goto bed (like leaving the browser open over night) you come back to the bar the next day and attempt to show your wrist band to bypass the line. At this point you're rejected because you have last nights wrist band and are told to get to the back of the line and get authorized again.
如果将 DisplayRememberMe 属性设置为 false，则 cookie 将不会保留在客户端计算机上。然后它将被存储在内存中。
如果您使用 HTTPS/SSL，它将在通往客户端计算机的途中受到保护。
那么只剩下理论上的可能性了：
随后破解 cookie 上的加密。
可能有一些更简单的方法来攻击您的系统。
http://msdn.microsoft.com/en-us/library/ms998310.aspx
If you set the DisplayRememberMe property to false the cookie will not be persisted on the client machine. It will then just be stored in memory.
If you use HTTPS/SSL it will be protected on the way to the client machine.
There are then only theoretical possibilities left:
Followed by breaking the encryption on the cookie.
There are probably some easier ways to attack your system.
http://msdn.microsoft.com/en-us/library/ms998310.aspx