运行环境

微信支付运行时，依托强大的微信环境，国民级应用，安全性想说都没法说，杠杆滴；而接口服务，是一个后端服务，几乎看不到摸不着，这里我就简单的说一两句。

数据签名

之所以有数据签名，也是基于安全考虑，在异步运行时环境里，变量因素太多，保证请求到数据没有被篡改、伪造，简单粗暴的方式就是对数据签名，引申出的就有如下的签名方案：

MD5摘要(哈希)算法

这其实是个单向数据摘要方案，官方加密方案是把secret拼接到待摘要字符串末尾，进行摘要。MD5摘要的签名，目前公认不安全了（暴力强算可逆），不建议再使用了。

HMAC-SHA256摘要(哈希)算法

稍微比MD5数据签名安全一点的是HMAC-SHA256，这也是单向数据摘要方案。HMAC缩写的全称是Hash-based Message Authentication Code，摘要算法支持 sha256, sha512 等算法。

在这不得不提一下APIv2上几个不洁癖的地方，就是在返回值验签上，有些接口验签默认值MD5，有些是HMAC-SHA256，有些接口xml只返回了sign字段，有一些还没有，迭代风格迥异。

研发的同学可以按如下规律来判断，在有返回sign字段的时候，官方是采用的哪种签名方案，即：

  • 返回sign长度为32字节，平台方采用的是MD5数据摘要方案；
  • 返回的sign长度为64字节，官方采用的是HMAC-SHA256数据摘要方案；

无sign字段的几个接口，属于特定领域使用的，估计官方也不会再迭代了，先将就着用吧。

AES-ECB加解密

Advanced Encryption Standard with ECB (Electronic Codebook 电码本) mode 模式是分组密码的一种最基本的工作模式。算法及模式可以百科一下，这里就不展开了，属于对称加密，安全强度相较于 MD5/HMAC-SHA256 要高许多，不过存在共享密钥问题。

RSA-OAEP加解密

RSA加密属于非对称加密，公钥加密/私钥解密，公钥是系统间交互的，私钥是双方秘密保存的，解决了共享密钥问题，相对来说，安全级别高许多。

AES-GCM加解密

Advanced Encryption Standard with GCM (Galois/Counter Mode) 指的是该对称加密采用Counter模式，并带有GMAC消息认证码。属于对称加密，密文相较于AES-ECB解密难度要高，对应的安全等级也高一些，不过也存在共享密钥问题。

APIv2 适用业务形态

  • 收单服务
  • 资金应用
  • 营销工具
  • 通关报关

APIv3 适用的业务形态

  • 收单服务
  • 资金应用
  • 支付分
  • 智慧零售
    • 智慧商圈
    • 支付即服务
    • 支付即会员
    • 消费者服务
  • 营销工具

两个版本安全对比

业务形态 APIv2密钥 API证书 APIv3密钥
收单服务 需要 无需 需要
资金应用 需要 需要 需要
营销工具 需要 需要 需要
通关报关 需要 需要 -
支付分 - 需要 需要
智慧零售 - 需要 需要

从上图表格以及技术方案来看，APIv3的数据安全等级高了许多，然而，所有的操作，均使用一套 APIv3证书 及 APIv3密钥，这对商户的安全等级考量是非常高的了，至少要达到 安全合格 检查的3类级别，通俗的讲就是要去商户，对关键信息具有较强的安全管控，以规避因误造成的损失。白话说一下风险点就是，只要掌握了商户的 API证书，那么商户的“底裤条纹及颜色”就曝露在光天化日之下了，这是对商户的一个考验。

而APIv2，收单服务仅依赖密钥，在不暴露 API证书(或者根本没有申请)的情况下，仅存在理论上的“暴露短裤”风险，短裤和底裤比较起来，相对还好的吧。。。

所以，在当下这个时间节点，在升级APIv3这件事情上，商户需要谨慎考虑并且需要做 等保合规 评估。

安全防护方面较弱的商户，我的建议是，能不提供 API证书 的绝不提供；能用APIv2的，绝不升APIv3；实在没法儿的业务，坚决要做到API证书管控，宁可不做，也不能存资金安全隐患。

不得不用的场景

对于官方新晋的赋能产品，有很多产品功能包，均是以APIv3形式提供，比如 消费者投诉接口 ，这项服务是微信生态内，健康的一个双向保障，对以服务为导向的行业来说，有此接口能力，是一个很好的体现服务质量的通道。强烈建议商户朋友们能够尽快接入。

问题就来了，对不得不接入的功能，从实践上，有如下几个建议：

  1. 建议API证书做安全等级管控，商户/服务商平台上，对于出资金可以设置白名单的地方，均设置上安全请求IP白名单(白名单目前只有5个名额，而且还不支持IP网段形式，且用且珍惜);
  2. 建议使用独立的签名服务，把API证书圈定在有限的环境内，避免将API证书本身分发出去，特别地，对于APP对接微信支付，千万千万 不要把API证书内置了，APP本身就是分发机制，这证书要是分发出去，后果简直这太可怕了；
  3. 建议独立的签名服务要对请求签名的应用请求进行身份认证鉴权；尤其是对于关键的 出资金 业务，不仅要验证应用请求和参与签名的路径，甚至请求报文的核心字段要做验证；

远期上来看，APIv3肯定是趋势，何以“破解”API证书权限过大问题，待就等等官方的大智慧吧。

附注链接