充分利用云计算的七种方法

当客户端将动态码上传给服务端，服务端查询数据库获取到用户对应的密钥，然后使用同样的算法进行处理生成一个动态码，最后比较客户端上传动态码与服务端生成是否一致。

付款码离线方案

上面我们了解了动态口令的实现方案，付款码生成原理其实也大致如此。

不过付款码离线方案采用动态密钥的方式(「全局唯一」)，定时请求服务端更换密钥，以此保证更高的安全性。

另外在一次性动态口令方案，需要双方基于同样的秘钥，所以服务端需要明确知道这「背后正确用户」。以上面的登录场景为例，登录过程输入用户名,服务端就可以根据这个在数据库中查询相应的密钥。

但是在付款码的支付场景中，支付过程仅仅传递一个付款码，就可以向相应的用户扣款。不用想，这个付款码这串数字一定包含相应的用户信息。

所以付款码的相应的算法相比动态码会更加复杂，这样才可以有效保证安全性。

看到这里，不知道你们是否急切想了解这套算法那?

哈哈，开个玩笑，这种算法岂能是我们能掌握的。

支付宝核心算法咱不知道，但是我们可以从其他人公开设计方案了解一个皮毛。

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

 

里时间就充当一个动态变参，这样可以源源不断产生动态码。

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

这样对于用户输入来讲，可以有充足时间准备输入这个动态码，另外一点客户端与服务端可能存在时间偏差，30 秒的间隔可以很大概率的屏蔽这种差异。

画外音：这个有效时间其实很考量，如果比较长，安全性就差。

如果比较短，用户体验就很差，不容易输入准备。

经过 「HMAC-SHA1」 签名函数以后，我们得到一个长度为 40 的字符串，我们还需要将其转化为 6 位数字，方便用户输入。处理的伪码如下：
 

过上面两张图，我们整体了解付款码交互流程。

付款码的技术方案其实可以分为客户端在线与离线的两种情况，下面我们来看下两种方案具体实现方式。

在线码方案

客户端在线码的方案，这个应该比较容易想到，只要支付宝/微信在登录的情况下，点击付款按钮，客户端调用后台系统的申请付款码接口。

后台系统受到请求之后，生成一个付款码，然后在数据库保存付款码与用户的关系，并且返回给客户端。

只要客户端在有效期内展示该付款码，就可以完成支付，否则该二维码就将会过期。

使用这种方案，相对来说比较安全，因为每次都是服务端生成码，服务端可以控制幂等，没有客户端伪造的风险的。

另外即使需要对付款码规则调整，比如付款码位数增加一位，我们只要调整服务端代码即可，客户端都无需升级。

「不过这种方案缺点也比较明显，客户端必须实时在线联网，没有网络则无法获取付款码。」

另外，现在有一些智能设备也开始支持支付宝支付，这些设备中很大一部分是没有联网的功能(比如小米手环四)，那这种情况是没办法使用在线码方案

（编辑：平顶山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!