手机没联网,支付宝也支付成功了,原理是什么 ?

用支付宝时发现没开网络也能付款成功,原理是什么呢?有没有被破解的可能?

事实上支付宝和微信的“当面付”产品,是一款联机在线支付产品,所以不允许双方均离线的场景下支付(这一点和公交卡圈存支付不一样,公交卡的近场支付事实上允许双方脱机)。

题目中所知的支付宝和微信没有网络,指的都是消费者客户端没有网络,而不是双方都没有网络。

严格来说,当面付产品(特指商户主动扫消费者钱包客户端上的 token 码进行支付的形态)必须要商户在线方可进行联机交易,原因有以下两点:

  1. 支付公司为了保证资金安全必须要确保每笔用户的支付行为背后都真正发生了资金扣款,所以在线联机确保支付成功是必要的。(这里解释了为什么不允许双方脱机)

  2. 商户为了确保用户的支付结果可信赖,必须要自己的终端或者系统从支付公司获得支付结果,而不能以消费者的支付结果凭证作为结论。以传统 POS 业务举例,你可以认为你的刷卡信息等同于支付宝的当面付码,商户必须要看到 POS 机打出支付成功单据后才认为支付有效,如果 POS 支付超时没有回执,光凭客户手中的银行短信通知是不会让客户走的,而是会冲正掉上一笔交易让客户重新刷一笔。(这里解释了为什么要选择商户必须联机的方案)

那么,我们来看看一个标准的当面付产品的信息流是什么样的(原谅我草草画了一下):

我们可以看到在这个图里红色圈圈部分,商户系统和支付宝系统是对接上的,所以商户系统是联机的——而用户的手机,在展示 code
的时候,我并未强调是否和支付宝服务端联机。

事实上,不论是微信还是支付宝都支持两种用户码生成模式,即在线码和离线码。

在线码其实很容易理解,用户目前是登录钱包的状态,只要点击【付款】按钮,客户端就向支付宝的服务端申请一个针对这个客户账户的支付凭证码并展现到客户手机上。

这个支付凭证码在支付宝的服务端会有一组数据库记录其与真实客户账户之间的关联,并且这份关联的有效期为
60S,超过时效即便商户上送这个码,支付宝也会认为这是作废码而不予处理。

用户每次点开【付款】、等待超过 60S、主动刷新付款码,都会触发客户端向服务器申请一个新码的请求。

这个方案的好处是:

  • 相对安全,每次码都是服务端生成。

  • 业务灵活,即便对码的安全算法等进行较大的调整,也不用升级客户端,因为是服务端发码。

这个方案的坏处也显而易见:

  • 用户的手机客户端必须在线联网,如果没有网络则无法获取付款码

  • 用户即便在线,如果网络连接不好,也会出现点了付款等好久才看到码的情况,体验会不可控。

为了解决在线码方案的问题,离线码方案就出现了。

离线码的基本技术原理其实也不复杂,可以参考 @反方向的钟 的回答,比较简单的实现方式是:

用户登录后,服务端通过可信网络向用户客户端发送一个种子数据(每个客户的种子数据唯一,换用户登录后销毁原种子,重新下载种子)本地保存,当用户点击【付款】时,客户端利用这个种子数据

  • 时间戳 + 一套安全算法可以生成一串数字,即离线码。

当用户使用离线码支付时,服务端通过一定算法校验这个码的确是来自于这个用户,随即确认用户授权完成支付。

离线码的好处不言而喻:

  • 用户无需在线,就算在地下室等没有网络的场景一样可以使用

  • 由于不依赖网络,所有码本地生成,所以客户体验很好,一点付款码就能出来

那离线码的劣势呢,我们看看:

  • 用户 root/ 越狱手机后,保密存储的种子数据有可能被不法分子利用恶意程序获取到,导致离线码被随意生成用于消费。

恩……怎么说呢,毕竟现在不是发烧友主动 root 越狱的用户并不多,这是其一。

即便是 root 越狱,如果用户使用手机的习惯良好,被恶意程序攻击手机的概率也很低,这是其二。

每家公司都有自己的安全团队去保障自己客户端的数据安全,并不是说 root 的用户就只能坐以待毙了,否则微信和支付宝早被搞破产了,这是其三。

当然从我个人的角度来说,普通用户我都不建议去 root 或者越狱。

这个问题最粗暴的方案就跟反方向的钟所说的一样,监测到系统被 root 了就对用户限权(很多银行的客户端方案都是这么搞的)。

作为直接面向消费者市场且充分竞争的产品,微信支付和支付宝断然不会采用上面那个方案的。

怎么能又开放离线码给用户,又能确保用户支付安全,本身也是支付公司安全竞争力的一部分,这里就省略几万字了。

  • 数据碰撞可能导致 A 用户的码扣到 B 用户的账户

恩,这里涉及一些算法问题,业务上就是碰了巧了 A 用户码算出来和 B 用户码一模一样且都有效(两个客户端都没作弊)。

在线码之所以可以避免这个问题是因为在线码是服务端发的,可以控幂等。

离线码是客户端自己根据算法生成的,所以没法控。

其实原因和哈希算法的数据碰撞类似,是个小概率的纯技术问题,就不展开赘述了。

解决方案:优化算法(确保碰撞概率低到一定程度甚至杜绝),如果真的出现就认栽给客户赔钱(赔多了技术部门老大就肯定痛定思痛优化算法了)。

事实上这个问题发生的概率极低极低,所以可以忽略不计。

  • 算法调整不如在线码灵活

因为离线码生成逻辑都在客户端,所以通常来说安全算法升级会导致客户端升级,比在线码升级更影响用户一些。

分析到上面这层,各位产品经理相信应该就知道如何做方案选型了。(装个逼,事实上我觉得了解到上面那个层面是支付行业产品经理的基本素质)

后话:

我在写这个答案的时候其实都在刻意回避公司实现这些业务的具体逻辑和算法。而我个人并非当面付产品的产品经理,所以大家放心,这篇文章不算泄密。

写这个答案的目的是希望能尽量站在产品和业务角度还原业务原理,希望更多的非行业内的知友知其然,也知其所以然。

两步认证技术

什么是两步认证

在介绍两步认证之前,首先来看下目前主流的几种认证方式。

[
](https://dn-coding-net-production-pp.codehub.cn/ebc07cdb-948e-434f-ae4f-
d14a81c7893d.png)

上图中的认证方式大体上可以分为三大类

1.You know : 比如密码,这种只有我们知道的

2.You are : 比如指纹,这种只有我们拥有的

3.You have : 比如信用卡,这种只属于你的

了解上面所说的三大类之后,我们就很容易的理解下面几点。

什么是两步认证?

两步验证,对应的英文是 Two-factor Authentication(2FA),从名字可以看出,「两步」是 2FA 的重点,而两步就是我们上面所提到的
You know + You Have ,也就是 密码 + 一次性密码(One Time Password,OTP)

为什么我们需要两步验证?

传统的密码认证方式,如果在用户名密码在其他网站上泄露,任何用户都可以使用你的账号密码进行登陆做任何操作。但有了两步认证就能在一定程度上有效的避免这种情况的发生。因为在每次登录时,不仅需要输入您的帐户密码,还需输入移动设备为您生成的一次性动态验证码

OTP

前面说过,2FA 中使用的是一次性密码(One Time Password,OTP),也被称作动态密码。一般 OTP 有两种策略:HOTP ( HMAC-
based One Time Password) 和TOTP ( Time-based One-time Password)
。目前被广泛使用的正是后者这种基于时间的动态密码生成策略。

算法大体是这样:

  1. 客户端和服务器事先协商好一个SECRET,用于一次性密码的生成过程,此密钥不被任何第三方所知道。此外,客户端和服务器都采用时间做计数器。

  2. 客户端对密钥和计数器的组合(SECRET,time/30)使用HMAC(Hash-based Message Authentication Code)算法计算一次性密码,公式如下:HMAC-SHA-1(SECRET, time/30)

  3. 各种算法加特效后成6位数字

在这里就只简要介绍该算法,如想深入了解

==> https://tools.ietf.org/html/rfc6238

基于TOTP的密码有如下特点

  1. 无需记忆,不会产生password这样的泄漏问题

  2. 动态生成,每30s生成一个,安全性大大提高

  3. 对网络无要求,离线下仍可正常使用

  4. 成本低,无需购买硬件和软件

两步认证流程

  1. 服务器随机生成一个类似于『DPI45HKISEXU6HG7』的密钥,并且把这个密钥保存在数据库中。

  2. 在页面上显示一个二维码,内容是一个URI地址(otpauth://totp/账号?secret=密钥?issuer=厂商)

  3. 客户端扫描二维码,把密钥『DPI45HKISEXU6HG7』保存在客户端。

  4. 客户端每30秒使用密钥『DPI45HKISEXU6HG7』和时间戳通过TOTP『算法』生成一个6位数字的一次性密码

两步认证的其他情况

然后仅仅只是做好上面这种正常的验证流程是不够的,Coding 的两步认证在一些异常情况下做了很多处理。

  1. 生成的 OPT 应该是不能复用的,也就是用户在登陆或者危险操作时输入完一次 OPT 后,手机端 OPT 仍然未刷新时,在进行登陆或者危险操作时输入刚才的OPT是无效的,必须等待手机上OPT的刷新。

  2. 既然可以离线使用,那么怎么保证时间的差异性,我们服务端会兼容服务器时间的前后30s。从而有效的避免细微时间上差异而导致的验证失败,同时也避免了用户刚输入完 OPT 后还未做提交操作时 OPT 刷新而引起验证失败。

  3. 在遇到使用遍历所有6位数数字进行暴力破解 OPT 时,我们会对错误次数进行限制,90s 限制其错误次数能有效避免暴力破解的出现。

  4. 在开启两部认证后,其他所有登陆的客户端都会因为开启两部认证而过期,必须重新登陆。

两部认证的实现

目前 Coding 采用的 https://github.com/wstrange/GoogleAuth 实现的TOTP 算法,在提供 TOTP
算法之外,该库提供了可以存储用户 secret 的接口,采用的 ServiceLoader 方式,ServiceLoader
方式可以通过链接了解更多==>http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html


在对外网开放的后台管理系统中,使用静态口令进行身份验证可能会存在如下问题:

    (1) 为了便于记忆,用户多选择有特征作为密码,所有静态口令相比动态口令而言,容易被猜测和破解;

    (2) 黑客可以从网上或电话线上截获静态密码,如果是非加密方式传输,用户认证信息可被轻易获取;

    (3) 内部工作人员可通过合法授权取得用户密码而非法使用;

静态口令根本上不能确定用户的身份,其结果是,个人可以轻松地伪造一个假身份或者盗用一个已有使用者的身份,给企业造成巨大的经济和声誉损失。本文主要介绍并实现了一种动态口令(OTP)的实现方式。

  动态口令(OTP,One-Time
Password)又称一次性密码,是使用密码技术实现的在客户端和服务器之间通过共享秘密的一种认证技术,是一种强认证技术,是增强目前静态口令认证的一种非常方便技术手段,是一种重要的双因素认证技术,动态口令认证技术包括客户端用于生成口令产生器的,动态令牌,是一个硬件设备,和用于管理令牌及口令认证的后台动态口令认证系统组成。

otp从技术来分有三种形式, 时间同步、事件同步、挑战/应答。

(1) 时间同步

原理是基于 动态令牌动态口令验证服务器的时间比对,基于
时间同步令牌,一般每60秒产生一个新口令,要求服务器能够十分精确的保持正确的时钟,同时对其令牌的晶振频率有严格的要求,这种技术对应的终端是硬件令牌。

(2)事件同步

基于事件同步的令牌,其原理是通过某一特定的事件次序及相同的种子值作为输入,通过HASH算法中运算出一致的密码。

(3)挑战/应答

常用于的网上业务,在网站/应答上输入 服务端下发的
挑战码动态令牌输入该挑战码,通过内置的算法上生成一个6/8位的随机数字,口令一次有效,这种技术目前应用最为普遍,包括刮刮卡、短信密码、动态令牌也有挑战/应答形式。

使用阿里云身份宝(或者Google Authenticator)时间同步实现OTP动态口令

如上图,是一种基于时间同步的OTP计算方式,是通过客户端和服务器持有相同的密钥并基于时间基数,服务端和客户端采用相同的Hash算法,计算出长度为六位的校验码。当客户端和服务端计算出的校验码相同是,那么验证通过。

  由于客户端需要存储密钥和计算校验码的载体,阿里云的身份宝(或者Google
的Authenticator)提供了手机端的APP进行密钥存储和校验码计算。下面我们以这两款客户端为例,实现在应用采用OTP进行权限验证,主要流程如下图:

流程关键代码如下,(更详细代码,请Git下载:https://github.com/suyin58/otp-demo

1 用户注册:

1.1 生成OTP密钥:

1
2
3
String secretBase32 = TotpUtil.getRandomSecretBase32(64);

oper.setOtpSk(secretBase32);

1.2 生成OTP扫描用字符串:

约定字符串格式如下:

1
2
String totpProtocalString = TotpUtil.generateTotpString(operCode, host,
secretBase32);

1.3 将1.2中生成的字符串生成二维码,通过邮件发送给用户

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
String host = "otptest@wjs.com"; // 自定义

            String totpProtocalString = TotpUtil.generateTotpString(operCode,
host, secretBase32);

            String filePath = f_temp;

            String fileName = Long.toString(System.currentTimeMillis()) +
".png";



            try{

                QRUtil.generateMatrixPic(totpProtocalString, 150, 150,
filePath, fileName);

            }catch (Exception e){

                throw new RuntimeException("生成二维码图片失败:" + e.getMessage());

            }


            String content = "用户名:"+operCode+"</br>"


                    +"系统使用密码 +
动态口令双因素认证的方式登录。</br>请按以下方式激活手机动态口令:</br>安卓用户请点击<a
href='http://otp.aliyun.com/updates/shenfenbao.apk'>下载</a>,"

+"</br>苹果手机在AppStore中搜索【身份宝】(Alibaba)。下载安装后,通过扫描以下二维码激活动态口令。</br>"

                    +"<img src=\"cid:image\">";

            EmailBaseLogic emailBaseLogic = new EmailBaseLogic();

//            String to, String title, String content, String imagePath

            emailBaseLogic.sendWithPic(email,"账户开立通知", content, filePath + "/"
+ fileName);

1.4 将用户注册信息与1.1的OTP密钥存储到数据库中

数据存储代码(略)

2 客户端工具使用

2.1 下载APP

安卓用户下载地址:http://otp.aliyun.com/updates/shenfenbao.apk

苹果手机在AppStore中搜索【身份宝】(Alibaba),或者Google Authenticator

2.2 扫描二维码

使用下载的APP,扫描1.3邮件中的二维码,客户端获取密钥。APP使用密钥基于时间算出6位校验码(每分钟变化)。

1 用户登录

客户端输入登录用户名、用户密码,以及2.2客户端工具中的6位校验码。

1.1 服务端根据用户名和用户密码获取用户信息和密钥

代码参考略

1.2 服务端使用密钥基于时间算出6位校验码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
String secretHex = "";

        try {

            secretHex = HexEncoding.encode(Base32String.decode(secretBase32));

        } catch (Base32String.DecodingException e) {

            LOGGER.error("解码" + secretBase32 + "出错,", e);

            throw new RuntimeException("解码Base32出错");

        }

        long X = 30;

        String steps = "0";

        DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

        df.setTimeZone(TimeZone.getTimeZone("UTC"));

        long currentTime = System.currentTimeMillis() / 1000L;

        try {

            long t = currentTime / X;

            steps = Long.toHexString(t).toUpperCase();

            while (steps.length() < 16) steps = "0" + steps;

            return generateTOTP(secretHex, steps, "6",

                    "HmacSHA1");

        } catch (final Exception e) {

            LOGGER.error("生成动态口令出错:" + secretBase32, e);

            throw new RuntimeException("生成动态口令出错");

        }

1.3 比较客户端和客户端校验码是否一致

代码参考略

其他,Demo中的例子可以使用身份 + 密码,先进行密码验证,在通过动态口令进行二次验证,使系统登录更加安全可靠。


Google
Authenticator是谷歌推出的一款动态口令工具,旨在解决大家Google账户遭到恶意攻击的问题,在手机端生成动态口令后,在Google相关的服务登陆中除了用正常用户名和密码外,需要输入一次动态口令才能验证成功,此举是为了保护用户的信息安全。那么,Authenticator采用了哪些算法?又是如何实现的?且看本文技术解读。

很多手机用户会使用 [Google Authenticator](https://code.google.com/p/google-
authenticator/)(谷歌身份认证)来生成认证令牌,与传统单因子密码不同,其采用的是更安全的双因子(2FA two-factor
authentication
)认证。FA是指结合密码以及实物(信用卡、SMS手机、令牌或指纹等生物标志)两种条件对用户进行认证的方法。只需要在手机上安装如此高大上的密码生成应用程序,就可以生成一个随着时间变化的一次性密码,用于帐户验证,而且这个应用程序不需要连接网络即可工作。

实际上Google Authenticator采用的算法是TOTP(Time-Based One-Time
Password基于时间的一次性密码),其核心内容包括以下三点:

一个共享密钥(一个比特序列);

当前时间输入;

一个签署函数。

共享密钥

共享密码用于在手机端上建立账户。密码内容可以是通过手机拍照二维码或者手工输入,并会被进行base32加密。

手工密码的输入格式如下:

xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

包含该令牌的二维码的内容是一个URL:

otpauth://totp/Google%3Ayourname@gmail.com?secret=xxxx&issuer=Google

时间输入(当前时间)

输入的时间值来自于手机本身,一旦我们获得密钥后,就无需与服务器再进行通信了。但是最重要一点是务必确保手机上的时间是正确的,因为往后的步骤服务器会多次重复使用之前得到的时间值,服务器只会认准这个值。进一步说,服务器会比对所有提交的令牌以确认哪一个是你输入并提交的。

签署

签署所使用的方法是HMAC-SHA1。HMAC的全称是Hash-based message authentication
code(哈希运算消息认证码),以一个密钥和一个消息为输入,生成一个消息摘要作为输出,这里以SHA1作为消息输入。使用HMAC的原因是:只有用户本身知道正确的输入密钥,因此会得到唯一的输出。其算法可以简单表示为:

hmac = SHA1(secret + SHA1(secret + input))

事实上,TOTP是HMAC-OTP(基于HMAC的一次密码生成)的超集,区别是TOTP以当前时间作为输入,而HMAC-
OTP以自增计算器作为输入,该计数器使用时需要进行同步。

算法

首先,要进行密钥的base32加密。虽然谷歌上的密钥格式是带空格的,不过base32拒绝空格输入,并只允许大写。所以要作如下处理:

1
2
3
original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))

第二步要获取当前时间值,这里使用的是UNIX
time
函数,或者可以用纪元秒。

1
input = CURRENT_UNIX_TIME()

在Google Authenticator中,input值拥有一个有效期。因为如果直接根据时间进行计算,结果将时刻发生改变,那么将很难进行复用。Google
Authenticator默认使用30秒作为有效期(时间片),最后input的取值为从Unix epoch(1970年1月1日
00:00:00)来经历的30秒的个数。

1
input = CURRENT_UNIX_TIME() / 30

最后一步是进行HMAC-SHA1运算

1
2
3
4
5
6
7
original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))

input = CURRENT_UNIX_TIME() / 30

hmac = SHA1(secret + SHA1(secret + input))

至此,2FA所需的两个因子都已准备就绪了。但是HMAC运算后的结果会是20字节即40位16进制数,应该没有人会愿意每次都输入这么长的密码。我们需要的是常规6位数字密码!

要实现这个愿望,首先要对20字节的SHA1进行瘦身。我们把SHA1的最后4个比特数(每个数的取值是0~15)用来做索引号,然后用另外的4个字节进行索引。因此,索引号的操作范围是15+4=19,加上是以零开始,所以能完整表示20字节的信息。4字节的获取方法是:

1
four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac) + 4]

然后将它转化为标准的32bit无符号整数(4 bytes = 32 bit):

1
large_integer = INT(four_bytes)

最后再进行7位数(1百万)取整,就可得到6位数字了:

1
2
3
large_integer = INT(four_bytes)

small_integer = large_integer % 1,000,000

这也是我们最后要的目标结果,整个过程总结如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))

input = CURRENT_UNIX_TIME() / 30

hmac = SHA1(secret + SHA1(secret + input))

four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac) + 4]

large_integer = INT(four_bytes)

small_integer = large_integer % 1,000,000

我在这里准备了一个完整可执行的GO语言程序,感兴趣的朋友请点击点击 [这里](https://github.com/robbiev/two-factor-
auth)进行查看。

英文出自: [Garbagecollected](http://garbagecollected.org/2014/09/14/how-google-
authenticator-works/)


当你使用网银时,网站要求提供六位数动态口令。那么网站是如何验证这六位数是不是正确的呢?验证原理是什么?

令牌实际相当于一个密码本,输进去AAA得到BBB,BBB是正确答案,验证通过。实际用的时候还会令牌会有一个时间有效性的问题,在不同的时间里输入AAA得到的答案是不同的,服务器端认为的正确答案是在随时间变动的,前一分钟有可能是DDD,后一分钟可能是MMM,一般在一个有效时间段(一般为一分钟)才会得到的答案BBB,

每个令牌都有不同ID,帐号先与令牌ID绑定,令牌会根据自身的特定ID与当前时间来计算出6位的随机码。服务器端程序因为
有了令牌ID,所以也可以根据这个令牌的特征和当前时间来生成同样的随机码,然后你提交令牌生成的验证码,服务器会验证与它自己生成的是否一致,一致就通过,不一致就提示错误……

动态口令牌使用唯一的128位种子将其初始化;其内部芯片每分钟都会使用一种算法,组合该种子与当前时间,生成一个随机的数字。而在认证服务器则采取和这个动态密码器同一种算法产生该随机数字,保证动态密码器和我行网银服务器的单一认证,就像每个客户都有了世界上独一无二的身份认证,保证客户使用网银的安全性。

服务器端和每个对应的“动态口令牌”都使用同样的一套算法,可以自定义计算数组的时间间隔。每批次“动态口令牌”都拥有唯一的序列号,然后服务器端和“动态口令牌”执行相同的计算程序,在设定好的相同的更新时间计算出新的数组.

其实上网输入密码服务器验证时跟这个动态口令牌没有有直接物理联系,唯一有联系就是二者根据唯一的序列号,利用公式,你算你的,我算我的。但同一时间算出的数字都是一样的,要不就会验证不能通过,这个6位阿拉伯数字的计算过程中时间是一个很重要的参数,使用时间参数时2者的时间必须要保持一致,要不就会时间不同步导致动态口令牌失效!

对于失去时间同步的令牌,目前可以通过增大偏移量的技术(前后10分钟)来进行远程同步,确保其能够继续使用,降低对应用的影响,但对于超出默认(共20分钟)的时间同步令牌,将无法继续使用或进行远程同步,必须返厂或送回服务器端另行处理。

原理

动态密码的密码其实不是随机的,而是由规律的。当下动态密码分为两类,时间性和事件性。何为时间性动态密码?该类令牌产出动态密码是以时间为参数的,而事件性一般以使用次数为参数的。我们以时间性动态为主要说明对象。整个验证的过程如下:

1.动态密码令牌产生动态密码 以时间和种子为参数,进行迭代,得出动态密码,这里的时间一般是秒数。每个时间性动态密码令牌中会内置一个时钟芯片。

2.服务器校验动态密码。 服务器读取系统时间加上种子,以相同的迭代方法得出动态密码,然后双方进行比对。

讲到这边,可能有所怀疑难道令牌的时间和服务器的时间一定会一致吗?我的答案肯定是不一致的。那怎么能检验的过去呢?原来很简单,服务器校验是是在一个时间区间里校验的,比如现在是12:00,服务器会生成11:55-12:05中所有的动态密码,然后和令牌产生的动态密码比对,这样不就解决了时间不一致的问题了。另外服务器会把令牌和服务器相差的时间记录下来,下次检验的会先把这个偏移值记录下来,以减少动态密码迭代次数,这样就完成了另外一个比较重要的功能,偏移值自动调整。

动态口令,又叫动态令牌、动态密码。它的主要原理是:
用户登录前,依据用户私人身份信息,并引入随机数产生随机变化的口令,使每次登录过程中传送的口令信息都不同,以提高登录过程中用户身份认证的安全性。

  银行通常提供给用户两种动态口令:
一种是固定数量的动态口令,最常见的就是刮刮卡。用户每次根据银行提示,刮开卡上相应区域的涂层,即可获得一个口令。刮刮卡成本低廉,使用方法简单,因此很多银行采用这种方法,如工商银行;
另一种是硬件形式的动态口令,即电子令牌,它采用专用硬件,每次可以用自带的密码生成芯片得到一个当前可用的一次性动态密码,交通银行等就采用这种方式。一般来讲,每个客户端的电子令牌都有一个唯一的密钥,该密钥同时存放在服务器端,每次认证时令牌与服务器分别根据同样的密钥,同样的随机数和同样的算法计算出认证时的动态口令,从而确保口令的一致性和认证的成功。因每次认证时,随机数的参数不同,所以每次产生的动态口令也不同。每次计算时参数的随机性保证了每次口令不可预测,以保证系统安全。

OTP与常用认证技术比较

目前在信息系统中使用的增强型认证技术包括:

1 USBKey: 申请PKI证书。

2 动态口令卡:打印好的密码刮刮卡。

3 动态短信:使用电信通道下发口令。

4 IC卡/SIM卡:内置与用户身份相关的信息。

5 生物特征:采用独一无二的生物特征来验证身份,如指纹。

6 动态令牌:动态口令生成器和认证系统。



动态口令认证技术不足

动态口令认证技术没有第3方权威机构认证,如果业务应用系统安全策略不完善的情况下,可能会受到中间人攻击。如某某银行使用时间型动态令牌受到网络钓鱼攻击。建议在应用中完善安全使用策略,划清口令使用权限,加强交易系统流程控制,用以提高系统安全性。

otpauth://totp/oa?secret=63985989418859891633&period=60&digits=8

secret:密钥,也就是上面生成的seed

period:每60秒生成一次

digits:生成的随机码长度


Golang的实现

https://www.jianshu.com/p/e4b574be0ba6

Java服务端的实现:

https://github.com/wstrange/GoogleAuth

https://github.com/suyin58/otp-demo

Python的实现:

https://github.com/sahands/python-totp

Flutter、Dart的实现:

https://github.com/vubon/dart-totp

算法原理:

https://blog.csdn.net/qq_29951983/article/details/80814272

Measure

Measure

黑客为什么不攻击支付宝?

“支付宝被黑客搞了!!!”

女票发给我一段视频。

中哥我虎躯一震,这么大的事儿居委会咋没通知我??赶紧打开视频。

我去,这是黑客吗?谁来解释一下,明明是黑客,为神马穿得这么白,连脸都是白的。。。

还有,你带着那个面具敲代码,能看清鬼啊?这是在练盲打么??闭着眼睛攻击支付宝,是为了表现一种蔑视和侮辱么???

往后看了五分钟,冷静了一下,我不禁三呼卧槽。这是一个叫做《智造将来》的节目,浙江卫视的。虽说黑客的装束槽点满满,但干的事情还是很刺激的:

他们在试图推倒三个身娇体柔的支付宝账户,把账户里的钱偷偷转走。。。

主持人说,他们之所以搞得这么硬核,就是为了现场检测一下支付宝的安全性能到底好不好,你的钱放在支付宝里到底安不安全。

为了让大家舒爽看片,这里中哥插一嘴:

支付宝怎么保护大家的账户安全呢?并不是你想的那样,在杭州有一个脸上贴着“支”的敢死队,每天在网上和黑客手动硬刚。

真实情况是,“安保工作”是由安全部门的童鞋开发的一套“风控系统”来自动完成的。这套风控系统有点像参加高考的你,在之前的学习阶段有“老师”各种辅导,但是一旦被推到实战场景里,就只能靠自己“自动滑行”了。

回到节目现场,情况很是危急。一边是黑客奋力攻击,一边是受害者支付宝各种殊死抵抗。

就在我为支付宝捏一把汗的时候,剧情突然走向癫狂:受害者家属也来到了现场!

这个男人叫雄文,是支付宝风控部门的老大,蚂蚁金服的副总裁。支付宝的安全系统,就是他团队的作品。一堆头衔你也记不住,这么说吧,如果你支付宝里钱丢了,就找他赔。

看到雄文这个名字我就震精了,目测支付宝安全老大,应该管理很多码农。不叫“佳娃”(Java)或者“稀加”(C+),居然叫雄文,这是摆明了有野心跟中哥抢夺10w+啊。。。

对不起跑偏了,继续看节目。

对第一个账户的攻击开始惹。黑客攻击主持人蒋昌建的支付宝。他们事先通过钓鱼 Wi-Fi
收集了他的手机号,然后又利用近场读卡器偷到了他的银行卡号。用这些信息尝试 重置他的支付宝密码
。然而,重置支付宝密码还需要身份证,黑客并没有办法拿到蒋昌建的身份证号。于是登录他的支付宝 失败

对第二个账户的攻击开始惹。黑客攻击的是嘉宾王孟秋的支付宝。这次攻击的对象黑客通过“撞库”拿到了王孟秋的支付宝登录密码,顺利登陆。但是由于不知道支付宝支付密码,所以转账失败。

对第三个账户的攻击开始惹。这次攻击目标是现场一位观众的支付宝。由于提前在这部手机里植入了木马,黑客可以完全控制这部手机,所以他们使用手机验证码就直接登陆了支付宝。然后黑客选择修改支付密码,修改支付密码需要验证个人信息,黑客又通过手机里存储的银行卡和身份证照片,成功修改了支付密码。转账眼看就要成功。

我满心激动,等着看黑客使出最后的杀手锏一击致命。。。

然后。。。突然。。。转账失败了!节目结束了!结束了!束了!了!

纳尼?XX都X了你就给我看这个?我期待中支付宝被黑客干翻在地的场景被XX总局吃了吗?

我突然想起了一个新闻:

女棋士赢了。。。

用了好久,我才接受支付宝真的赢了这个事实。虽说在节目上支付宝赢了,然而,在日常和黑客的乱斗中,支付宝难道就没有输的时候吗?我不信。

于是,中哥下定决心要去和雄文聊聊,写一篇雄文背后故事的雄文,让大家认识一下我雄文里的雄文到底是怎样的雄文。

几天后,在支付宝童鞋的引荐下,我坐在了雄文大叔的对面。我不是要和他下棋,而是要探究一下支付宝背后的秘密。

雄文

(一) 支付宝能不能扛住“黑客围殴”?

“老实说,节目上被攻击的支付宝,是不是假的支付宝?”我劈头盖脸就问。

“当然是真的支付宝。”雄文云淡风轻。

“你怎么证明?”我说。

“为了电视节目,如果要模拟一个假的支付宝,还要做出一套假的风控系统,要开发好多代码。太麻烦了。还不如用真的。况且真的风控系统我们做了十几年,干嘛要用假的。。。”他说。

“所以,被攻击的那三个账户,也是真的咯?”我问。

“如假包换”他说。“支付宝账户都是实名制,背后挂着身份证的。不仅用不了假的,做节目的时候,连真的都差点用不了。。。”

纳尼?雄文大叔在说什么?

原来,在节目录制之前,需要进行一次彩排。彩排时候选定了三个账户被黑客一顿锤,支付宝防住了,一切都没问题。结果第二天要正式录制的时候,奇特的事情发生了——这三个账户被支付宝风控系统判定为受攻击高危账户,直接保护起来了,暂时限制对外转账功能一段时间。。。无奈,节目组只能另外换三个账户。也就是最终出现在节目上的那三个。

“系统都是自动运行的,被封住的账户,就连我也无权解开。。。”雄文一摊手。

我去,你是魔鬼吗?支付宝风控系统疯起来连自己人都刚啊,六亲不认,肃然起敬。

“这支付宝的风控系统,叫个啥名?”

“叫 AlphaRisk!”他说。

“账户是真的,攻击是真的,AlphaRisk 的防御也完全是自动化的,那么也就是说在节目现场,你根本不知道它能不能挡住黑客的进攻咯?”我问。

“是的。”

“那你慌么?”

“有点。”

“。。。”

雄文这么不按套路出牌的坦诚,让我本来准备好的一万个质疑都瞬间失效。

“录节目时你最慌的是什么时候?”

“AlphaRisk
判断一个账户是不是被盗用,是要综合很多指标来判断的。其中一个重要的维度就是看转走多少钱。结果在节目彩排的时候,黑客强行登录支付宝账号以后,居然只转5块钱!说实话,这么少的金额,是有可能被
AlphaRisk 放过的。转这么少钱,也没跟我商量,当时我真是捏了一把汗。还好支付宝给力,拦住了。”雄文吐槽。

感觉白衣黑客们费劲气力,才看清5这个按键在哪。。。

雄文当时的表情是这样的。

看看,在节目上黑客攻击三个支付宝账户都功败垂成时,雄文有多开心。

支付宝曾对外发布了一个数据:资损率低于千万分之五。意思就是,存在支付宝里的钱,出问题的概率低于千万分之五。

千万分之五,真牛X!等等,好像哪里不对。。。假如我就是那倒霉的千万分之五,我是不是要去杭州上访?

“不用,如果你的支付宝真的没被拦住,被盗了,我们赔给你就是了。”雄文淡定地说。

确实,我记得支付宝从2004年上线之后,就有一个口号叫“你敢付,我敢赔。”只不过说实话这么多年中哥的支付宝账户也没丢过钱,不知道他们到底是赔不赔。。。既然今天支付宝副总裁都这么说了,那我放心了。

也就是说,理论上支付宝并不能保证防御住每一次具体的黑客攻击,但这对于普通用户来说那不重要,因为每个人的钱都是绝对安全的。

说实话,见到雄文之前,我是没想到他会这么坦诚的。好不容易逮到他,得多问点电视台不让播的内容。

接下来就到了中哥硬核科普时间了,今天的话题是:

** **

你家支付宝的门神——AlphaRisk——到底是咋工作的?

(二)黑客偷钱,总共分三步

你可以简单想象一下,用支付宝转账,要过三道大门:

第一道:登录密码;

第二道:支付密码;

第三道:AlphaRisk 风险控制系统。

雄文说。

来,我们一道一道地科普。

第一关、登录密码

这个很简单。你登录支付宝的时候,要输入登录密码,证明你是你。

你可能会杠说,不对啊,我每次在手机上登录支付宝,不用输入密码,直接就打开了啊!没错,那是因为你经常登录,并且没有换手机。这种情况下,你账户有风险的概率很低。支付宝没有必要每次都打扰你,让你输密码。

这里,我们学到了今天最重要的一个概念:打扰率。

一个
App,每要求你做一件事,比如输入密码,比如让你接收一个短信验证码,这都算一次打扰。而在用户体验中,打扰是要扣分的。所以,通过频繁打扰用户的方式来保证你的“绝对安全”,并不是个好办法。

由上图可知,频繁打扰是一件很烦的事,这个问题涉及到深奥的产品哲学,我们在最后还会详细讨论。

我们继续说登录密码。

如果你在一部手机里很久都没有登录支付宝,那是需要重新输入密码的。如果你换了一部新手机登录支付宝,那么不仅要输入密码,还要二次校验(短信验证码或者回答安全问题)。

所以,黑客单单偷到了你的支付宝登录密码,是无法直接登录你的支付宝的。那他们是怎么做的呢?中哥可以告诉你几种可能性:

1)你的身份信息泄露严重。

刚才我说到,支付宝密码是可以被重置的,需要提供身份证、银行卡等一系列信息。如果这些信息隐私信息都被黑产掌握了,那么从某种程度上说,他就是你了。没办法,你的密码也会被重置,他可以登录。

2)你的手机丢了。

你的手机丢了的意思是——你的手机不仅丢了,并且没有设置开屏密码或指纹解锁。否则坏人解不开你的手机,就跟没丢一样。

反正黑客只要进入你的手机主屏,接下来就有两种情况:

你在几天内用过支付宝,那么,黑客不用输入密码,就像你本人使用一样,能直接登陆。

你最近没有登录支付宝,那么支付宝会要求你输入密码,此时黑客可以选择重置密码,选择手机接收验证码,也是可以重置密码成功登录的。

此乃第一关。

第二关、支付密码

** **

如果坏人破解了你的登录密码,那么接下来他想把钱转走,就要遇到“支付密码”这道关口。

你记得不,支付宝会要求你的支付密码和登录密码不同,目的就是为了防止坏人破解了你的登录密码,直接就能攻破你的支付密码。

这里有个小细节:支付宝最近几年会鼓励你用指纹代替支付密码。当然,用户也可以手动选择切换——这次支付不用指纹,就用密码。这关实际上挡不住黑客,但是你要记住这个细节,一会儿有用。

接下来我们继续说黑客怎么攻破你的支付密码:

1)用你之前泄露的其他登录密码尝试。

一般人不会把支付宝支付密码和其他应用的登录密码设置为一个,这种方法成功率从实战数据中看比较低。

2)重置你的支付密码。

重置你的密码,需要你的个人信息,或者需要你的手机。如果黑客已经掌握了这些,那么他很可能重置支付密码成功。

你一定以为:黑客破了我的支付密码,钱就会被转走了噜。

错!图样图森破!黑客的噩梦才刚刚开始。

马上就会进入第三步骤:AlphaRisk。

第三关、AlphaRisk

前面两步,黑客的所有操作,其实 AlphaRisk 都在默默看着,只是它没说话而已。

当前两个密码都输入正确后,AlphaRisk 会作为最后一道门神,像尉迟恭和秦叔宝一样,决定放不放走这个钱。

那么,AlphaRisk 判断的依据是什么呢?

举个栗子:一个老警察靠在公交车站,他如何发现一个正在挤上车的小伙是个贼呢?他会通过几个维度:眼神、举止、穿着、和前人之间的距离、是否遮挡手上的行为等等等等。有经验的警察不用等到“偷钱”那个动作发生,就已经能准确判断谁是小偷。

同样,AlphaRisk 也像一个老警察,它也会从一些维度来观察一笔交易。比如:设备、环境、偏好、行为、关系、账户、身份、交易,等等。

如果其中所有维度任何一个或者多个有异常,都会引起 AlphaRisk 的警觉,直接强制操作者进行人脸活体验证,手机验证码,或者干脆就截断交易。

不知你感受到了没。日常你用支付宝转账给别人,你觉得非常自由,支付宝从来不添乱,恰恰是因为 AlphaRisk
对每一笔交易都做了极其细致的评估之后,觉得没问题才不拦着的。

你可能会问,为神马 AlphaRisk 等到那么惊险的最后一步才起作用呢?早点出来这个“哔——”就装得不够到位吗?

这个地方又涉及到刚才的概念——打扰率,如果支付宝在输入交易密码之前就用 AlphaRisk 跳出一堆人脸验证手机验证码,那就会让你觉得很烦。作为一个有尊严的
App,支付宝把安全性最强的 AlphaRisk 放到最后一步,就是为了最少的打扰。

下面说 AlphaRisk 的工作细节。

以《制造将来》里面的操作举例。攻击第三个手机的时候,黑客已经拿到了登录密码和交易密码,并且是照着身份证的照片把身份证号一次输入正确的,为神马
AlphaRisk 会认为这个交易有风险呢?

用大家都能理解的话说,大概是酱:

首先,支付宝是在陌生的手机上登陆的;

其次,支付宝的登录密码是刚刚被重置过的;

再次,支付宝的支付密码也刚刚被重置过;

还有,转出账户和被转入账户之间没有任何人际关联;

还有,转出账户所在城市和被转入账户所在城市,本身就很少存在转账行为;

等等等等。

其实,还有很多不正常的维度可供 AlphaRisk 参考。

比如刚才我故意卖了关子的一个细节:操作者本来习惯用指纹支付,突然今天强制改成了密码支付。这一个蛛丝马迹,起码说明事出有因,足够让 AlphaRisk
关注到这次交易的风险。

啊,说了这么多,终于大概解释清楚了支付宝风控的三道关。

雄文告诉我,支付宝也不是一开始就有这么强大的智能风控能力的。

在2004年,支付宝刚上线,他们就大喊“你敢付,我敢赔”的口号。实际上在那个时候,支付宝还真是“敢赔”。意思是,虽说风控技术有点糙,但我们胆子大,敢赔钱给用户而已。。。

“那后来你们是怎么一步步提高风控能力的呢?”我好奇的地问。

“你要是那么哗哗地赔钱,你也会拼了老命提高风控能力的!”

“。。。”

(三)偷不到钱,那骗钱行不行?

有一个问题其实很值得一说。

宽泛来说,支付宝账户受损失,有两种情况:1、账户被盗;2、你被诈骗之后主动转钱给别人。

当然,你的账户被盗,支付宝会赔钱给你。但如果你被骗,用支付宝主动转钱给骗子,就没办法找支付宝赔钱了。毕竟,被骗不能赖钱包。

但是雄文告诉我,作为一个有追求的钱包,这两年支付宝恰恰在“识别诈骗”方面苦练技巧。

这种对诈骗的识别能力,同样在 AlphaRisk 身上。

骗子骗人,一般都是直接打电话,或者在微信上骗,那些过程支付宝肯定不知道。它只能看到一个账户给另一个账户转了钱。。。通过这么少的信息,它怎么能判断你是不是被骗了呢??

雄文给我讲了一个真实的例子。

一个妈妈,她的孩子在外地打工,做快递小哥。突然有一天,她接到了一个陌生电话,告诉她儿子出了车祸,急需抢救,需要她打钱过来。妈妈开始没相信,把电话挂了。但是身边的电视正好播出了一条新闻,说他儿子所在的城市,有一个送货小哥出了严重车祸。这下她着急了,赶快给对方回电话,要把钱转过去。

就在这位妈妈把钱转给骗子的时候,AlphaRisk
判断了风险,并且弹出了提示,告诉她有这笔转账可能是被骗了。妈妈选择无视,关掉弹窗继续转账。这次,AlphaRisk
判断强风险,直接阻断了交易,锁定账户两小时。

这位妈妈非常生气,觉得自己的儿子出了事,支付宝却不让转账,于是拨打客服理论。正在这时,他的儿子碰巧打电话给妈妈,这才揭穿了骗子的骗局。

在这个例子中,AlphaRisk 是凭什么判断转账存在诈骗风险呢?

雄文说,至少有三点:

1、妈妈平常的支出,都是小额的日常生活,买菜超市,突然一下转几万块显得很异常。

2、对方的收款账户是新注册的。而且近几日只有大额收款和提现,并没有日常消费。

3、这两个账户之间从未有过直接转账。

你看,基础逻辑和判断账户被盗差不多,只不过,判断被骗可以利用的信息比判断被盗少得多,所以难得多。

但最让雄文头疼的是,截断用户付款固然好,但是万一截错了,用户是要跟支付宝拼命地。。。支付宝但凡截断用户的交易,必须证据确凿。如果没有百分百的证据,一般会选择弹窗提示。然鹅,很多时候即使支付宝弹出了警视窗,用户都会选择直接关掉,没啥作用。

即使是这样,雄文团队也对弹窗内容改了又改,可谓是苦口婆心啊。

这是修改前的 ↓↓↓

这是修改后的↓↓↓

前两天,雄文和团队突然找到了一个好方法,他们和地方反诈骗中心“合作弹窗”。例如你是重庆人,在支付宝判断你的一笔交易有风险时,弹出的内容不是“支付宝提醒您注意诈骗”,而是“重庆反诈骗中心提醒您,这个交易有可能是诈骗。”

“这样一下,用户终止交易的比率大大增加!”改了几个字,就能让好多人少上当。雄文老激动了,这两天从地方到中央找反诈中心公安局各种合作。

“到目前为止,用户遭受诈骗,有85-90% 都能收到弹窗提示。”雄文大叔开心地说。

现在是这样↓↓↓

说到这,雄文大叔给我普及了一个金融小常识:

一般的在线交易系统,对于转账这个操作,只涉及“转出”和“到账”两个状态。这边转出之后,那边就到账。就像一盏灯只存在“开”和“关”两个状态。不可能存在“这边钱扣掉,那边还不到账”的情况。

但是支付宝为了防止诈骗,开发了第三个状态:类似“预授权“。如果你觉得这次转账有风险,可以设置2小时或者24小时延时到账。这种情况下资金就在“预授权”状态。在这个期间如果你发现被诈骗,可以报警并向支付宝申请冻结资金。

“预授权“状态的钱,按理说到时之后就会顺利进入转入账户。但只要有公安机关的相关凭证,就可以退回到转出账户。

别看只是加了一个“预授权”的状态,这相当于给了受害者一个“时光机”,回到过去,改变那个无可挽回的错误。

雄文说,为了增加这个新状态,他们两年里对支付宝底的层代码做了很大的修改。虽然大动干戈,但这件事非常值得。

(四)玩漂移的老司机

讲真,人类对一台机器的要求是很变态的。好的机器不仅要代替人,还要比人更精神。

毕竟是亲生的, 说到 AlphaRisk,雄文特别开心。他觉得如果2017年支付宝没有开始研究
AlphaRisk,现在很多风控策略还靠人肉的话,一定会被“时代的洪流”所击垮。

如今,AlphaRisk 有两个杀手锏:

1、和人比,它厉害到不知哪里去了。

你可能已经知道,AlphaRisk 就是一种“人工智能。你作为一个人每天家长里短悲欢离合其实本质都是判断,人工智能每天也是做一件事:判断。

人工智能判断事情的标准,和人又像又不像。这里涉及到一个大家普遍理解得不好的技术梗,中哥正好以 AlphaRisk 为例简单科普几句:

人工智能和人各自做一个判断,有点像两个大厨分别做一桌菜给你吃。这分为三步:

1、他们使用的原料种类都是一样的青椒、萝卜、鸡肉等等。(这意味着人工智能和人用于判断一件事情的基础数据是一样的。)

2、但是,他们炒菜的路数可就不一样了。人类可能会做出鱼香肉丝、宫保鸡丁、水果拼盘,但是机器会根据自己的理解做出西瓜披萨,苹果蒸蛋、巧克力烧茄子等等常人不能想象的饭菜。(这意味着人工智能的判断模型和人既相似又不同。)

3、最后,两桌菜分别上来,食客们会发现,两种菜虽然不一样,但是都能填饱肚子,而且机器做的明显更好吃更营养。(这意味着人工智能判断的准确度比人类还高。)

简单总结人工智能的工作原理:通过人类看都看不过来的数据,用风骚的机器思维,做出一击致命的判断。

这里给你几个数据你感受一下。

AlphaRisk
用来判断的风险点有几千个(如交易金额、支付宝注册地、交易时间、使用密码支付还是指纹支付等)。把这么多数据进行惨无人道的交叉运算,总运算量是巨大的。

在平时,每秒钟全世界都会用支付宝进行上万次的交易。如果在双十一这种狂欢节,每秒支付宝要处理25万笔交易。你想想看,就像商场的收银台后面,排队排了25万个顾客,每一笔交易,AlphaRisk
都还要计算无数次来判断它是不是有风险,这得累计多大的计算量。。。

如果这些计算量交给人来做,等到算完,估计已经到了9102年双11了吧。

这么疯狂的机器,日常得有不少码农为它检修上油吧。。。

雄文说哈哈哈NO!因为,这两年他们已经搞出了一套“自动驾驶”系统。

纳尼?支付宝也会开车了么?求车牌号!其实,不是你想的那样,这就到了 AlphaRisk 的第二个逆天优势。

2、这是个会自动驾驶的老司机。

那些做坏事的黑客,连过年都不休息,天天“苦炼内功”,不断升级自己盗取支付宝账户和诈骗用户的技术。这是为什么?因为他们知道,如果能早几天研究出一个盗取支付宝的方法,那赚的钱可比在支付宝上班的码农加班费多多了。

对手那么疯狂,AlphaRisk 也要加油才行啊。正常情况下,AlphaRisk 想要学会新的反诈骗套路,要工程师手动输入代码。

但是,雄文和支付宝安全团队的队员很“懒”,他们觉得,AlphaRisk 已经长大了,不能每天晚上给它“检查作业”,它要自己学习新的知识了。

所以过去两年,攻城狮们很少砍柴,主要磨刀。他们建立了一个自动建模的系统。每天都会有一些用户损失通过投诉渠道反馈到支付宝风控团队,这个自动建模系统就可以通过学习这些AlphaRisk
没有拦截成功的案例来建立新的风险模型,然后把这个模型输入到 AlphaRisk 里,下次再遇到同样的问题,AlphaRisk 就能一眼识别。

自动建模还不是全部。

你知道,每年双11的时候,支付宝会像雷峰塔一样,承受一下交易量水漫金山的感觉。这个时候,如果还执行原来的风控策略,就会导致计算力严重不足的情况。本来人家零点秒杀,结果支付宝算了十秒钟,跟人家说没问题去付钱吧。结果秒杀的限量款衣服早都被人家抢得毛都不剩。这会造成大批群众到杭州上访的。。。

所以,支付宝需要根据不同的情景,调整 AlphaRisk 的风控策略。这就像一辆车,根据路况不同,切换12345档。

原来每到双11,攻城狮们就会写一套新的风控策略,为 AlphaRisk 手动换挡。从2017年开始,完全不用了。AlphaRisk
学会了骚气的自动换挡。交易量巨大的时候,就自动切换为高档,交易量低的时候,就瞬间调回来。

这不就和汽车的自动驾驶是一回事么。。。

我第一次发现,原来自动驾驶不仅仅是汽车领域的人工智能。凡是需要复杂人工智能的场景,其实都有自动驾驶的一席之地。甭管是人是机,反正这个世界缺不了老司机。

(五)三个“隐秘战场”

其实,中哥知道,科普半天支付宝 AlphaRisk 的风险识别技术,你也未必听得进去,因为我已经提前剧透了,反正你丢了钱支付宝会赔给你。

不过,要是你以为雄文和支付宝风控团队只玩技术,那就太小看他们了。

有道是:“科学的尽头是哲学。”

这句话不无道理。好多事是科学解决不了的。比如你女票天天吵着要买钻石戒指,你告诉她从科学角度说那玩意儿其实就是碳,那你当晚必定自己睡。

虽说支付宝的风控做得很科学,但是雄文却每天都面临三个哲学问题:

第一,打扰率和资损率如何平衡?

之前我们已经介绍过这个重要概念“打扰率”,就是支付宝为了保障你账户的安全,弹出来一些验证提示等等打扰你的行为的概率。

当然技术水平是在不断进步的。但假设在技术保持不变的情况下,这是个跷跷板。打扰率越高,资损率就越低。

如果让中哥这样的抠门来做决定,那估计是要把资损率降到极限,对用户的打扰率有多高。。。爱咋咋地。。。因为这样能保证赔出去的钱最少。

当然,支付宝没有这样做。他们在资损率降低到千万分之五之后,转而把技术重心放在了降低打扰率和诈骗识别上。

资损率低到千万分之五的时候,我们就认为被盗是小概率事件了。即使被盗,也能做到全额赔付。这个时候,我们要用技术的进步让用户体验到温度。

雄文说。

正所谓:“有技术的 App 千篇一律,有温度的 App 万里挑一”。表面上看,这是一个产品哲学和技术取舍。但在这个天平上,你其实可以测量用户的重量。

第二,赔付与不赔付如何平衡?

你可能会说,不是刚刚都说了么,被盗就赔,自己转给骗子不赔。

没错,但是在现实生活中,总有那些让人哭笑不得的中间地带。

我随便给你举两个例子。

第一个例子:卖早点的老张,把自己的收款码放在早餐车柜台上,结果有一天,一个混球突然把老张的收款码偷偷换成自己的。老张忙着做早点,结果半个小时才发现。他联系支付宝客服,你是支付宝的话,你赔还是不赔?

直接说答案,赔。原因很简单,做生意不容易,虽然二维码被偷梁换柱不是支付宝的责任,但是支付宝不想让诚实的人受损失。

别看雄文说得轻描淡写,当初决定二维码偷换也要赔的时候,所有人可是下了老大的决心的。因为,付款码偷换的整个流程,都不是支付宝能监督控制的,所以他们不知道如果赔的话,要赔出去多少钱。

雄文记得,那时候他跟支付宝老大井贤栋商量这件事,井贤栋立刻就同意了,他说:“我们准备个几亿,先赔着。”支付宝还专门给小摊主设计了一个语音播报的功能,收到款手机就会大声喊出来。

当然,事后证明广大摊主并没有那么粗心,自己的二维码被偷换了还不知道。数据显示,真正因此受损失的小商家很少。

第二个例子:小美联系支付宝客服要求赔偿,说一觉醒来支付宝里几万块的余额不翼而飞。但是支付宝通过数据查看, 这笔钱是用她的手机,在她家的 Wi-Fi
环境里,密码根本没有被重置,都是一次输入正确而被转走的。AlphaRisk 认为这很可能不是被盗,说白了,有可能是“监守自盗”,如果你是支付宝,你赔不赔?

直接说答案,不一定赔。原因也很简单,因为大家都要诚实。如果涉及到欺诈,支付宝并不能蒙受不白之冤。

这是个真实的案例。后来的警察调查发现,这是她交往十年的男朋友,因为沾上了赌博不敢说,趁她睡觉的时候偷偷把钱转走的。

雄文告诉我,支付宝风控部门有一个专门的团队,就是处理这种介于赔偿和不赔偿之间的中间地带。如果确实有警方介入,没有发现是监守自盗或亲友作案,那么支付宝就会赔付。

第三,安全和安全感之间如何平衡?

你有没有过这样的经历:给别人转好大一笔钱,结果支付宝问都没问,直接放行了你的转账。这时你的心里会闪过一丝不安全感,就像穿着短裙的女装大佬,总感觉空空荡荡的。

其实,AlphaRisk 在背后已经帮你掐指一算,判断了你的转账没有风险,只不过没有明确告诉你。

雄文说,这是他们团队最近在努力思考的问题:“安全”没问题,但是用户的“安全感”有问题,这要怎么平衡?

其实有关“安全”和“安全感”的问题,历史上有个经典公案。汽车门关上的时候,本来是没有声音的,但是广大司机们听不到声音,总觉得车门没关好,百爪挠心。于是,索性各大车厂专门设计了一个机关,让车门关闭的时候发出坚实的“砰——”。然后,天下太平。。。

“所以,你们也要在某些不需要打扰用户的时候,弹出验证消息吗?”我问。

“谁说得准呢?”雄文笑了。

没想到,每天我打开支付宝只是付个钱买个余额宝,其实它背后正在发生着无数秘密战争——支付宝风控团队带着 AlphaRisk
时刻在改进风控技术,并且在这样那样的平衡之间精确腾挪。

告别雄文。走在杭州冬天温润的空气里,我突然觉得心情很舒畅。

一次偶然的电视节目,却让我认识了这么一位温暖的大叔,还有背后守护我们的工程师们。

我记得曾经在网上看到过这样一个帖子:“黑客这么厉害,为什么不去攻击支付宝?”

现在我觉得自己大概能回答这个问题了:他们攻击了,只是你不知道,因为有人在替你负重前行。

很多备受推崇的产品经理在介绍经验时,总是强调“人心”二字。当时,我未免觉得这是一种政治正确的姿态。但当我和无数大佬聊过之后,越来越发现一个真理:

** **

技术可以打下世界, 但只有良知可以赢得人心。

世界辽阔,而且,没有想象中那么糟。

O,对了,想看这期节目的,可以上优酷搜索“智造将来”,2019年2月3日那期。

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×