运行环境
微信支付运行时,依托强大的微信环境,国民级应用,安全性想说都没法说,杠杆滴;而接口服务,是一个后端服务,几乎看不到摸不着,这里我就简单的说一两句。
数据签名
之所以有数据签名,也是基于安全考虑,在异步运行时环境里,变量因素太多,保证请求到数据没有被篡改、伪造,简单粗暴的方式就是对数据签名,引申出的就有如下的签名方案:
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 要高许多,不过存在共享密钥
问题。
AES-GCM加解密
Advanced Encryption Standard with GCM (Galois/Counter Mode) 指的是该对称加密采用Counter模式,并带有GMAC消息认证码。属于对称加密,密文相较于AES-ECB解密难度要高,对应的安全等级也高一些,不过也存在共享密钥
问题。
RSA-OAEP加解密
RSA加密属于非对称加密,公钥加密/私钥解密,公钥是系统间交互的,私钥是双方秘密保存的,解决了共享密钥
问题,相对来说,安全级别高许多。
APIv2 适用业务形态
- 收单服务
- 资金应用
- 营销工具
- 通关报关
APIv3 适用的业务形态
- 收单服务
- 资金应用
- 支付分
- 智慧零售
- 智慧商圈
- 支付即服务
- 支付即会员
- 消费者服务
- 营销工具
两个版本安全对比
业务形态 | APIv2密钥 | API证书 | APIv3密钥 |
---|---|---|---|
收单服务 | 需要 | 无需 | 需要 |
资金应用 | 需要 | 需要 | 需要 |
营销工具 | 需要 | 需要 | 需要 |
通关报关 | 需要 | 需要 | - |
支付分 | - | 需要 | 需要 |
智慧零售 | - | 需要 | 需要 |
从上图表格以及技术方案来看,APIv3的数据安全等级高了许多,然而,所有的操作,均使用一套 APIv3证书
及 APIv3密钥
,这对商户的安全等级考量是非常高的了,至少要达到 安全合格
检查的3类级别,通俗的讲就是要去商户,对关键信息具有较强的安全管控,以规避因误造成的损失。白话说一下风险点就是,只要掌握了商户的 API证书
,那么商户的“底裤条纹及颜色”就曝露在光天化日之下了,这是对商户的一个考验。
而APIv2,收单服务仅依赖密钥,在不暴露 API证书
(或者根本没有申请)的情况下,仅存在理论上的“暴露短裤”风险,短裤和底裤比较起来,相对还好的吧。。。
所以,在当下这个时间节点,在升级APIv3这件事情上,商户需要谨慎考虑并且需要做 等保合规 评估。
安全防护方面较弱的商户,我的建议是,能不提供 API证书
的绝不提供;能用APIv2的,绝不升APIv3;实在没法儿的业务,坚决要做到API证书
管控,宁可不做,也不能存资金安全隐患。
不得不用的场景
对于官方新晋的赋能产品,有很多产品功能包,均是以APIv3
形式提供,比如 消费者投诉接口,这项服务是微信生态内,健康交易的一个双向保障,对以服务为导向的行业来说,有此接口能力,是一个很好的体现服务质量的通道。强烈建议商户朋友们能够尽快接入。
若要接入,这下问题就来了,APIv3接口,全部需要API证书,而API证书又什么都能干。这么大的权限,对不得不接入的功能,应该如何接入呢?
从实践上,有如下几个建议:
- 建议
API证书
做安全等级管控,商户/服务商平台上,对于出资金可以设置白名单的地方,均设置上安全请求IP白名单(白名单目前只有5个名额,而且还不支持IP网段形式,且用且珍惜); - 建议使用独立的
签名服务
,把API证书
圈定在有限的环境内,避免将API证书
本身分发出去,特别地,对于APP对接微信支付,千万千万 不要把API证书内置了,APP本身就是分发机制,这证书要是分发出去,后果简直这太可怕了; - 建议独立的
签名服务
要对请求签名的应用请求
进行身份认证鉴权;尤其是对于关键的 出资金 业务,不仅要验证应用请求
和参与签名的路径,甚至请求报文的核心字段要做验证;
远期上来看,APIv3肯定是趋势,何以“破解”API证书权限过大问题,待就等等官方的大智慧吧。
点赞再看!
V3签名不会写怎么办?有PHP手把手教学吗?
如你所说的,还是谨慎一点暂不升级好!
看了2遍文档还是不敢升级,APIV2希望能够一直用下去
API能接成功就烧高香了,还要求这么多
指出1个明显的错误,希望不要误导大家:
文中说AES-ECB安全强度相较于 MD5/HMAC-SHA256 要高许多是不恰当的,理由有三:
1)AES是对称加密算法主要解决机密性问题,MD5/SHA5是擦凑算法主要解决完整性和认证的问题,应用场景不同两者没有可比性
2)在签名验签的场景,业界推荐使用HMAC-SHA256
3)AES的ECB模式已是业界公认的不安全模式,推荐使用GCM模式和CBC模式