使用第三方身份验证的应用程序的密码？
我有一个 ASP.NET MVC 应用程序，刚刚将 RPX 第三方联合身份系统集成到其中。 集成工作正常，但我在思考在 ASP.NET 级别如何处理它时遇到了一些困难。
由于身份是在外部处理的，因此我的应用程序不需要密码：我从不收到用户的密码，只收到他们的身份。 但是，ASP.NET 会员资格提供程序需要传递密码才能创建用户、登录用户等。
我一直在考虑在创建时使用 new Guid()，但是这需要调用数据库来检索用户的密码，然后才能通过会员资格提供商登录用户。 我可以为每个用户使用相同的密码，以便提前知道密码，但我担心这会使我的用户数据不安全。
我很想听听其他网站如何处理这个问题，例如 StackOverflow。
[另请参阅我的其他问题，有关此类应用程序的会员提供商。]
I have an ASP.NET MVC application into which I have just integrated the RPX third-party federated identity system. The integration is working ok, but I'm having some difficulty wrapping my head around what to do with it at the ASP.NET level.
Because the identity is handled externally, I have no need for passwords in my app: I never receive the user's password, just their identity. However, the ASP.NET Membership Provider stuff requires passwords be passed around in order to create a user, sign a user in, etc.
I've been considering using new Guid() at creation time, but this would require a call to the database to retrieve the user's password before I could sign the user in via the membership provider. I could use the same password for each user so that it's known in advance, but I'm concerned that this would make my user's data insecure.
I'd be interested to hear how other sites handle this issue, e.g., StackOverflow.
[Please also see my other question, regarding membership providers for such an app.]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先确保没有人可以使用用户名和密码直接针对您的数据库进行身份验证 - 我想这已经是这种情况，因为您正在使用 RPX 进行实际身份验证，并且只有在您已经完成身份验证后才调用 ASP.NET 成员资格提供程序建立了用户的身份。
然后，存储在您这边的密码就变得无关紧要，因为它不是秘密 - 如果我可以算出您这边某人的密码，就不会突然危及他们的数据，因为我仍然无法使用该信息登录。 用户的秘密由第三方提供商管理，而不是您。
因此，您不妨存储最方便的内容（即众所周知的虚拟值） - 您也可以关闭会员资格提供程序上的密码加密，以在服务器上取回一些周期。 加密/散列不用于验证任何人身份的值是没有意义的。
Start by ensuring that noone can authenticate directly against your database using a username and password - I imagine this is already the case as you are using RPX to do the actual authentication, and you are only invoking the ASP.NET membership provider once you have already established the user's identity.
Then, the password stored on your side becomes immaterial, because it's not a secret - if I can work out what someone's password is on your side, it doesn't suddenly compromise their data because I still can't login using that information. The user's secret is managed by the 3rd party provider, not you.
So you might as well store what is most convenient (ie a well-known dummy value) - you might as well turn off password encryption as well on the membership provider, to get back some cycles on the server. No point in encrypting / hashing values that aren't used to verify anyone's identity.
那么为什么要使用 ASP.NET 会员资格呢？ 它并不真正适合您正在做的事情，即第三方身份验证。 也许您可以查看 dotnetopenid 项目 和示例，因为它们有一个经典的 asp.您可以针对 mvc 修改哪个网站示例？ 他们有一个 wiki 也许是 google dotnetopenid mvc？
Why use asp.net membership then? It doesn't really fit into you what you are doing which is 3rd party authentication. Maybe you could have a look at the dotnetopenid project and examples as they have a classic asp.net site example which you could modify for mvc? They have a wiki here Maybe google dotnetopenid mvc?