什么可以解决 OpenID 的安全问题
我在 OpenID 方面遇到的问题是，任何人都可以建立一个类似于 yahoo/google 表单的表单，并引导用户在那里并设置密码。这会影响我作为用户（尽管我可以小心），但它会影响 OpenID 提供商。可以采取什么措施来防止这种情况发生？除了教育用户查看 URL 之类的之外。我的意思是通过技术方法来防止这种情况发生。
The problem I have with OpenID is how anyone can put up a form that looks like yahoo/google's form and direct users there and steel the passwords. This affects me as a user (though I can be careful about it), but it affects OpenID providers. What can be done to prevent this? Other than educating the users to look at the URL and all this. I mean a technical way to prevent this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这个问题被称为可信路径，并且几乎没有好的解决方案。维基百科文章中链接的 Ka-Ping Yee 的论文对此进行了很好的处理。
This problem is called Trusted Path and there are few good solutions to it. Ka-Ping Yee's thesis, linked in that wikipedia article includes a good treatment of it though.
这本质上可以归结为网络钓鱼攻击。从技术角度来看，这不是可以轻易避免的事情，除非所有涉及的身份验证方之间都达成了共同协议。一些银行现在显示用户选择的图像。实际上，银行试图证明他们是真正的银行（因为他们知道您在注册过程中选择的图像），并且用户向银行提供密码以表明他们有权访问该帐户。
That essentially boils down to a phishing attack. This isn't something that can easily be prevented from a technical point of view, unless there's mutual agreements between all authentication partys involved. Some banks now show an image that the user selected. In effect, the bank is trying to prove that they are that actual bank (because they know what image you chose during registration) and the user is providing the bank with a password to show that they are authorized to access the account.
我一直喜欢的一个想法（不仅因为这是我的想法）是，您可以通过永远不允许用户拥有自己的密码来解决这个问题。该策略是，为了登录，用户访问他们想要登录的网站，并请求身份验证令牌。然后，令牌会通过电子邮件发送给他们，在一段时间内有效，他们只需单击链接即可登录。
不过，这种方法的明显问题是：您的电子邮件无法做到这一点。所以，它稍微转移了问题。但是，如果您通过客户端证书方法向您的电子邮件提供商或任何人进行身份验证：http:// en.wikipedia.org/wiki/Mutual_authentication，并考虑一些其他事情（即确保登录链接的详细信息的传输不被拦截等），它至少是“有趣的”想想。
但是，一般来说，解决问题的方法是：对交易双方进行身份验证；即，在向您发送您关心的任何内容之前，请确保您正在访问的网站是您想要的网站。
One idea I've always liked (not only because it's my idea), is that you can solve this problem by never allowing the user to have their own password. The strategy would be that, to log in, the user visits the website they want to log in to, and requests an authentication token. The token is then emailed to them, valid for a little bit, and they just click the link to log in.
The obvious problems to this, approach, though, are that: Your email can't do it. So, it's shifting the problem slightly. But, if you authenticate with your email provider, or whoever, via the client-side certificate approach: http://en.wikipedia.org/wiki/Mutual_authentication, and give some other things a bit of thought (i.e. ensuring transmission of the details of the login link aren't intercepted, etc), it's at the very least "interesting" to think about.
But, in general, the way to solve your problem is: authenticate both sides of the transaction; i.e. ensure that the website you are talking to is the one you want, before sending it anything you care about.
我不喜欢 openID 身份验证协议，但 SSL（这是一种可行的方法）使网站变得可信，浏览器应该真正开始拥有像 google、yahoo、youtube、facebook 等使用该技术的网站列表，并且在未先获得适当证书的情况下拒绝打开网站。
这是一个有点超出你的问题范围的解决方案，但也解决了它。因为想一想......如果 StackOverflow 开始使用 SSL，为什么浏览器应该允许连接到它而不首先获得适当的证书？有道理吧？
一项技术，解决所有问题。
I'm not into the openID authentication protocol but SSL (is the way to go, it) makes the website trustable and the browsers should really start to have like lists of websites like google, yahoo, youtube, facebook etc that use that technology and refuse to open the website without getting the proper certificate first.
Thats a solution that goes a little bit beyond the scope of your problem but also solves it. Because think about this... if StackOverflow starts using SSL why the browser should allow connections to it without getting a proper certificate first? Make sense right?
One single technology, all the problems solved.