zoukankan      html  css  js  c++  java
  • 验证码的前世今生(今生篇)

    验证码的前世今生(今生篇)

    看完《验证码的前世今生(前世篇)》也许第一感觉就是Winter is coming,互联网的人机对抗到了最黑暗的时刻。柳暗花明又一村,最黑暗的时刻也是光明即将来临的时刻——在传统验证码的末日新的反向图灵测试机制浴火重生。

    0×1 验证码的划代标准

    在介绍新的反向图灵测试机制前,首先我们对验证码进行划代对比。通过验证码的划代对比我们能更清楚新型验证码的特性。

    验证码划代的标准是人机识别过程中基于对人类知识的应用。

    第一代:标准验证码

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

    第二代:创新验证码

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

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

    第三代:无知识型验证码

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

    如Google的新版ReCaptcha:

    阿里巴巴的滑动验证:

    0×2 无知识型验证码的原理

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

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

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

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

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

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

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

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

    如下图,Festel分组结构的可逆性不要求加密的核心函数F可逆,故可以自动的生成任意的F函数进而派生出无数对称加密算法。

    基于自动化的代码更新及混淆机制从而保障整个Web代码对抗逆向分析和调试的强度,进而将不可信的Web前端打造成可信的端。

    Step 2:后续风控引擎会基于用户操作的行为特征、用户环境信息、用户对应的设备指纹及其设备信誉综合进行决策,判断是否需要对该次操作进行二次判断或者是直接阻断。

    0×3 无知识型验证码的优点

    无知识型验证码有三大核心优点,分别是用户体验,风险识别,风险拦截。

    用户体验:

    无知识型验证码针对大多数的用户能够无需思考,直接通过。不存在业务和流程的打断,体验流畅,对用户体验的提升毋庸质疑。

    风险识别:

    因为随着机器学习的发展让机器掌握人类具有的知识也不再是难点,无知识型验证码不再基于知识来挑战机器,而是基于人类的固有行为特征以及操作的环境信息综合进行风控决策,攻击者难以批量的模拟出可以欺骗风控引擎的正常人类的的操作。

    风险拦截:

    普通的验证码基于知识对机器发起挑战,无法做到对机器进行阻断。因为知识的挑战还需要兼顾人类的体验,机器通过的概率只能做到无限的降低而无法消除。而无知识型验证码基于后端的风控决策,可以对不同风险的操作提出更高难度的验证码乃至阻断,有更大空间对风险进行消除和拦截。

    0×4 总结

    目前阿里聚安全提供的滑动验证产品,目前对外提供免费试用,欢迎申请免费试用

    最后,希望新型的验证码能够建设更简单和安全的互联网: )

    作者:南浔@阿里安全,更多安全类知识及资讯,请访问阿里聚安全博客

  • 相关阅读:
    flask -服务端项目搭建
    蓝图 Blueprint
    flask-session
    flask-数据库操作 / ORM/Flask-SQLAlchemy/数据表操作/数据操作/数据库迁移
    在 Flask 项目中解决 CSRF 攻击
    Flask-Script 扩展/自定义终端命令/Jinja2模板引擎
    Flask项目创建/http的会话控制/Cookie/Session/请求钩子/异常捕获/context
    redtiger sql injection 练习
    流畅的python--序列构成的数组
    流畅的python--python的数据模型
  • 原文地址:https://www.cnblogs.com/alisecurity/p/6022918.html
Copyright © 2011-2022 走看看