OAuth 和网络钓鱼漏洞，它们是否紧密地联系在一起？
我最近用 OAuth 做了很多工作，我不得不说我真的很喜欢它。我喜欢这个概念，并且喜欢它如何为您的用户提供较低的进入门槛，将外部数据连接到您的站点（或者让您提供数据 API 以供外部使用）。就我个人而言，我总是对要求我直接向他们提供另一个网站的登录信息的网站犹豫不决。 OAuth“网络代客密钥”方法很好地解决了这个问题。
不过，我（和许多其他人）看到的最大问题是，标准 OAuth 工作流程鼓励网络钓鱼攻击利用的相同类型的行为。如果您训练您的用户，重定向到站点以提供登录凭据是正常行为，那么网络钓鱼站点很容易利用这种正常行为，而是重定向到他们捕获您的用户名和密码的克隆站点。
您已经采取了哪些措施（或已采取措施）来缓解这个问题（如果有的话）？
您是否告诉用户手动登录提供的网站，而不使用自动链接或重定向？ （但这会增加进入门槛）
您是否尝试教育您的用户？如果是，何时以及如何？用户必须阅读的任何冗长的安全解释也会增加进入门槛。
还有什么？
I've been doing a fair bit of work with OAuth recently, and I have to say that I really like it. I like the concept, and I like how it provides a low barrier-of-entry for your users to connect up the external data to your site (or for you to provide the data apis for consumption externally). Personally, I've always balked at sites that ask me to provide my login for another website to them directly. And OAuth "valet key for the web" approach solves this nicely.
The biggest problem I (and many others) see with it though, is the standard OAuth work-flow encourages the same type of behaviors that phishing attacks use to their advantage. If you train your user that it is normal behavior to be redirected to a site to provide login credentials, then it is easy for a phishing site to exploit that normal behavior but instead redirect to their clone site where they capture your username and password.
What, if anything, have you done (or seen done) to alleviate this problem?
Do you tell the users to go and login to the providing site manually, without automatic links or redirection? (but then this increases the barrier of entry)
Do you attempt to educate your users, and if so, when and how? Any lengthy explanation of security that the user has to read also increases the barrier of entry.
What else?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我相信 OAUth 和网络钓鱼有着不可分割的联系，至少在 OAuth 目前的形式中是这样。已经有一些系统可以防止网络钓鱼，最引人注目的是 HTTP（暂停笑声......），但显然它不起作用。
网络钓鱼是针对需要用户名/密码组合的系统的非常成功的攻击。只要人们使用用户名和密码进行身份验证，网络钓鱼就永远是一个问题。更好的系统是使用非对称加密技术进行身份验证。所有现代浏览器都内置了对智能卡的支持。您无法对某人钱包中的卡进行网络钓鱼，并且入侵用户的桌面也不会泄露私钥。非对称密钥对不一定位于智能卡上，但我认为它构建的系统比纯粹用软件实现的系统更强大。
I believe that OAUth and phishing they are inexorably linked, at least in OAuth's current form. There have been systems in place to prevent Phishing, most notability HTTPs (pause for laughter...), but obviously it doesn't work.
Phishing is a very successful attack against systems that require username/password combos. As long as people use usernames and password for authentication phishing will always be a problem. A better system is to use asymmetric cryptography for authentication. All modern browsers have built in support for smart cards. You can't phish a card sitting in someones wallet and hacking the user's desktop won't leak the private key. The asymmetric keypair doesn't have to be on a smartcard, but I think that it builds a stronger system than if it where purely implemented in software.
您在被重定向到的网站上有一个帐户，他们不应该实施反网络钓鱼措施，例如签名短语和图像吗？这还利用了用户从通常使用这些措施的银行等处获得的任何现有培训。
一般来说，登录页面应向用户提供用户友好的共享秘密，以确认他们正在登录的站点的身份。
正如 Jingle 所指出的，ssl 证书可用于身份验证，但在这种情况下，用户不能将证书直接从网站加载到 Web 浏览器中作为 OAuth 设置过程的一部分吗？如果已经与该站点建立了信任关系，我不确定是否有必要进一步求助于 CA。
You have an account with the site you are being redirected to, shouldn't they be implementing anti-phishing measures such as a signature phrase and image? This also leverages any existing training the users have received from e.g. banks who commonly use these measures.
In general, the sign-in page should present user-friendly shared secrets to the user to confirm the identity of the site they are logging into.
As Jingle notes, a ssl certificate could be used for authentication, but in this case couldn't the user load a certificate directly from the site into their web browser as part of the OAuth setup process? If a trust relationship has already been established with the site, I'm not sure further resort to a CA is necessary.
有一些技术可用于避免或减少网络钓鱼攻击。我列出了一个廉价选项的清单：
上面列出的所有选项很大程度上取决于用户对信息安全和隐私的教育。仅在第一次身份验证时出现的向导可以帮助实现此目标。
There are some techniques that can be used to avoid or diminish phishing attacks. I made a list of cheap options:
All options listed above highly depends on user education about information security and privacy. Wizards that appears only on the first authentication can helps achieve this goal.
延伸一下代客泊车的类比：你怎么知道你可以信任代客泊车，并且他/她不仅仅是一个试穿者？你实际上并不知道：你只是根据上下文做出（可能是无意识的）判断：你了解这家酒店，你以前去过那里，你甚至可能认出你要给钥匙的人。
同样，当您使用 OAuth（或 OpenID）登录时，您会将用户重定向到他们应该熟悉的站点/URL，因为他们正在从他们知道的该站点提供凭据。
To extend the valet analogy: how do you know you can trust the valet, and that he/she is not just someone trying it on? You don't really: you just make that (perhaps unconscious) judgement based on context: you know the hotel, you've bene there before, you might even recognise the person to whom you're giving your key.
In the same way, when you sign in using OAuth (or OpenID), you are redirecting the user to a site/URL which should be familiar to them, seeing as they are providing their credentials from that site which is known to them.
这不仅仅是 OAuth 的问题，也是 OpenID 的问题。当然，更糟糕的是，使用 OpenID，您向提供商提供了一个网站，如果您还没有伪造的网站，那么很容易自动抓取该网站并生成一个网站，然后您也可以将其引导给您的用户。
幸运的是，没有什么严肃的事情使用 OpenID 来进行身份验证 - 博客文章、flickr 评论并不是一个有趣的目标。
现在，OpenID 正在采取缓解措施，因为他们开始开发信息卡支持，其中客户端软件形式的固定 UI 将提供安全的身份“钱包”，但 MS 似乎已经在信息卡方面失败了卡，即使这是他们的（开放）规范。
它不会很快消失。
This isn't just an OAuth problem, it's OpenID's problem as well. Worse of course with OpenID you're giving a web site your provider, it's easy to automatically scrape that site if you don't have a bogus one already and generate one which you then direct your user too.
It's lucky that nothing serious uses OpenID to authenticate - blog posts, flickr comments just aren't a juicy target.
Now OpenID are going somewhere to mitigation as they start to develop their Information Card support, where a fixed UI in the shape of client side software will provide an identity "wallet" which is secure, but MS appear to have dropped the ball themselves on Information Cards, even though it's their (open) spec.
It's not going away anytime soon.
像 ssl 认证一样认证 oAuth 提供商怎么样？只有经过认证的 oAuth 提供商才是值得信赖的。但问题是，与 ssl 认证一样，CA 很重要。
What about to certify the oAuth provider just like the ssl certification? Only certified oAuth provider is trustworthy. But the problem is, as with ssl certification, the CA matters.