文章总结： 文章探讨HTTPS下仍需加密登录数据的原因，核心在于满足等保2.0及金融行业安全合规要求。技术层面上，HTTPS存在证书信任风险，应用层加密可作为纵深防御手段，增加中间人攻击难度并阻挡初级攻击者，虽无法完全防御高级逆向工程。建议采用非对称与对称加密结合（如RSA+AES或SM2+SM4）并增加签名校验，以平衡性能与安全性。 综合评分： 80 文章分类： 安全建设,WEB安全,解决方案,技术标准

增加攻击难度

单纯的 HTTPS，在链路上或许能阻拦掉中间人。但如果有些路由器或者防火墙配置了证书（非法合法都有可能），浏览器给你证书不可信提示，用户还坚持访问的话，那就没招。登录接口加密，在没有密钥的情况下，能防止中间人获取相关信息。

其次，加解密可以增加难度，把一些脚本小子拒之门外。

对稍微有经验的渗透测试人员和爬虫人员，没什么用。

• • 浏览器断点调试
• • 大模型定位分析
• • JS 补环境
• • js hook 通用脚本
• • 定制化浏览器
• • 内存加密方式碰撞
• • ……

有很多方法规避掉这些，往深处走，就是一系列防御工程了，JS 混淆、jsvmp、奇葩验证码、一次性 token、浏览器特征……

改进做法

文章中作为虽然针对安全合规做了一些改进，不过选择的 RSA，而不是国密中的 SM2，那这个项目的等保等级应该不算很严格，以及有大概率不是金融类项目。

如文中而言，单纯的 RSA 公钥加密，运算很慢，很消耗时间，一般采取的做法是非对称和对称加密相结合。

客户端： 非对称加密以公钥加密对称加密的密钥，对称加密加密具体的数据。

服务端： 非对称加密解密拿出对称加密的密钥，然后以对称加密解密具体的数据。

对应的就是：

• • RSA + AES
• • SM2 + SM4

再上一个档次，还会加上签名校验和一次性 token

• • RSA + AES + MD5/sha
• • SM2 + SM4 + SM3

其中对称加密的密钥，还可能每次都随机（其实也没什么用就是了）。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：进击的HACK 进击的HACK 进击的HACK《为啥 HTTPS 下还要加密登录数据？》