英文:
Google App Engine Go - using OpenID, should I also use captcha?
问题
目前我正在使用golang开发一个GAE应用程序，允许用户使用Google的OpenID登录服务。每个账户显然都会映射到一个Google账户。我应该为用户注册实现验证码，还是使用OpenID已经可以防止机器人攻击了呢？
英文:
Currently I'm developing a GAE application in golang that would allow the users to log into the service using OpenID from Google. Each account would be mapped to one Google account obviously. Should I implement captcha for user registration, or does using the OpenID already prevent the service from a bot attack?
答案1
得分: 3
你是否接受任何OpenID？那么这样的保护是不够的。任何人都可以在自己的域上建立一个OpenID网站，使用脚本创建数十亿个账户，并使用其中一个账户登录你的网站。
你是否只接受特定的OpenID提供商？那么你并没有按照OpenID的原意使用它（实际上，这与它创建的初衷恰恰相反）。但是答案是：你是否相信OpenID提供商在账户创建时已经进行了自己的尽职调查，以防止垃圾账户的产生？
无论如何，你可能会发现验证码是一个很差的解决方案，而且目前所有的实现都是有问题的（但这是一个完全不同的话题）。
英文:
Are you accepting any OpenID? Then this is not sufficient protection. Anyone can put up an OpenID site on their own domain, use a script to create a billion accounts, and log in with one of them on your site.
Are you accepting only specific OpenID providers? Then you're not using OpenID as it was meant to be used (and, in fact, expressly the opposite of why it was created). But the answer then would be: do you trust that the OpenID providers have done their own due diligence at the time of account creation to prevent spam accounts?
Regardless, you'll likely find that captcha's a poor solution, and currently all implementations of it are broken (but that's a whole different topic).
答案2
得分: 1
首先，对于机器人攻击的担忧实际上是一种初步的预防措施。解析CSRF令牌（无论如何都应该使用）和处理cookie已经足够让攻击者感到痛苦了。我怀疑有人会费心去设置自己的OpenID提供者，这是唯一的方法。
其次，App Engine的OpenID联合登录是用户API的功能，而不是Go运行时的功能 - 您可以使用任何OP（Facebook，Yahoo！，Steam... Google）。用户API提供两种模式（可通过应用程序设置进行配置）：OpenID联合登录和Google帐户登录。选择哪种取决于需求。如果您只需要用户的Google帐户，最好使用后者；如果是几乎所有东西的简单无密码登录，选择OpenID。从应用程序的角度来看，两者看起来是相同的。不过，最好的方法是使用OAuth。
回到问题上来，无论是Google帐户API还是OAuth，这些攻击几乎是不可能的，而使用OpenID则稍微简单一些。
https://developers.google.com/appengine/docs/go/users/overview
英文:
First of all, fear of a bot attack is really a preliminary caution. Parsing CSRF tokens (which you should use anyway) and dealing with cookies would already cause enough pain to an attacker. I doubt anyone would trouble himself into setting up very own OpenID provider which is the only way one can do that.
Secondly, App Engine's OpenID Federated Login is the User API feature, not Go runtime's one — you can use any OP with it (Facebook, Yahoo!, Steam... Google). User API provides two modes (configurable via Application Settings): OpenID Federated Login and Google Accounts sign in. Which to pick depends on requirements. If all you need is user's Google account you'd better use the latter, when if it's simple password-less sign in with nearly everything, choose OpenID. From the app's perspective both look identical. Best way to go is OAuth, though.
Getting back on the question, both Google Accounts API and OAuth would make such attacks almost impossible and with OpenID it is a little simpler.
https://developers.google.com/appengine/docs/go/users/overview
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论