是否有理由编写自己的身份验证而不是使用Forms Security

Question

在ASP.Net中，有没有理由坚持自己的身份验证而不是使用Forms Security（以及编写自定义提供程序）？

Forms Security存在哪些限制？为什么有人想编写自己的身份验证？

Answer 1

开箱即用的提供商的一个限制是ProfileProvider。它将用户的所有配置文件信息存储在单个数据库字段中，从而难以直接查询。

幸运的是，在Scott Guthrie的博客中有一个很好的基于表格的提供者： http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx

但一般来说，我会使用标准的会员提供商和控件。它们经过了很好的测试，可以节省大量代码。

除此之外，使用Guids对所有的Ids都很烦恼，因为我更倾向于使用。我知道，Guids并不仅限于几十亿用户，但我的网站都没有让很多人注册。

Answer 2

我广泛使用了ASP.NET Membership，并在.NET中编写了几个网站安全方案。

我不知道.NET Membership中存在任何安全漏洞。存在一些各种问题，例如将登录凭据存储在数据库中，但是对于大多数目的，您可以配置成员资格选项，因此它相对安全。您可以添加密码盐，最小/最大传递长度，复杂性选项，传递尝试等。在一些较大的公司中，他们更喜欢使用ActiveDirectory或Kerberos身份验证，因为帐户可以由域或区域管理员控制。 .NET Membership支持这些身份验证方法。

我遇到的最大问题是：

1. API本身并没有真正抽象到它需要的水平（和力量）。如果您需要以编程方式删除用户或重置密码，虽然完全可能，但如果您不使用.NET登录/帐户控件，那么它的工作量会比您预期的要多，而您可能不会因为它们是适合的对用户而不是帐户管理。
2. 没有内置的Web服务来访问帐户，这并不总是必要的，但它本来不错。
3. 管理帐户是一个负担，因为你必须为它编写自己的控件，点＃1使这个任务变得很麻烦。您可以购买多个第三方控件以使其更具可忍性。
4. 使用子组/子帐户，分层角色等功能扩展功能可能非常具有攻击性和挑战性。

与丹尼尔达成协议，但在大多数情况下，它运作良好，可以为您节省大量的工作。经过测试，它有很多选项，而且效果很好。

Answer 3

编写自己的登录控件长期以来一直是灾难。事实上，我认为它在几年的运行中被标记为OWASP十大（安全）问题。