是否有理由编写自己的身份验证而不是使用 Forms Security
在 ASP.Net 中，是否有理由直接进行自己的身份验证而不是使用 Forms Security（并编写自定义提供程序）？
Forms Security 存在哪些限制以及为什么有人想要编写自己的身份验证？
In ASP.Net, is there ever a reason to flatly make your own authentication instead of using Forms Security(and writing a custom provider)?
What limitations exist to Forms Security and why would someone want to write their own authentication?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
开箱即用的提供程序的限制之一是 ProfileProvider。它将用户的所有个人资料信息存储在单个数据库字段中，因此很难直接查询。
幸运的是，Scott Guthrie 的博客中描述了一个很好的基于表的提供程序：
http://weblogs.asp.net/scottgu/archive/ 2006/01/10/435038.aspx
但一般来说，我会使用标准的会员提供程序和控件。它们经过了良好的测试，并且节省了大量的编码。
除此之外，对所有 Id 使用 Guid 让我很恼火，因为我更喜欢整数。我知道，Guids 不仅限于数十亿用户，但我的网站还没有那么多人注册。
One of the limitations of the out-of-the-box providers is the ProfileProvider. It stores all of the profile information for a user in a single database field, making it difficult to query directly.
Luckily there is a good Table based provider described here in Scott Guthrie's blogg:
http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx
But generally, i would use the standard Membership provider and controls. They are well tested and they save a lot of coding.
Apart from that, the use of Guids foir all of the Ids annoys me as I prefer ints. I know, Guids are not limited to a couple of billion users, but none of my sites have had that many people register yet.
我广泛使用了 ASP.NET Membership，并用 .NET 编写了多个网站安全方案。
我不知道 .NET 会员资格中存在任何重大安全漏洞。存在一些不同的问题，例如将登录凭据存储在数据库中，但对于大多数目的，您可以配置成员资格选项，因此相对安全。您可以添加密码盐、最小/最大传递长度、复杂性选项、传递尝试等。在一些较大的公司中，他们更喜欢使用 ActiveDirectory 或 Kerberos 身份验证，因为帐户可以由域或区域管理员控制。 .NET 成员资格确实支持这些身份验证方法。
我在使用它时遇到的最大问题是：
不过，与丹尼尔的观点一致，对于大多数用途来说，它工作得很好，并且会为您节省大量工作。它已经过测试，有大量的选项，而且运行良好。
I've used ASP.NET Membership extensively and have written several website security schemes in .NET.
I don't know of any gaping security holes in .NET Membership. There are some various concerns such as storing login credentials in a database, but for most purposes you can configure the Membership options so it's relatively safe. You can add password salt, minimum/max pass length, complexity options, pass attempts, etc. In some larger companies they prefer to use ActiveDirectory or Kerberos authentication because the accounts can be controlled by domain or zone admins. .NET Membership DOES support those authentication methods.
The biggest issues I have run into using it are:
In agreement with Daniel, though, for most purposes it works fine and will save you a lot of work. It's tested, it has a truckload of options, and it works well.
编写自己的登录控件长期以来一直是灾难的根源。事实上，我认为它连续几年被标记为 OWASP 十大（安全）问题。
Writing your own login controls has long been a recipe for disaster. In fact, I think it was flagged as an OWASP Top 10 (security) problem for a couple of years running.