对称加密算法SM4，非对称加密算法SM2，哈希算法SM3，签名算法SM2。
GMSignatureSpi#sha256WithSM2、GMSignatureSpi#sm3WithSM2
所有接入API服务网关的接入方密钥对均按如下要求建立。
a) 根据实际业务场景，接入方可分为发送方或接收方。
b) API网关应用线上（Web界面）或者线下分发秘钥对，确保秘钥的生成规律不能为 其他方所获知。
c) 接入方可根据自身需求，定期更新接入方密钥对。
d) 秘钥应采用对称国密算法 。
后续双方的交互使用「AES秘钥」进行加解密，秘钥交换流程完成。
而不同场景的API网关对API调用方的安全要求等级也会不同，通常对外网的安全要求会比内网要高。 最终可以形成如下这张API资产访问清单。
服务对象 | 使用环境 | 网关场景 | 安全要求 |
合作机构 | 外网 | 2B-API | 高 |
外部用户 | 外网 | 2C-API | 高 |
内部用户 | 外网/内网 | 2G-API | 中 |
内部应用 | 内网 | 2S-API | 中 |
API安全治理的实践思路
用过API网关的同学都知道，它的核心能力主要是流量路由转发及分流。所以，缺省情况下，它并不会启用安全控制 能力，因此，你需要根据实际使用场景，选择开启不同的安全控制能力。
API网关一般都支持如下安全控制能力
控制能力 | 防范场景 |
请求限流 | 防止攻击者频繁请求API，导致资源耗尽无法正常响应 |
签名验签 | 防止攻击者伪造身份请求API，或篡改请求报文数据 |
加密解密 | 防止攻击者通过非法手段拦截报文后，获取敏感数据 |
防重请求 | 防止攻击者通过非法手段获取报文后，重复请求API |
用户鉴权 | 防止攻击者在匿名情况下请求API，获取数据或攻击程序 |
访问约束 | 防止攻击者利用漏洞，采用不安全的方法或跨域请求API |
前文有提到过， 不同场景的API网关对API调用方的安全要求也会不同。 所以，并不是说所有API网关都要实现或开启以上控制能力，根据实践使用经验，参考如下
控制能力 | 2B网关 | 2C网关 | 2G网关 | 2S网关 |
请求限流 | 必须 | 必须 | 可选 | 可选 |
签名验签 | 必须 | *无需 | *无需 | 可选 |
加密解密 | 必须 | *可选 | *可选 | 可选 |
防重请求 | 必须 | *可选 | *可选 | 可选 |
用户鉴权 | 必须 | 必须 | 必须 | 可选 |
访问约束 | 必须 | 必须 | 必须 | 必须 |
注：*代表在移动端环境下为必须。
可以发现，面向公网的API安全控制要求要远远高于内网。所以说， 在API安全治理的优先级上，建议采取先外后内的实践策略** ，毕竟面向公网的API处在一个完全开放的环境下，它更容易受到致命性的攻击。
以下内容从这几种常见的安全类型。
报文签名用来验证通讯报文的完整性和防篡改校验(敏感信息（比如身份信息、银行信息等）不在此处处理）。 采用App Secret Key + HMAC方式。
这种方式的主要特征有 1）引入App Secret Key来标识API调用者身份，2）引入HMAC防止消息被篡改。
HMAC：为了防止消息在传递过程中被篡改，引入MAC（ Message Authentication Code），这是一种给消息签名的技术。在实现中，首先对消息进行MAC，得到一个摘要字串。接收方得到消息后，进行同样的计算，然后比较这两个MAC字符串，如果一致，则表明没有被修改过。而HMAC（ Hash-based Authenticsation Code），指的是，利用Hash技术完成这一过程，比如使用SHA-256算法。
App Secret Key：抽象出一个应用的概念，用来标识调用者的身份，每一个应用可以生成一个或多个Secret Id/Key。API所有者只给有权限的API访问者颁发相应的Secret Id/Key。API访问者请求时带上应用标识，服务端就可以识别调用者的信息，并进行更细粒度的权限管理。
HMAC+App Secret Key：API访问者发送请求时，可以对应用标识使用HMAC计算出摘要字串，在HTTP头的 sign字段中放入相关信息发送到服务端。服务端会查询相关应用的信息，并验证签名，验证通过，返回200，否则返回401。
网关需要验证API调用方上送的签名是否正确；API调用方收到应答，也需要验证签名是否正确，如果API调用方未正确验证签名，存在潜在的风险，API调用方自行承担因此而产生的所有损失。
接入系统调用该类函数，对签名串使用SM3算法做摘要，将摘要转换为十六进制字符串后，再使用各自私钥对摘要做签名，并对结果进行Base64编码。最后，将生成的签名赋值给signature，填入到HTTP 报文头。
公共请求参数（HTTP头信息）
app_key | String | 是 | 应用的app_key |
signature | String | 是 | 签名 |
X-Ca-Timestamp | String | 是 | 时间戳，格式为yyyy-MM-dd HH:mm:ss，例如：2011-06-16 13:23:30。时间戳，格式为yyyy-MM-dd HH:mm:ss，例如：2011-06-16 13:23:30。API服务端允许客户端请求时间误差为10分钟 |
对于报文的验签处理机制如下：
首先，将报文体数据SM3算法做摘要，将摘要转换为十六进制字符串后，再使用对方公钥对摘要和报文中的签名信息做签名验证操作。
在API网关的签名中，提供X-Ca-Timestamp、X-Ca-Nonce两个可选HEADER，客户端调用API时一起使用这两个参数，可以达到防止重放攻击的目的。
原理
敏感信息（比如身份信息、银行信息等）采用一次一密的方案，敏感信息加密密钥仅在使用时生成，且每个密钥仅使用一次，通过网关给出的公钥加密后Base64出现在报文中。。
在应用系统接入API网关模式下，敏感信息传输时加密与解密流程概要描述如下。
a) 发送方通过应用系统方式向API网关传输敏感信息的场景：
1) 发送方生成敏感信息密钥；
2) 发送方使用敏感信息密钥 对敏感信息进行加密；
3) 发送方使用API网关的公钥 ，对敏感信息密钥进行加密；
4) 发送方使用自身的私钥，进行数字签名；
5) 发送方将加密后的敏感信息密钥密文、使用对称秘钥加密后的敏感信息密文以及发送方数字签名发送给API网关；
6) API网关使用发送方的公钥，进行验签；
8) API网关使用自身的私钥，对加密后的敏感信息密钥密钥进行解密；
9)API网关使用敏感信息密钥明文，对敏感信息解密得到明文。
TLS 能保证的只是传输过程中第三方抓包看到的是密文，但防不了在客户端和服务端截取数据的黑客，要在服务端截取数据比较难，但在客户端截取还是比较容易的。最简单的，你在浏览器访问知乎、京东等知名网站并用抓包工具抓取请求，就会发现，虽然是HTTPS请求，但看到的数据并非密文，而是明文的。对HTTPS的攻击手段也不少，比如降级攻击、中间人攻击等。
所以，只用HTTPS做防护是不够的，我们还需要对密码进行非对称加密。非对称加密算法主要有:RSA ECC
要怎么做呢?慢哈希+Slat(盐)。Slat的存在主要是为了让破解密码的成本增加。建议每个用户的Salt值不同(最好对不同用户的密码随机生成不同的salt，salt库和密码库分离开)，这样就没办法用彩虹表进行批量破解。再加上慢哈，暴力破解的成本也呈指数级增加，何为慢哈希?所谓慢哈希，其实就是指执行这个哈希函数非常慢，这样暴力破解需要枚举遍历所有可能结果时，就需要花上非常非常长的时间。慢哈希算法主要有: Argon2、Scrypt、Bcrypt、PBKDF2
TLS是基础，密码再进行单独加密，加密算法要用非对称加密;
如果用户登录时密码错误，那错误提示语不要直接提示“密码错误”，只需要给出一个大概的提示，比如“用户名或密码错误”;
密码错误次数连续超过N次，比如6次，则将用户锁定一段时间:
数据库用慢哈希+Salt的方案进行存储，不同用户用不同Salt值。
增加多重校验，比如登录设备检测、指纹识别、人脸识别、手机验证码等
答案1：关于中间人攻击，就需要引入第三方来解决信任问题，https 的 ssl 证书就可以，比如我请求www.renfei.net，你说你（中间人）是www.renfei.net，那你就出具 ssl 证书证明你是，如果证书对不上，那我就不信任你，不会继续交换秘钥了。申请 ssl 证书的时候会审核域名所有权，不是随便就能申请的，所以假冒的服务器端（中间人）是无法出具证书证明自己是www.renfei.net的。
我觉得还是有必要的，首先明确一点https也是可以被抓包解密的，前提是拿到设备。分享一次我的事迹，我曾经抓包支付宝APP，想改数据包里的内容，虽然是https，依然能抓取并拿到里面的内容，但是支付宝在传输的时候还是加密了，也就是说 https 里面还是加密的内容，这就造成我无法修改数据包，除非我反编译支付宝的APP，拿到加密算法，再伪造APP请求。
您的逻辑上是没问题的，我是根据行业习惯来的，不信任客户端产生的东西，或者说接口传进来的我都不信任，如果由客户端生成AES的话，后端还需要判断这个秘钥的强度，增加了后端的工作量，不如直接不信任客户端，都由后端决定用什么密码，什么时候下发新的密码
https://www.renfei.net/posts/1003346
https://cloud.tencent.com/developer/article/1925022
| 留言与评论（共有 0 条评论） “” |
