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

【问题标题】：Is there ever a reason to write your own authentication instead of using Forms Security是否有理由编写自己的身份验证而不是使用 Forms Security
【发布时间】：2011-03-24 19:31:45
【问题描述】：

在 ASP.Net 中，是否有理由直接进行自己的身份验证而不是使用 Forms Security（并编写自定义提供程序）？

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

【问题讨论】：

标签： asp.net security forms-authentication

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

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

我在使用它时遇到的最大问题是：

API 本身并没有真正抽象到它需要的水平（和能力）。如果您需要以编程方式删除用户或重置密码，虽然完全有可能，但如果您不使用 .NET 登录/帐户控件，这比您预期的要多，您可能不会因为它们适合面向用户，而不是面向帐户管理。
没有用于访问帐户的内置 Web 服务，这并不总是必要的，但它会很好。
管理帐户很麻烦，因为您必须为其编写自己的控件，而第 1 点使这成为一项繁琐的任务。您可以购买多个第三方控件以使其更容易忍受。
通过子组/子帐户、分层角色等来扩展功能可能非常困难且具有挑战性。

不过，与 Daniel 一致，它在大多数情况下都可以正常工作，并且可以为您节省大量工作。它已经过测试，有很多选择，而且效果很好。

【讨论】：

【解决方案3】：

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

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

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

除此之外，在所有 Id 中使用 Guid 让我很恼火，因为我更喜欢 int。我知道，Guid 不仅限于几十亿用户，但我的网站还没有那么多人注册。

【讨论】：