web前端开发验证码代码 第三代验证码究竟比一代二代强在哪里？

web前端开发验证码代码 第三代验证码究竟比一代二代强在哪里？很多朋友对这方面很关心，我爱编程网整理了相关文章，供大家参考，一起来看一下吧！

java web 验证码生成后一般在什么地方保存这个验证码？存到数据库还是怎么地？

说起验证码，关系它的是安全性，再联系到你的 时效性 ，这就非session（本身是客户端的唯一使用服务器资源的凭证，而且是有时效限制的，用户长期未访问服务器，这个session是就会被主动注销掉）不能当此大任了，可用性不在话下，至于你说的加密这是画蛇添足了。

依楼上所言，未免误人，服务器端是必须保存这个验证码的，就像我给你了一个验证码，你可以使用，我自己也得备份一下和你比对，不然那不就变成了：你说你的验证码是对的，你已经验证过了，我就信任你了，那就等于没有密码，客户端的一切安全认证都是不足为信的！

第三代验证码究竟比一代二代强在哪里？

更加人性化，智能化，防止了机器人的出现。并且更高程度的保护了用户的信息安全。

第一代：标准验证码

这一代验证码是即是我们常见的图形验证码、语音验证码，基于机器难以处理复杂的计算机视觉及语音识别问题，而人类却可以轻松的识别来区分人类及机器。这一代验证码初步利用了人类知识容易解答，而计算机难以解答的机制进行人机判断。

第二代：创新验证码

第二代验证码是基于第一代验证码的核心思想（通过人类知识可以解答，而计算机难以解答的问题进行人机判断）而产生的创新的交互优化型验证码。第二代验证码基于第一代验证码的核心原理－－“人机之间知识的差异”，拓展出大量创新型验证码。

如12306的验证码也是对于传统验证码的一种创新：

第三代：无知识型验证码

第三代验证码最大的特点是不再基于知识进行人机判断，而是基于人类固有的生物特征以及操作的环境信息综合决策，来判断是人类还是机器。无知识型验证码最大特点即无需人类思考，从而不会打断用户操作，进而提供更好的用户体验。

如Google的新版ReCaptcha:

无知识型验证码的原理

Step 1：在Web前端周期性的对Javascript代码进行混淆和并更新加密算法，将不可信的Web前端打造成可信的客户端。在用户进行滑动操作时，基于可信的客户端采集用户操作的行为信息以及环境信息，将其加密后提交给后端的风控引擎；

Web前端因为代码都是明文形式的脚本语言，服务端想要从客户端获取可信的数据一直面临“源码面前，了无秘密”的困扰。给一个前端工程师充足的时间，似乎Web前端真的是了无秘密，

而随着攻防对抗的持续，安全的补锅匠们总能找到猥琐的方法来进行防御。Web前端虽然没有客户端防止逆向和调试的安全强度，但是却具备客户端所不具有的hotpatch能力。

参考Map-Reduce的原理，单台机器性能不行，把任务分派到多台机器并发执行。如果单份Javascript混淆的强度不可行，那么周期性的对Javascript代码自动混淆。即便攻击者能够短时间的对Web前端进行逆向，但逆向出来的功能短期之后就会在服务端失效，那么也能极大的消耗攻击者的成本。

更可怕的是丧心病狂的Google基于Javascript完全的实现一套虚拟机，核心代码使用字节码实现。周期性的对字节码格式更新逆向的成本成几何级数递增。

如果代码逻辑不更新，仅仅重复的混淆原有逻辑，那么仍然没有意义。而对于一个Web的验证码应用，核功能只有两部分：

1、事件采集模块，采集用户的行为信息，此部分逻辑简单，也无法自动化更新代码逻辑；
2、行为数据加密模块，该部分的核心是加密算法，似乎代码逻辑自动化更新变化有足够空间。

为了保障前端的可信，需要对加密算法进行自动化更新，必须要有一个巨大的对称加密算法可选集合才能保证代码的自动化更新。而所有对称加密算法都基于Feistel分组密码结构，基于Feistel分组密码结构可以派生出无数的对称加密算法，从而可以派生出无数的的对称加密算法。 我爱编程网

腾讯的点击验证码是什么原理

对于伪造网络请求的攻击方面，还有很多技术细节，篇幅有限，如果感兴趣可以看一下我的这篇博客，讲的就是有关验证码方面的一些技术细节：
CSRF漏洞的原理
如果提到的哪个专业术语我没有做通俗的解释，请在下方回复。
如果觉得长，想要直入主题的话可以直接找到 ---重要内容分割线---，看那部分其实是这套验证码最核心的安全机制。
目前web前端的验证码主要分几类：
1 看到图形，肉眼识别后输入字符；
2 根据界面图形，进行鼠标、手指（移动端）交互操作；
3 短信、电话、邮箱验证。
其中第3条，很多时候往往会与第1条相结合起来，以防止CSRF漏洞造成的短信炸弹攻击。
包括用户无感知的人机检验方式（简单地如前端token+referrer判断，这个待会儿再讲）在内，
以上所说的所有手段，终究目的是一个，那就是检查当前访问者究竟是一个“人”，还是一台“机器”。
这在计算机研究领域被称为图灵测试，图灵是一位计算机科学家，他提出对于“人工智能”的定义是：如果把一台电脑放在一个与外界隔绝的房间里，同时把一个人放在一个一模一样的房间里，同时对人和电脑进行各种各样的提问、测试，如果两者做出的反应基本一致（总会有差异，哪怕人与人之间也会有不同），那么认为这台电脑的算法水平已经达到了“人工智能”的级别。
说了这么多，想表达的还是一点，对于“让机器模拟人的行为”或者说“把自己伪装成一个人”，这样的事情在专业领域是有很多研究的。现在网络上存在着诸多验证码、安全校验等等东西，很多人不理解，认为这种东西增加了人们对于软件的正常使用的成本。其实这些安全手段，都是为了防止黑客以各种各样的技术手段，伪造网络请求，假冒真实用户的身份去“刷”网站的各个接口。

下面回到主题，来谈一谈题主所提到的这个腾讯的验证码页面的技术实现。
粗略地翻了一下这个页面的源代码（对于web领域，页面程序的源代码是完全裸奔的，这一点与客户端程序不同，所以如果想要研究对方的代码，对于web开发者来说是一件比较容易的事情，换句话说web前端代码里边是没有太多秘密可言的，因此web的安全性也相对差一些），这个页面在我见过的一些验证码系统中是很常见的一种，就是前面提到的那第1种，看图识别输入字符的验证码形式。下面上代码：
先来看看在UI层面，就是最常见的，通过javascript在DOM上绑定的监听事件触发回调，如图所示，如果我把右边红圈中的click监听remove掉，点击按钮之后就什么反应都没有了，所以基本确定它验证码的逻辑都卸载了这个CT_btn_trigger的回调函数中。然后看看点击后弹出的layer：
全都是用DOM实现的，我在代码中没有发现任何flash object的痕迹（为什么提flash，这个也放在后边说），输入验证码之后监听网络数据包，找到了发送验证码的那个接口：
服务端的接受验证码的接口为 而我们刚刚输入的一条验证码，query字段名称是ans。这里的这一条网络请求是https协议传输的，包括整个qq安全中心的页面也都是上了https的，https协议与我们熟知的http协议最大的不同就是，通过加密手段规避掉了网络中间层对数据包的截获，这一点对于这套验证码来说还是值得肯定的，目前的很多验证码系统对于传输验证码的网络请求都没有上https。

昨晚看的仓促，刚刚又翻了一下发现了这一套验证码系统的核心部分，其实就是上面截图中的collect字段，感谢 @李默然 的提醒，这部分其实也就是我在前文中所提到的那个token，从collect这个字段命名不难猜出这个token是一个前端拼装起来的东西。具体如何拼装，在这里我就不一一扒代码了，考虑到毕竟是一个安全中心的页面，把技术细节在这里讲的太透了，普通用户也不那么关心，反倒是替别有用心的人省了点儿事。所以就不给腾讯的前端同学找麻烦了，在这里简单述说说吧。
collect参数，在用户点击这个按钮的那一刻，就会从服务端传过来一个collect参数，这时的collect参数中做了一些组装和软加密处理，拿到的是密文，明文中的内容不难猜测一定包裹了验证码所需的那张图片的url。
当输入验证码完成后，从客户端发往服务器的那条请求中，虽然ans字段中的验证码是明文，但是还依然带了一个collect字段，而这时的collect字段和上一个collect字段内容是不同的，显然也是一个加密后的结果，推测可知这个collect字段在服务端解密后拿到的明文中，至少也要包含用户本地操作的一些数据，这数据中就包括，他输入的那段验证码所对应的图片究竟是哪张。也许存了图片的url，也许是服务端记录图片的某一组key值，但这个对应关系是一定要有的。
以上提到的collect字段，其实是整个这套验证码系统最为关键的一点，黑客如果要破译这层csrf防御，首先需要搞明白两处collect字段是如何加密的。如果放在其他系统客户端的角度来说，破译这层加密的难度不小，但是由于web客户端的代码是裸奔的，这个天然的劣势导致，黑客不一定要以数学的方法去解出这套加密机制，而是可以直接翻看源代码，看明白collect字段是怎么拼装的，然后只要结合起图片识别模块就可以对这个接口进行强刷了。由于验证码本身是最简单的图片6位验证码，所以图像处理方面识别难度不是很大。
总的来讲，这一套验证码体系属于中规中矩，可能因为并不涉及到金额安全问题，所以也并没有十分重视。
如何优雅地屏蔽百度广告推广
下面简单讲讲刚才翻源码过程中遇到的几个技术细节，值得了解一下：
1 这样的验证码安全吗？
很遗憾，我是个喜欢讲实话的人。这样的验证码，不是绝对安全的。
2 什么是CSRF漏洞？
CSRF简单地说就是伪造的网络请求，黑客以这种手段，用脚本写出一些自动化程序，非正常地使用正常用户在访问网页时调用的http接口，从而达到其他目的（盗号，刷接口，甚至将服务器拖库）。这也正是网页加入验证码的根本原因，提高了黑客去做CSRF攻击的成本，因为他的自动化脚本可以发送任何用户相关的数据，但却很难猜出每次都随机出现的图形验证码中的字符。
3 这样的验证码存在哪些安全隐患？
简单地图形验证码现在已经不算是安全的了，因为以如今的图像识别技术，黑客可以构造一套自动化脚本，首先获取验证码的那张图片，然后把图片交由专门做图像识别的程序模块进行识别处理，返回一个识别结果，再把识别的结果像正常用户填写验证码一样回填到http请求的参数中去。我们看到，他在http请求的参数中，是直接把验证码的字符放在里边，而没有对字符做任何md5、AES一类的处理，所以黑客可以很容易的知道这个参数是什么，并构造上述的一个自动化渗透工具。来对服务器进行攻击。他的图像识别算法的能力不需要达到90% 80%这么高，哪怕有10%的精度，黑客可以把这样的一套脚本攻击程序分布式地放在各个机房的机器上，对服务器造成一定的攻击。对于你所看到的这个qq安全中心的页面是否安全的问题，真的没有是和否的区别，只有值得与否的区别。毕竟构造一套上述的自动化攻击程序以目前的技术，成本还是很高的。但不是不可能。这也解释了，为什么春节抢票期间，12306出台了那么一套变态的验证码，就是因为抢票的这个利益太大了，如果有人能够破译它的验证码系统，损失是铁路部门无法接受的，所以宁可让验证码把普通用户难到骂娘，也绝对不能给黑客的自动化攻击程序留下可乘之机。
4 为什么我要提到flash？
flash作为软件行业中被诸多安全漏洞缠身的一项技术，在web领域，某种意义上却能算是银弹了，至少我是这样认为的。为什么这么说？就像我刚才说的，软件行业，客户端代码其实都是没有什么秘密可言的，你真的想把一些安全级别非常高的代码逻辑保护起来，那只有放到服务端里才可靠，这就是为什么大家申请网银卡的时候都会配给一块U盾，因为软件客户端永远是不安全的，或者说相对于这样大额度交易的利益来讲，在黑客们面前他不够安全。所以要依靠U盾的硬件加密手段，把一些重要的加密逻辑焊死在芯片中进行固化保护。那么话说回来，为什么又要说flash在web领域是安全的呢？因为web太不安全了，作为一个客户端来说，它的一切代码都是裸奔的，任何打包、编译都没有，（有人可能要提到如今的webpack等打包工具，但那些东西实际意义并不在于打包而在于模块化），通俗的解释就是，任何一个懂前端js代码的工程师，都可以很低的成本，读懂其他网站前端代码中做了一些什么事情，这相比其他平台的客户端开发来说是非常可怕的。
真是因此，很多web网站都会把一些不希望别人“轻易偷走”的数据，写到一个flash客户端中，然后再把flash编译后打包的swf作为一个静态资源加载到页面中（因为现代浏览器都是支持flash的），让flash和用户交互。想要把flash反汇编出来，搞懂他里边做了什么，对于同样从事flash的AS开发工作的工程师与从事web前端开发工作的工程师，这本身从实现成本上就比web前端的html和javascript代码要高很多。
另外，如今的绝大多数web工程师，都不太熟悉flash代码，所以把flash作为web系统某些安全隐患上面的银弹，还是有一定道理的。这里我可以举一个目前线上的例子，酷狗音乐就是通过flash播放器，解码一种acc格式（特殊的音频格式，普通浏览器和播放器无法直接播放）的音频文件，来实现音乐歌曲的防盗版。因为你前端就算把他音频文件的url拿到了，下载下来，你也不好直接播放。
对于这部分,就不再扯远了。

以上就是我爱编程网为大家带来的web前端开发验证码代码 第三代验证码究竟比一代二代强在哪里？，希望能帮助到大家！