首页 > 代码库 > 验证码设计(转)

验证码设计(转)

12306采用验证码, 无疑是一种很不错的措施,可以在一定程度上阻止了黄牛们的疯狂行为,不过也给正常使用验证码的童鞋带了个很头痛的问题,在选座提交订单的关键时候,竟然验证码图片拉取不下来又或者验证过程非常耗时。鉴于自己也是无数码农中的有这职业病的一员,为此也来谈谈关于验证码的优化方案。

      验证码通常一张静态的图片,但是12306使用的却是一张动态的图片(GIF格式),动态图片的验证码大大的提高了破解的难度,但无疑也具备比较高的生成成本。我们首先来看一下通常情况下的验证码校验流程:
 
     1)浏览器向验证码服务器发起获取验证码图片的请求;
     2)验证码服务器返回验证码图片文件和图片文件对应的ID编号(ID编号一般下发到浏览器的Cookie中);
     3)浏览器提交用户输入的验证码和图片文件ID编号;
     4)Web服务器校验用户输入的验证码与图片中展示的验证码是否一致,根据校验结果来向用户展示不同的页面;
 
     下面我们来看一下系统的整体架构图:
    主要处理流程为:
    1、获取验证码
         1)从配置中心中获取当前可用的频率控制、验证码库、待验证库可用的服务地址列表
         2)频率控制,主要控制当前请求是否属于恶意攻击;
         3)验证码库,获取可用的验证码信息,即获取一个可用的验证码图片文件地址;
         4)将获取到的验证码信息写入到待验证库中,方便后续进行校验验证码;
     2、校验验证码
         1)根据从前端获取到的图片编号(获取验证码时,下发的对应编号),来从待验证库中获取验证信息;
         2)将验证结果发送到校验统计模块;
 
    在设计过程中需要考虑的点:
    1)恶意刷新
     来自某个IP频繁的请求验证码,大体上就可以判定验证码正在被刷中,需要采取措施进行一定的频率限制,降低继续被刷的请求量,这里我们可以采用比较简单限制来个某个IP请求次数,当然也可以根据业务特性,添加业务对应的频率控制逻辑;
     2)验证码有效期
     验证码可以生成一条Key—Value的数据存放到Memcache中(即待验证库),Value为:验证码图片文件ID、验证码Code、生成时间,每个请求验证码图片的请求,均在缓存中插入一条记录,每发送一个验证请求,即将缓存中的这条记录删除失效。
     3)图片文件与图片编号
     两者之间不可以建立一一对应的关系,否则,坏人只需要保存图片编号,下次就可以重复提交对应的验证码;但是可以建立一对多的关系,也就是一张图片对应多个图片编号,但是一图片编号只能唯一对应图片;
      4)验证码生成
     验证码图片文件的生成相比而言是比较慢的操作,所以需要采用离线计算成功的方案,避免浏览器获取图片验证码文件耗时比较久,影响用户的体验;这里存放一个问题,什么时机启动验证码生成的流程,有以下几种策略:
       a)每天定时生成更新,策略简单实现;
       b)定时检测验证码可用量,来生成一批新的验证码文件;
     总之,验证码图片文件的生成必须是离线进行的,同时在此时需要为图片文件生成一个或者多个编号;服务部署的个数,完全取决于验证码的消耗量;
     5)验证码库
     验证码库,应该采用那种数据结构?Mysql还是其他的数据结构。在这里,可以尝试采用Redis的list结构来当作消息队列来使用或者其他的可用的消息队列。需要获取验证码时,从消息队列中Pop出一个值即可。每个记录中至少需要存储的字段为:图片编号、图片地址、验证码等信息。消息队列中的记录 < 50%时,可以出发验证码生成逻辑来定时插入新的验证码。面对更并发的验证码请求量,可以在集群中多部署几套Redis消息队列以及验证码生成系统来应对;
     6)图片编号的生成
     验证码图片文件需要支持在多台机器上面部署多个服务,同时也要支持在单机上面部署多个服务,这里就需要解决如何来生成唯一验证码图片编号的问题。可以通过根据机器IP和服务编号来解决这个问题,每台机器上面的服务均存在一个服务编号(保证服务编号在单机上是唯一的),计算公式可以为:ID = MD5(IP+服务编号+时间戳+自动序列号)