前端加解密实践：从「别明文传密码」开始

wuwenzen@outlook.com (wuwj) — Thu, 26 May 2022 00:00:00 +0000

每次提到前端加密，评论区都会有人说：

有 HTTPS 了，还加什么密？
前端代码都是能看到的，没意义。

理论上没错，但在金融/政企等场景里，有些需求不是技术可不可行，而是「要不要多一层安全防护 + 满足合规要求」。

这篇文章从实战出发，聊聊：

1. HTTPS 已经有了，为啥还要前端加密？

先说前提：HTTPS 必须有，这是基础。
在这个基础上，某些场景仍然会要求：

防止明文敏感信息出现在抓包里
- 即便是 HTTPS，有些合规要求会明确写「不得以明文形式传输密码等敏感信息」；
- 抓包截图里看到一串密文，和直接看到手机号/密码，感受是不一样的。
降低中间层日志泄露风险
- 有时候请求会经过网关、代理、日志系统；
- 如果这些地方有不规范的日志记录，敏感字段加密可以降低损害。
和现有后端架构/第三方接口对齐
- 有些历史系统已经约定「密码字段用某种算法加密再传」；
- 前端需要遵守既有协议。

前端加密不是代替 HTTPS，而是多一层「应用层加密」。

简单回顾一下：

特性：

所以常用组合是：

前端生成一个随机对称密钥 → 用后端公钥加密这个密钥 → 发给后端 → 后端用私钥解出密钥 → 后续用这个对称密钥加解密数据。

前端常见实现方式：

以「登录密码不可明文传输」为例，设计一个简化流程：