*不*使用 asp.net 会员资格提供程序是一个坏主意吗？
不使用内置的 ASP.NET 会员资格提供程序通常是一个非常糟糕的主意吗？
我总是为我的 asp.net 应用程序（面向公众）推出自己的应用程序，并且这样做确实没有遇到任何问题。它有效，并且似乎避免了一层复杂性。我的需求非常基本：设置后，用户必须使用电子邮件地址和密码登录，如果他们忘记了，则会通过电子邮件发回给他们（一个新的）。设置完成后，每个用户帐户几乎不需要做任何事情，但我确实需要为每个用户存储几个额外的字段（全名、电话和其他一些字段等）。需要登录凭据的用户数量很少（通常只有管理员和一些备份），其他人都在未经身份验证的情况下使用该站点。
如果跳过 ASP.NET 会员资格提供程序功能，我可能会错过哪些重大优势？
Is it generally a really bad idea to not use the built-in asp.net membership provider?
I've always rolled my own for my asp.net apps (public facing), and really have not had any problems in doing so. It works, and seems to avoid a layer of complexity. My needs are pretty basic: once setup, the user must use email address and password to login, if they forget it, it will be emailed back to them (a new one). After setup there is little that needs to be done to each user account, but I do need to store several extra fields with each user (full name, telephone and a few other fields etc). The number of users that required login credentials are small (usually just the administrator and a few backups), and everyone else uses the site unauthenticated.
What are the big advantages that I might be missing out on by skipping the asp.net membership provider functionality?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
滚动自己的身份验证系统永远不是一个好主意。有很多方法会导致错误，但在测试中似乎仍然有效，直到一年后，当您发现您的网站在六个月前被破解时。
始终尽可能依赖您的平台为您提供的安全代码，无论是 asp.net 还是其他平台。这样做，系统就会得到更多部署的供应商的支持，这样就可以更容易地发现和修复错误，即使你确实遇到了问题，当你的老板来询问时，你也可以将责任归咎于供应商。更不用说，一旦您第一次使用供应商的解决方案，其他部署将会更快。这才是正确的做法。
ASP.Net Membership 提供程序远非完美，但我向您保证，这比从头开始构建它更好。
Rolling your own authentication system is never a good idea. There are so many ways to get it wrong that still seem to work in testing, until a year later when you find out your site was cracked six months ago.
Always lean as much as possible on the security code provided for you by your platform, be it asp.net or anything else. Do this, and the system is supported by a vendor with many more deployments so that bugs can be found and fixed more easily, and even if you do have a problem you can place the blame on the vendor when your boss comes asking about it. Not to mention that once you get past the first time using your vendor's solution, additional deployments will be faster. This is just the right way to do it.
The ASP.Net Membership provider is far from perfect, but I promise you that it's preferable to building it from scratch.
提供程序模型的优点概述如下，但简要说明如下：
可以通过 web.config 文件中的简单更改来交换提供程序。并不是说您不能编写自己的登录内容来执行相同的操作，而是您可以在将来的某个时刻轻松编写自定义提供程序并将其切换到您的应用程序中，而无需更改应用程序中的任何内容。
提供了所有基础知识。默认的会员提供者具有密码检索、帐户锁定、多种密码加密方法、有效密码限制规则配置和用户管理，全部开箱即用。对于大多数从头开始启动 ASP.Net 应用程序的人来说，仅使用它就可以大大减少设置时间。
您的应用程序的很大一部分已经经过审查。您无需担心调试自己的所有身份验证代码！这意味着，当出现错误时，您通常会在网站中断之前得到修复，并且如果没有修复，您也有能力推卸责任。
The advantages of the provider model are outlined here, but in brief:
Certain out-of-the-box webcontrols are built to use the membership provider model, such as the Login control/view and the Create User Wizard. So you miss out on a 1-step configuration for having a logged-in dashboard for all your pages without writing any code.
Providers can be swapped with a simple change in the web.config file. Not saying you can't write your own login stuff to do the same, but you can easily write a custom provider at some point down the road and switch it into your application without changing a thing in the application.
All the basics are provided. The default membership providers have password retrieval, account locking, multiple password encryption methods, valid password restriction rule configuration and user management, all out of the box. Just using that alone is a huge reduction in setup time for most people starting an ASP.Net application from scratch.
A large component of your application is already vetted. You don't need to worry about debugging all your own authentication code! This means that when there are bugs, you often get fixes before site breaks, and you have the ability to pass the blame if not.
我同意 Ayende 对此的感受：
这也是我的经验。每当我实现自己的会员提供程序（在撰写本文时两次）时，我都会将绝大多数被重写的方法保留为未实现，因为我永远不会调用它们，也不会使用任何 Web 表单使用它们的控件。
如果 Sql 和 Active Directory 提供程序能够满足您的所有需求，那么它们就很棒。但如果他们不这样做，而您正在考虑实施这些提供程序，那么可能有更好的方法适合您。
不要将 MembershipProvider 与 FormsAuthentication 混淆，我仍然经常依赖它来进行我的应用程序。该机制负责将用户的身份验证令牌包装在 cookie 中并在客户端和服务器之间传递。据我所知，FormsAuthentication 没有任何问题，我不建议重新发明它。
如果您不想实施数十个 MembershipProvider 方法、RoleProviderMethods 和 ProfileProvider 方法然后只需实施 IPrincipal 和 IIdentity 并执行您需要执行的操作。 这是一个让这两个接口与 FormsAuthentication 一起使用的示例，这很简单。
另外，请注意，您需要明智地存储用户的凭据。 SqlMembershipProvider
确实至少可以存储散列加盐密码。确保您至少也这样做。 这是一个不错的一段代码来帮助解决这个问题。注意使用的慢速哈希算法。不要吸毒。更新 (2013-12-16)
自从我写这篇文章以来，ASP.net 中的情况发生了变化。 ASP.NET Identity 取代了以前的成员资格功能。
我的建议是使用新东西，因为：
API比以前稍微复杂一些，但是更加灵活。
I agree with Ayende's feelings about this:
This is also my experience. Anytime that I've implemented my own membership provider (twice at the time of this writing) I left the vast majority of the overridden methods unimplemented, because I was never going to call them and I wasn't using any of the web-forms controls that make use of them.
The Sql and Active Directory providers are great if they meet all of your needs. But if they don't and you are thinking of implementing the providers, there may be a better way for you.
Don't confuse the MembershipProvider with FormsAuthentication, which I still rely on regularly for my applications. This is the mechanism that takes care of wrapping the user's authentication token in a cookie and passing between client and server. There's nothing wrong with FormsAuthentication as far as I know and I wouldn't suggest reinventing it.
If you don't want to implement dozens of MembershipProvider methods, RoleProviderMethods, and ProfileProvider methods then just implement IPrincipal and IIdentity and just do what you need to do. Here's an example of getting those 2 interfaces working with FormsAuthentication, which is trivial.
Also, be aware that you need to be smart about storing your users' credentials. The SqlMembershipProvider
doescan at least store hashed salted passwords. Be sure you at least do the same. Here's a nice piece of code to help out with this. Notice the slow hashing algorithm used. Don't do drugs.update (2013-12-16)
Things have changed in ASP.net since I wrote this. ASP.NET Identity replaces the Membership features from before.
My recommendation is to use the new stuff because:
The API is slightly more complicated than before, but more flexible.
如果您有一个行之有效的解决方案，请坚持下去。 “如果某件事有效，就不要修复它”等等。否则，考虑一下会员 API 背后的程序员时间、QA 时间和用户时间是您自己所能想到的任何东西的数千倍。
If you've got a solution that works well, stick with it. "If something works, don't fix it" and all that. Otherwise, consider that the Membership API has thousands of times the number of programmer-hours, QA-hours and user-hours behind it than anything you could come up with on your own.
您可能会从以下其他常见问题中获得一些见解：
哪个您使用的身份验证和授权方案 - 为什么？
Microsoft 会员提供商与自定义提供商与完整的自定义登录系统
任何人使用ASP .NET 会员资格？
.Net 会员资格的替代方案
You might get some insight from these other popular questions:
Which authentication and authorization schemes are you using - and why?
Microsoft Membership Provider Vs Custom Provider Vs Complete Custom Login System
Anyone uses ASP .NET Membership?
Alternatives to .Net Membership
会员资格不仅仅是会员资格（登录名、电子邮件、密码及其相关功能）。 Aspnet 将成员身份与配置文件分开，并且它们可以集成。个人资料就是您所说的“额外字段”。
即使您没有会员资格，您也可以拥有经过一些自定义的匿名个人资料。例如，用户可以设置首选项，返回站点，并且仍然拥有它们，但仍然不注册。然后，当您注册时，可以迁移匿名个人资料并与您的新会员资格相关联。
当你跳过它时，你基本上会错过它。
此外，如果您选择使用内置或第三方控件来利用会员资格和个人资料，您也会错过它。
您可以实现一个提供程序，而不是一次性删除所有提供程序模型。
There is more to membership then just membership (login, email, password, and functionality around it). Aspnet separates membership from profile, and they can be integrated. Profile is everything you call 'extra fields'.
You can have an anonimous profile with some customization, even if you don't have a membership. For example, a user could setup preferences, return to site, and still have them, but still don't register. Then when you register, anonimous profile can be migrated and associated with your new membership.
That is what you basically miss when you skip it.
Also, if you choose to use build in or third party controls which make use of membership and profiles, you miss it too.
You could implement a provider, instead of dropping the provider model all at once.
就您而言，经过身份验证的用户是例外，而不是常态，因此推出您自己的用户可能不会有什么坏处。
.net 提供的一件事是防止暴力攻击，如果有人试图暴力破解管理员密码，管理员帐户将被锁定。
In your case, authenticated users are the exception, not the norm, so it probably doesn't hurt to roll your own.
One thing .net provides is a brute force attack prevention, in case someone tries to brute force the admin password, the admin account will be locked out.
我对内置 ASP.Net 身份验证的复杂性感到痛苦。我厌倦了必须为我永远不会使用的功能编写代码。 （以及留下一堆 NotImplemented 函数）。我还厌倦了使用 GUID 以外的其他东西以及在每个页面加载时进行多个数据库往返（仅用于身份验证）的困难......所以，我推出了自己的。它的名称为 FSCAuth 并且获得了 BSD 许可。
我已经使它比 ASP.Net 的内置身份验证更难出错。所有 cookie 处理和实际散列都留给 FSCAuth 的核心，而您只需担心将用户存储在数据库中并控制需要在哪些页面上进行身份验证。
如果您面临 ASP.Net 内置身份验证的问题并推出自己的身份验证，我建议您先看看我的身份验证库，如果不只是将其用作起点的话。
I feel your pain with the complexities of the built-in ASP.Net authentication. I was tired of having to write code for features that I was never going to use. (as well as leaving a bunch of NotImplemented functions). I also was sick of the difficulties of using something other than a GUID and having multiple database roundtrips on each page load(just for authentication)... So, I rolled my own. It's named FSCAuth and it's BSD licensed.
I've made it a bit harder than ASP.Net's built in authentication to get wrong as well. All of the cookie handling and actual hashing is left to the core of FSCAuth, while all you have to worry about is storing users in the database and controlling what pages need to be authenticated on.
If you're facing the question of ASP.Net's built-in authentication and rolling your own, I suggest you give my authentication library a look first, if not just using it as a starting point.
如何保存用户的密码？如果您以纯文本格式保存，那么这是一个很大的风险。 ASP.NET 会员系统的优点之一是它通过散列法对密码进行开箱即用的加密。
How do you save the users' passwords? If you're saving in plain text, that's a major risk. One advantage of the ASP.NET Membership system is that it encrypts passwords by hashing, out of the box.
我建议不要使用 ASP.Net Membership Provider，特别是 SQL Server 提供程序。它有几个重大问题，并且不能很好地符合现代标准。他们根本不会在密码更改时轮换盐，如果存在开放数据库妥协，这会导致持续攻击。他们没有完善的密码生成器，这导致生成的密码的熵低于期望的值。他们也没有足够的现成的密码哈希算法来满足现代标准（尽管这是可以克服的。）
I would recommend against using the ASP.Net Membership Provider, particular the SQL Server provider. It has several significant problems and does not hold up to modern standards well. They do not rotate the salt at all on password change, which opens up persistence of attack if there is an open DB compromise. They do not have a well done password generator which leads to lower than desirable entropy in generated passwords. They also do not have a sufficient password hashing algorithm out of the box for modern standards (though this can be overcome.)