浅谈支付宝智能风控引擎的风险感知维度的运行流程和一些设想

文章中可能存在纰漏,个人知识量有限,难免会发生错误,请谅解。

开头

之前看到一个节目:《智造将来》,里面有一期讲述的是【揭秘支付宝的安全系数】,看了之后深有感触,并且有一些感想,于是就打算把它写下来。

作者也提供了素材的地址,文章对视频依赖性较强:
《智造将来 - 揭秘支付宝的安全系数》视频链接地址

视频主要环节的是六位刑侦支队的网络干警作为攻击手,二人一组,分三组去入侵别人的支付宝账户,用支付宝风控引擎做自主拦截的红蓝对抗。
攻击手具有很高超的黑客水平,支付宝风控引擎也不是吃素的,内容非常精彩,过程读者可以去看,这里不多做补充。

结合案例对风险感知维度的运行流程的简单猜测

第一组入侵:

第一组挑战的是蒋昌建蒋老师的手机:攻击手通过一切途径获取到了蒋老师姓名和手机号。
攻击手通过获取到的信息进行暴力破解,想登录支付宝,因为登录尝试次数过多,支付宝智能风控引擎发出了警告。
浅谈支付宝智能风控引擎的风险感知维度的运行流程和一些设想_第1张图片
此时支付宝风险感知维度的大屏 设备和环境两个维度已经亮起
个人的几个猜测:
设备:是因为风控引擎已经感知到了,用户的手机是放在那里的,这是另外一台新的设备来尝试登录他的账户,是具有风险的操作
环境:攻击手和蒋老师的ip,用的网段,其中也包括设备类型,攻击次数等,造成了支付宝使用环境的不一致
攻击手由于无法登录支付宝从而无法达到转账的目的,随即又改变登录策略,选择忘记密码:
浅谈支付宝智能风控引擎的风险感知维度的运行流程和一些设想_第2张图片
但风控引擎还是检测到了风险:
浅谈支付宝智能风控引擎的风险感知维度的运行流程和一些设想_第3张图片

此时支付宝风险感知维度的大屏 行为又突然亮起
个人猜测:
行为:用户在非正常登录的情况下又选择修改密码,多次登录没有成功,这之间已经存在了暴力破解尝试登录的模型,多次的登录失败,和修改登录密码的行为已经造成了行为上的不一致。前提是用户会一直手记用户的操作习惯,用来对比每次新的操作的异常行为

隔开第二组说第三组入侵:

因为实验者的手机已经中毒,所以攻击手可以远程获取到他手机上的任何信息,所以攻击手用另外一台新的手机直接使用短信验证码登录,实验者手机上的信息,攻击手同时能看到。
正确的验证码输入成功后,支付宝风控引擎检测到存在风险,智能改变防护策略,进行姓名验证。攻击手通过远程获取到实验者手机的短信库,通过汽车旅行险信息远程获取到真实姓名。
直到成功登录了支付宝。
此时攻击手需要修改支付包登录密码,因为他不知道。
攻击手使用同样的短信验证码远程获取方式,远程获取支付宝因为修改支付密码而发送的验证码。
但是支付宝检测到当前操作存在风险,智能改变防护策略,所以还攻击手还需要继续验证银行卡号。
攻击手通过远程获取实验者的手机相册,远程获取到了他的银行卡号。
直到验证通过,支付密码被成功修改。
然后进入转账环节:
但由于支付宝风控引擎检测到当前操作存在风险,强行中断转账,最终,攻击手转账失败。
此时的支付宝风控风险感知维度的状态是:
浅谈支付宝智能风控引擎的风险感知维度的运行流程和一些设想_第4张图片

设备 环境 行为 说过了,触发因素大致一样
雄文的解说是:
关系:这个转账的双方,以前从来没有任何关系,也从来没有转过账
偏好:收款方的这个账户,自他登记以来,他主要的行为就是收账和提现,很少有一般的日常消费行为,已经成为了一个偏好的模型
交易:转账方的所属的城市,也很少转账。个人认为,支付宝依托大数据的,对交易的活跃做了分析,双方所属的城市很少转账,双方所属的位置少转账,双方的通讯录里都没有对方,这会造成转账和收款方的联系很少,与大数据模交易地理活跃模型不匹配。综上所述,这比转账拥有极高的风险,所以直接就把风险失败了。

设想延伸

支付宝的安全等级是世界一流的,安全级别的专家团队,黑客的师傅招到支付宝,藏龙卧虎高手云集。
虽不敢比支付宝,但是是否可以依据这几个简单的维度,也写一个mini的风控系统?

设备:如pc端,移动端,user-agent数据,
环境:用户客户端ip,ip对应的城市,单点登录
偏好:用户操作的习惯,数据通信的时间是否合理,异常操作合理性判断,如大量删除,大量异常写操作的数据。
行为:是否有sql注入 xss攻击,暴力登录,等。

通过这些数据已经可以做到的安全等级是:

  1. 即使有黑客用户名密码输入正确的情况下,由于不能保证所有维度的信息完全一致,黑客也无法登录,同时提醒用户,让他修改密码。
  2. 如果有人通过软件窃取到通信的数据,他也无法进行修改,因为还是不能保证所有维度的信息完全一致,比如登录用的是一个user-agent,referer,窃取者用的是另一个user-agent,referer,如果程序保证登录的设备信息与登录成功后设备信息一致才能通信的话,就算你能获取到,你也无法对数据进行恶意的篡改后发送到服务端。但是为了保证通信机密,推荐使用https协议。

当然也有一些缺点,比如操作的复杂性,打扰率更高,容易被误拦截等。

虽然没有什么商业的价值,但是也是一个不错的项目,比传统的增删改查要有意思,可以自己玩玩。如果这几个风险维度拦截率设置的得体,打扰率设计得体,可以广泛用于各个安全领域。

你可能感兴趣的:(安全)