Javascript 在客户端用hashkey验证验证验证码安全吗？

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

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

我的问题： 使用验证码的哈希键（如MD5）进行客户端JavaScript验证是否安全？使用散列密钥不会向机器人透露验证码本身，应该是非常安全的，对吗

但也许我完全错了这个想法。。。

---

谢谢你的见解

< P>听起来是可行的，但是你应该考虑一个长而随机的盐来防止基于预先计算的简单攻击。 更正式地说，您必须发送图像、长随机salt和散列值。然后，在客户端，您将计算与salt连接的输入文本的散列，并将结果与散列进行比较

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

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

---

还请注意，这可能只会增强用户体验（如果输入了错误的验证码，则无需发布页面），但肯定不能仅在客户端。实际的验证必须在服务器上完成。

我认为这足够安全，但这可能有助于OCR机器人在不在服务器上碰碰运气和丢失当前验证码的情况下检查是否正确（因为如果提供的答案不正确，服务器将使代码无效，并且不会给您第二次使用相同验证码重试的机会）

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

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

---

最后，我脑子里没有精确的数字，但根据可能的数量（如4个字母数字字符，不区分大小写），即使每次使用不同的salt在一段合理的时间内，甚至不进行OCR，就有可能对每一种可能性进行强制执行。为了缓解这种情况，您应该使用多次哈希迭代，以便在计算上很难尝试所有可能的答案。

仅在客户端？否-不只是客户端。第二次检查将在服务器上进行。Keeping记住，CAPTCHA通常有6个字符长（甚至更短）-您可以简单地对其进行暴力处理。因此

s/doable/security defect/

Hi Wiktor，非常感谢您的提示和建议！zerkms的评论说服我不要在表单上使用此客户端验证，表单应该得到真正的保护。@zerkms:可能足以要求使用大量轮计算哈希，以便le计算需要大量的时间。Bruteforce可能比这困难得多。@WiktorZychla在另一个答案中提到-如果你有一个OCR，那么Bruteforce可能需要1到2个字符，这对于任何数量的回合来说都是即时的。我个人认为故意设置一个安全漏洞，然后尝试加强安全性是危险的一步谢谢。@zerkms:同意，我是在我的答案和你的答案下对你的评论投赞成票的人。嗨，安德烈，这是一个我到目前为止还没有看到的好观点！如果你真的希望有人分析你的表单和代码，我想这方面确实会破坏验证码的安全性。但是有时候验证码更像是一个“提示”对于说“不要尝试-我准备好了”；@Arno：“但是有时候验证码更像是对垃圾邮件的“提示”——然后在那里放置一个虚拟静态图像，没有任何逻辑。简单，简单。如果你只担心路人的垃圾邮件，那么一个简单的解决方案就是让你的真实表单字段的名称具有随机/无意义的值，然后用“email”、“name”、“message”等名称创建一些隐藏字段，基本上是任何看起来像联系人表单的内容。在服务器上，检查这些蜜罐字段是否留空（因为它们对人类是不可见的），如果不是，则它是一个spambot。当然，这将在目标攻击的情况下中断，但您的解决方案也是如此。