关于golang:手机没网了却还能支付这是什么原理

0次阅读

共计 3787 个字符,预计需要花费 10 分钟才能阅读完成。

来自公众号:程序通事

当初生存曾经离不开微信 / 支付宝电子领取,平时进来吃饭、购物只有带个手机,就能够解决所有,以致于当初曾经好久没摸过真???? 了。

有一次进来吃饭,排着队付钱,等着过程十分无聊,筹备插入手机来把荒野乱斗,却发现这个中央居然连不上网。

看着手机明明信号满格,然而就是显示网络无连贯,苹果手机用户痛,谁用谁晓得。

画外音: 真的要 Diss 一下应用英特尔基带的 Iphone,???? 好差,没事网络就会闪断~

说回正题,因为没有网络,而我又没带钱,所以就怕付钱的时候因为手机没网,没方法应用支付宝扣款。正想着时,曾经排到了我,不管三七二十一,先用下支付宝试试,切实不行就不吃了。

不过没想到,当商家用扫码抢扫描支付宝上付款码领取当前,尽管我的手机最终没有弹出领取胜利的页面,然而商家端显示领取胜利,并胜利打印出了小票,过了一会,我的手机收到支付宝扣款短信。

因为我最近的工作对都是与微信 / 支付宝无关,整体领取流程还是比较清楚,然而付款码为什么能离线领取的确不是很分明,所以钻研了一番,于是有了明天的文章。

科普领取形式

在聊 付款码离线原理 之前,咱们先给不相熟支付宝 / 微信领取形式同学先科普一下常见的两种领取形式。

微信、支付宝 线下领取罕用领取形式有两种,一种是咱们关上手机,被动扫描商家提供码牌,这种领取形式个别称为主扫领取(用户被动扫码)。

支付宝 为例,付款流程 如图所示:

第二种则是咱们关上手机,展现咱们的 付款码,而后商家应用扫码枪等工具获取付款码实现领取,这种领取形式个别称为被扫领取(用户被扫码)。

以支付宝为例,付款流程如图所示:

对于第一种形式,须要手机端 APP 扫码,而后弹窗确认付款,这种形式是没有方法在手机没有网络的状况实现领取,所以咱们上文说的没有网络的状况特指付款码领取的场景。

付款码付款流程

在聊 付款码离线领取 的前提前,咱们先来来看下付款码的 整体流程 ,以 超市购物为例,一次付款码的领取信息流如图所示:

这个过程商家后盾零碎是须要调用的支付宝条码领取的接口,实现领取。

「因为商家后盾须要在线联网与支付宝后盾通信,所以说付款码的离线领取,指的是客户端没有的网络的状况,商家端其实必须实时联网在线。」

一次付款码接口调用流程如图所示:

通过下面两张图,咱们整体理解付款码交互流程。

付款码的技术计划其实能够分为客户端在线与离线的两种状况,上面咱们来看下两种计划具体实现形式。

在线码计划

客户端在线码的计划,这个应该比拟容易想到,只有支付宝 / 微信在登录的状况下,点击付款按钮,客户端调用后盾零碎的申请付款码接口。

后盾零碎受到申请之后,生成一个付款码,而后在数据库保留付款码与用户的关系,并且返回给客户端。

只有客户端在有效期内展现该付款码,就能够实现领取,否则该二维码就将会过期。

应用这种计划,相对来说比拟平安,因为每次都是服务端生成码,服务端能够管制 幂等,没有客户端伪造的危险的。

另外即便须要对付款码规定调整,比方付款码位数减少一位,咱们只有调整服务端代码即可,客户端都无需降级。

「不过这种计划毛病也比拟显著,客户端必须实时在线联网,没有网络则无奈获取付款码。」

另外,当初有一些智能设施也开始反对支付宝领取,这些设施中很大一部分是没有联网的性能(比方 小米手环四),那这种状况是没方法应用在线码计划。

基于这种状况,所以开始有了离线码计划。

离线码计划

说起离线码大家可能比拟生疏,然而实际上你如果仔细观察,其实很多场景都用到了离线码。

比如说以前去黑网吧玩梦幻西游的时候,账号总是被盗。

没方法,花了一笔重资买了一个网易将军令,每次登录的时候,除了输出用户名与明码以外,还须要输出动静口令。从此账号就很少被盗了。

又比如说每次网易领取的时候,咱们除了输出银行卡明码以外,还须要输出 网银盾上动静码,这样能力实现领取。

画外音:
图片这里又要吐槽一下,网银盾以前真的超难用,动不动就驱动不兼容。还记得当初用网银充值黄钻,搞了一下午都没有胜利 –!

当然下面这些可能曾经是 老古董 了,很多人都可能没用过,当初比拟风行是「手机验证器 APP」,比方 「Google Authenticator」 等。

这种令牌器,动静产生一次性口令(「OTP, One-time Password」),能够避免明码被盗用引发的平安危险。

其实付款码离线计划技术原型就是基于这种计划,所以上面咱们就基于 Google Authenticator,来理解一下这其中的原理。

动静口令技术原理

首先如果咱们须要应用 「Google Authenticator」,咱们须要在网站上开启二次验证性能,以 Google 账号为例,在设置两步验证的中央能够找到如下设置:

当咱们点击设置,将会弹出一个二维码,而后应用「Google Authenticator」APP 扫码绑定。

当咱们绑定之后,「Google Authenticator」APP 将会展现动静码。

咱们来解析一下这个二维码,对应上面这个字符串:

下面的字符串中,最重要就是这一串密钥 secret,这个是一个通过「BASE32」编码之后的字符串,真正应用时须要将其应用「BASE32」解码,解决伪码如下:

「这个密钥客户端与服务端将会同时保留一份,两端将会同样的算法计算,以此用来比拟动静码的正确性。」

咱们以客户端为例,生成一个动静码,首先咱们须要通过一个签名函数,这里 Google Authenticator 采纳的「HMAC-SHA1」,这是一种基于哈希的音讯验证码,能够用比拟平安的单向哈希函数(如 SHA1)来产生签名。

签名函数伪码如下:

下面函数中的,input 应用以后工夫整除 30 的值。

这里工夫就充当一个动静变参,这样能够源源不断产生动静码。

「另外这里整除 30,是为了赋予验证码一个 30 秒的有效期。」

这样对于用户输出来讲,能够有短缺工夫筹备输出这个动静码,另外一点客户端与服务端可能存在工夫偏差,30 秒的距离能够很大概率的屏蔽这种差别。

通过「HMAC-SHA1」签名函数当前,咱们失去一个长度为 40 的字符串,咱们还须要将其转化为 6 位数字,不便用户输出。解决的伪码如下:

残缺的算法伪码如下:

当客户端将动静码上传给服务端,服务端查询数据库获取到用户对应的密钥,而后应用同样的算法进行解决生成一个动静码,最初比拟客户端上传动静码与服务端生成是否统一。

付款码离线计划

下面咱们理解了动静口令的实现计划,付款码生成原理其实也大抵如此。

不过付款码离线计划采纳动静密钥的形式(「全局惟一」),定时申请服务端更换密钥,以此保障更高的安全性。

另外在一次性动静口令计划,须要单方基于同样的秘钥,所以服务端须要明确晓得这「背地正确用户」。以下面的登录场景为例,登录过程输出用户名, 服务端就能够依据这个在数据库中查问相应的密钥。

然而在付款码的领取场景中,领取过程仅仅传递一个付款码,就能够向相应的用户扣款。不必想,这个付款码这串数字肯定蕴含相应的用户信息。

所以付款码的相应的算法相比动静码会更加简单,这样才能够无效保障安全性。

看到这里,不晓得你们是否急迫想理解这套算法那?

哈哈,开个玩笑,这种算法岂能是咱们能把握的。

支付宝外围算法咱不晓得,然而咱们能够从其他人公开设计方案理解一个皮毛。

这里小黑哥给你一个知乎网友 @反方向的钟答复的离线二维码实现形式,给你 look look。

付款码离线码的劣势

最初咱们来看下付款码离线计划的劣势:

第一,算法调整不灵便,如果相干算法较大的调整,可能须要降级客户端, 并且这个期间服务端还须要兼容新老算法产生的付款码。

第二,安全性问题,失常的状况相干密钥无奈被普通用户获取,然而架不住有有心之人。他们可能通过获取手机用户 Root 权限或者越狱手机,利用恶意程序获取密钥,而后随便生成付款码。

看到这一点,大家可能会放心本人的钱包平安了。不过这一点,我感觉不过过分放心,蚂蚁团体这么多大神,不是吃干饭的,他们必定有很多措施保障领取平安。

第三,数据碰撞问题,A 用户生成付款码算进去与 B 用户统一,这就 Hash 算法一样,再怎么优良的算法,也有概率才生一样的额 Hash 值。

这就导致本来是扣用户 A 的钱,最初却扣了 B 用户。这样一来,的确很乌龙,对于 B 用户来讲,莫名其妙被扣钱了。

不过释怀,这种事放到放到当初,我感觉还是比买彩票中奖低,所以这种事还是不必过分放心了。

即便真被误扣了,释怀,支付宝这么大体量必定会跟客户赔钱的。

最初

最初总结一下,咱们平时应用付款码领取,其实原理就是商家端获取咱们手机 APP 付款码(「其实就是一串数字」),而后后盾调用支付宝领取接口实现扣款。

这个流程商家端后台程序必须联网在线,然而对于咱们客户端来讲能够在线,也能够离线。

如果咱们客户端在线,那就能够通过服务端向客户端发送付款码,这种形式更加平安,灵便,然而对于弱网环境下,体验就很差。

如果咱们客户端没网,那就通过客户端通过肯定算法生成付款码,服务端收到通过相干校验,确认是哪个用户,确认码有效性,并且实现扣款。这种形式,适宜客户端没有网络的状况,不过绝对不灵便,且安全性稍差。

嘿嘿,理解原理,有没有感觉还是挺有意思的~

下次排队付款钱, 如果手机没网,不要放心难堪,释怀拿出手机付钱~

参考
https://www.zhihu.com/questio…
https://garbagecollected.org/…

本文由博客群发一文多发等经营工具平台 OpenWrite 公布

正文完
 0