验证码的使用场景小议
发布于 2010-05-06 23:35 阅读:120,265 评论:0 标签: 验证码

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

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

    比如:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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