验证码，一个对用户毫无价值，但对网站却是一个自我保护的屏障。

     通常，验证码出现在提交表单的情况下，用于网站判断数据提交方是正常用户还是机器人。

     比如：

     1：在新用户的注册流程。可以用来遏制恶意注册。
        2：用户密码取回流程。可以用来防止用户密码被恶意夺取。
        3：用户登录。一般出现在多次密码输入错误，可以用来防刷密码。
        4：文章评论。可以防止广告等信息的传播。
        ......

     从产品上看，以上流程，对用户体验而言，让用户输入验证码，无疑是在骚扰用户。毕竟，恶意行为在独立用户、独立ip中是少数。这样的产品设计是让99个用户为1个用户的恶意行为买单。

     但是从技术上看，以上流程让验证码的存在却是有价值的。尤其是用户行为分析机制尚未建立时，因为我们无法预知对用户的行为。

     不要相信任何用户提交的数据。这一准则深深影响着程序员，我们对用户的提交的数据进行各种校验：是否符合产品上在页面规定的内容？是否符合数据库存储字段的属性？数据输入时是否会含有SQL注入的风险？数据输出时是否会影响页面的正常显示？数据中是否含有敏感词让某些人不高兴？

     这一切对正常用户而言，均不是问题。但是对于少部分用户，比如好奇心强的技术性用户，甚至想从中得取不正当利益的利益团体。真正有威胁的是后者。而验证码就是双方攻防的重要阵地，所谓刀光剑影尽在于此。

     基于以上讨论，我们是迫不得已在我们认为需要阻止恶意行为的地方加入验证码。这主要是一个技术问题，产品上是一个被迫的选择。

     但现在，似乎，在有表单提交的地方，验证码就成了标配。从以上的分析中，其实并不是每个地方都有必要出现验证码。只有在那种技术上、产品上难以控制恶意行为的地方才需要。

     一个比较典型的是：公司内网的登录为什么需要验证码？输入一次错误密码就是显示验证码的理由？尤其是那种半个小时不操作就要登录的系统，真是恶心的不行。半个小时不操作就让输入密码，本已很恶心，更恶心的是，这么频繁的操作偶尔输错一次密码还让输入验证码，真是恶心之极。

     言归正传，我们谈谈其它避免出现验证码的场景。

     一个登录后的用户，在进行操作时是否需要显示验证码？一个用户能登录，说明他通过了两个流程：注册、登录。以上我们谈到，这两个流程我们都是有必要用验证码来遏制恶意行为的。用户能正常登录，在很大程度上说明他不是一个恶意行为者。当然，不排除有恶意行为的可能，毕竟道高一尺，魔高一丈。这个时候就有必要考虑，是否为1个用户而为难99个用户了。

     我认为是没有必要的。如果一定要考虑，我们可以变通的实现，以缓解用户对验证码的厌恶，毕竟验证码对用户是毫无具体意义的。

     我们分场景讨论一下。我们把用户提交的信息分为两类：

     1：影响用户自己。
        2：影响其他用户。

     对于影响用户自己的操作，如修改密码、用户信息。这些信息有的只是用户的一条数据而已，如昵称、生日等；有的是需要网站付出资源的，比如绑定一个由网站方提供的邮箱、需要费劲心思保护的商务信息（某某币等）、用户敏感信息（密码、密保信息）等等。对于前者，用户任意改，其实无所谓，对于后者，就需要我们注意对用户进行保护了，比如用户被恶意侵入怎么办?这个时候验证码是否该出现呢？不应该！这个时候应该让用户输入自己的密码。这样既避免用户对验证码的厌恶感，又提高了安全性，夸大一点说：提高网站的品牌形象，用户一看：哇，这网站在保护我的信息。

     对于会影响其他用户的信息，如论坛的主题贴和回帖，博客、新闻的评论。如果这些地方显示验证码，从产品上让用户感觉不易用。但之前所说，道高一尺魔高一丈，如何遏制潜在的恶意行为？对这些产品而言，可使用的产品手段则比较多了。对于新注册的用户，很多网站都会禁言一段时间，但是这样也使正常用户感觉不爽，不利于网站推广。此时我认为可以采取产品手段：用户的注册时间、之前的活动量都是一个是否显示验证码的依据。对于可信赖的用户是无需使用验证码的！比如有些论坛就是积分大于某一值时就可以不显示验证码，当然对于这些用户的恶意行为的惩罚就是另一回事了。

     总而言之，验证码是技术人员无奈的选择，产品上能不用就不用，敬而远之！

建议继续学习：

1. CI框架里用的验证码    (阅读：4886)
2. 验证码的几个常见漏洞    (阅读：3357)
3. pytesser：图片验证码识别    (阅读：3164)
4. 一个Captcha的思路    (阅读：2298)
5. 实现动态验证码的思路    (阅读：2142)
6. 浅谈Web安全验证码    (阅读：1737)