使用哈希键在客户端验证验证码是否安全？答案

【问题标题】：Is it safe to validate a captcha on the clientside with its hashkey?使用哈希键在客户端验证验证码是否安全？
【发布时间】：2015-03-29 19:17:58
【问题描述】：

我经常使用验证码来保护表单。到目前为止，出于显而易见的原因，我只在服务器端检查用户输入的验证码解决方案。

对于所有其他表单字段，我会在客户端进行 javascript 验证，因为这更快且更用户友好；（当然我在服务器端做了第二次检查），但是对于验证码字段，我只是检查了它是否填写了。

我的问题： 使用验证码的哈希键（例如 MD5）进行客户端 JavaScript 验证是否安全？使用哈希键不会将验证码本身泄露给机器人，应该很安全，对吧？

但也许我对这个想法完全错误...... 感谢您的见解！

【问题讨论】：

【解决方案1】：

我会说足够安全，但这可能有助于 OCR 机器人检查他们是否正确，而无需在服务器上尝试运气并冒丢失当前验证码的风险（因为如果提供了不正确的答案，服务器将使代码无效并且不会给您第二次使用相同验证码重试的机会。

假设 OCR 机器人无法判断您的验证码的最后一个字母是小写 L 还是“1”数字？在没有客户端验证的传统验证码中，机器人只是碰运气，如果它猜错了，服务器会记录失败并重新发送一个完全不同的验证码，因此 OCR 必须重新开始。

现在想象一下上面的场景，但是通过客户端验证，机器人可以在不通知服务器的情况下验证他们是否有正确的答案，所以在这种情况下，如果机器人不确定，它会尝试所有对哈希的可能性，只提交正确的答案。基本上，这使机器人能够犯错误，而无需告知服务器，也无需重新开始。

最后，我没有记住精确的数字，但即使每次使用不同的盐，根据可能性的数量（如 4 个字母数字字符，不区分大小写），也有可能在一段合理的时间，甚至没有制作 OCR。为了缓解这种情况，您应该使用哈希的多次迭代，以便尝试所有可能的答案在计算上变得困难。

【讨论】：

嗨安德烈，这是一个很好的观点，我到目前为止还没有看到！如果您真的希望有人分析您的表单和代码，我认为这方面确实会破坏验证码的安全性。但有时验证码更像是对垃圾邮件发送者的“提示”，上面写着：“不要尝试 - 我准备好了”;-)
@Arno：“但有时验证码更像是对垃圾邮件发送者的“提示”” --- 然后在那里放一个虚拟的静态图像，没有任何逻辑。简单，轻松。
如果您只是担心路人垃圾邮件，那么一个简单的解决方案就是让您的真实表单字段的名称具有随机/无意义的值，然后制作一些名称为“电子邮件”、“姓名”的隐藏字段”、“消息”，基本上是任何看起来像联系表格的东西。在服务器上，检查这些蜜罐字段是否留空（因为它们对人类是不可见的），如果不是，那么它就是垃圾邮件机器人。当然，如果发生有针对性的攻击，这将中断，但您的解决方案也是如此。

【解决方案2】：

听起来可行，但是您绝对应该考虑使用长随机盐来防止基于预先计算的简单攻击。

更正式地说，您必须发送图像、长随机盐和哈希值。然后，在客户端，您将计算与盐连接的输入文本的哈希值，并将结果与哈希值进行比较。

由于长随机盐，攻击者的预先计算的集合必须非常大才能反映所有可能的盐值。

另外，忘记 MD5，因为它被认为是不安全的。使用更强的哈希函数。

另请注意，这只会可能增强用户体验（无需发布页面以防验证码输入错误）但绝对不能只客户端。实际验证必须在服务器上完成。

【讨论】：

请记住，验证码的长度通常约为 6 个字符（甚至更短）——您可以简单地破解它。所以s/doable/security flaw/
您好 Wiktor，非常感谢您的提示和建议！ zerkms 的评论说服我不要在应该真正受保护的表单上使用此客户端验证。
@zerkms: 可能足以要求使用大量轮次计算散列，因此单个计算需要大量时间。那时蛮力可能会困难得多。
@WiktorZychla 如另一个答案中所述 - 如果您有 OCR，则 1 或 2 个字符可能需要暴力破解，这对于任意轮数都是即时的。我个人认为故意放置安全漏洞然后尝试加强它是一个冒险的步骤。
@zerkms：同意，我是在我的回答和你的回答下支持你的评论的人。