在目前的概念中，CAPTCHA是不完善的，而且经常很容易被绕过。现有的解决方案没有一个是有效的——GMail最多只有20%的成功率。

实际情况要糟糕得多，因为这个统计数据只使用了OCR，还有其他方法可以绕过它——例如，CAPTCHA代理和CAPTCHA农场。我最近在OWASP做了一个关于这个主题的演讲，但是ppt还没有上线…

虽然CAPTCHA不能以任何形式提供实际的保护，但如果你想要阻止随意路过的垃圾，它可能足以满足你的需求。但它甚至无法阻止半专业的垃圾邮件发送者。

通常，对于一个有价值的资源需要保护的网站，你需要三个方面的方法:

限制来自认证用户的回复，不允许匿名帖子。 最小化(而不是阻止)来自认证用户的少数垃圾帖子-例如基于声誉的。人工版主在这里也可以提供帮助，但随后你会遇到其他问题——即充斥(甚至淹没)版主，而一些网站更喜欢开放…… 使用服务器端启发式逻辑来识别类似垃圾邮件的行为，或者更好的非人类行为。

验证码可以在第二个方面提供一点帮助，只是因为它改变了经济状况——如果其他方面都到位了，那么为了在如此少量的垃圾邮件中成功突破验证码(最低成本，但仍然是成本)就不再值得了。

同样，不是所有的垃圾邮件(和其他垃圾邮件)都是计算机生成的-使用CAPTCHA代理或农场坏人可以让真人发送垃圾邮件给你。

验证码代理是指他们将你的图像提供给其他网站的用户，如色情网站、游戏网站等。

验证码农场有很多廉价的劳动力(印度、远东等)来解决这些问题……通常每1000个验证码解决2-4美元。最近在Ebay上看到了这个帖子……

这里的一些人声称解决方案从未被机器人破坏过。我认为问题在于，你也不知道有多少人没有通过“验证码”。

一个网站不能变得对人类用户非常不友好。这似乎是在互联网上做生意的代价，你必须处理一些手工工作来忽略垃圾邮件。拒绝用户的验证码(或类似的系统)比根本没有验证码更糟糕。

Admittedly, StackOverflow has a very knowledgeable audience, so a lot more creative solutions can be used. But for more run-of-the-mill sites, you can really only use what people are used to, or else you will just cause confusion and lose site visitors and traffic. In general, CAPTCHAs shouldn't be tuned towards stopping all bots, or other attack vectors. That just makes the challenge too difficult for legitimate users. Start out easy and make it more difficult until you have spam levels at a somewhat manageable level, but not more.

最后，我想回到基于图像的解决方案:你不需要每次都创建一个新的图像。您可以预先创建大量(可能几千个?)，然后随着时间的推移慢慢地更改这个集合。例如，每10分钟或每小时过期100个最旧的图像，并用一组新的图像替换它们。对于每个请求，从整个验证码集中随机选择一个验证码。

当然，这无法承受直接攻击，但正如前面多次提到的，大多数验证码都无法承受。不过，这足以阻止随机机器人。

简单的文字听起来很棒。贿赂社区来做这项工作!如果您像我一样相信，SO代表积分可以衡量用户帮助网站成功的承诺，那么提供声誉积分来帮助网站免受垃圾邮件发送者的侵害是完全合理的。

Offer +10 reputation for each contribution of a simple question and a set of correct answers. The question should suitably far away (edit distance) from all existing questions, and the reputation (and the question) should gradually disappear if people can't answer it. Let's say if the failure rate on correct answers is more than 20%, then the submitter loses one reputation point per incorrect answer, up to a maximum of 15. So if you submit a bad question, you get +10 now but eventually you will net -5. Or maybe it makes sense to ask a sample of users to vote on whether the captcha questionis a good one.

最后，就像每日信誉上限一样，假设没有用户可以通过提交验证码问题获得超过100个声誉。这是对此类贡献的权重的合理限制，也有助于防止垃圾邮件发送者在系统中植入问题。例如，你可以选择与提交者的声誉成比例的概率而不是相等概率的问题。乔恩·斯基特，请不要提交任何问题。

@rob

蜜罐验证码怎么样? 哇，这么简单!看起来不错!尽管他们强调了无障碍问题。你认为这在SO会是一个问题吗?我个人觉得很难想象开发人员/程序员阅读屏幕有困难到需要屏幕阅读器的地步。

有些开发者不仅是法律上的盲人，而且是100%的盲人。手杖和辅助犬。我希望这个网站能支持他们在一个合理的方式。

然而，使用蜜罐验证码，您也可以放置一个隐藏的div，告诉他们将字段留空。如果他们填了，你也可以把它放在错误信息中，所以我不确定可访问性在这里有多大的问题。这肯定不太好，但也可能更糟。

虽然我们都应该知道基本的数学，但这个数学难题可能会引起一些困惑。在你的例子中，我相信有些人会回答“8”而不是“1”。

用粗体或斜体突出显示随机字符的简单文本字符串是否合适?用户只需要输入粗体/斜体字母作为验证码。

例如ssdfatwerweajhcsadkoghvefdhrffghlfgdhowfgh

在这种情况下，“堆栈”将是验证码。 显然，这个观点有很多不同的版本。

编辑:解决与此想法相关的一些潜在问题的示例变体:

使用随机颜色的字母代替粗体/斜体。 使用每秒钟红色字母作为验证码(减少机器人识别不同格式的字母来猜测验证码的可能性)

你是否打算为Stackoverflow提供一个API，允许以编程方式操纵问题/答案?如果是这样，基于CAPTCHA的保护将如何适应这种情况?

虽然通过Atom聚合提要提供了一个丰富的只读接口，但它允许人们创建一些有趣的智能客户端/工具，用于组织和搜索Stackoverflow的大量内容;我认为在网页界面之外拥有提问和/或回答问题以及对内容投票的功能是非常有用的。(尽管这可能不符合基于广告的收入模式。)

我更愿意看到Stackoverflow使用启发式监控方法，试图检测恶意活动并阻止违规用户，但我可以理解使用CAPTCHA可能是一种更简单的方法，因为您的发布数据即将发布。