登录接口是应该自定义加密还是依靠 HTTPS 就行？

[renfei]

各位大佬，每次安全测评的时候，总说我登录明文传输，自己写一套加密逻辑前后端都不太愿意用，因为还涉及到非对称加密、交换对称秘钥，大家都不想这么麻烦，每次我都应答用 HTTPS 来保护明文传输的问题

那么，按正常场景来说，是应该自己弄一套加密呢，还是套 HTTPS 万事大吉呢？

[tool2d]

你要确保客户端用了 SSL Pinning 技术，那流量就是相对安全的，不加问题也不大。

如果黑客能破解你的 SSL Pinning ，那他大概率也能破解你的非对称加密。

[ysc3839]

个人建议客户端提交前用 md5 或 sha1 等弱 hash 函数取密码的 hash 值再提交，后端用 argon2 等强 hash 进行验证。

一定要弄一套加密的话，参考 B 站登录接口的方案(现在如何不知道，以前是这样的)，先请求一个接口获取 RSA 公钥，登录请求的 post 数据全都用这个公钥加密，后端用私钥解密后再处理。

[javalaw2010]

我是赞同只依靠 https 的，但如果有同事反对，我会懒得解释（实际上我可能会简单解释一下以表示我不是个不顾安全的憨批），然后上一套简单的对称加密完事儿。

[CloudMx]

这个是两个维度的：
1 、HTTPS 强制要求是应对中间人的
2 、业务敏感字段数据要求有一些是规范政策相关的，技术上的话比如：一些留存 web 日志，相对明文是可以提升攻击者成本的。

[mozhizhu]

我干掉了账号密码，主导让微信扫码登录，然后被埋怨了；但是依旧推下去了，因为他们的 123456 太粗暴了

[tianmalj0613]

@ysc3839 #2 现在百度好像也是这样的

[Worldispow]

自定义加密和 https 加密是两个事吧，https 是公共链路加密。
自定义加密是内部网络加密，比如前后端交互、公司内部不同系统间交互等等。

[renfei]

@Worldispow #7
在我看来似乎是一个事儿

https 是把整个请求体加密了，多个 CA 中间认证

自定义加密，我也是模仿 https 先通过非对称加密交换一个秘钥，后续通过秘钥对称加密，只不过加密的是我指定的字段而不是整个请求体，并且没有 CA 认证

[MigrantWorkers]

目前我们的方案 jwt+sig ，用了几年了 没啥问题。也可能是体量小

[cozof]

用非对称，把公钥给前端，前端加完密数据发回。不行？

[lovelylain]

@ysc3839 先 hash 再提交意义不大，不加可过期的盐，hash 值相当于密码，加动态盐，后台要存储密码明文才能验密，还是 RSA 公钥加密吧，安全不复杂

[yzkcy]

针对明文传输整改的话，HTTPS 和前端加密都要上。

[yinmin]

@renfei 和同事沟通这类问题，如果说哪种技术好，是没法说服对方的。

最简单的方式是：参考大厂的 api 加密模式，例如你对标微信接口的加密方式，然后和领导、同事建议我们采用微信接口一样的加密模式，如果对方不同意，你让对方说他们的方案有啥好？为什么微信（再举例类似几个大厂接口）不采用？你们的技术方案比微信团队强？

[ysc3839]

@lovelylain 先 hash 再提交是为了尽可能避免用户隐私泄漏，印象中等保要求不能提交原始密码

[kaneg]

https 完全可以啊，安全方面最好不要自己造轮子，要用业界标准协议，否则可能适得其反。

[chenjia404]

我之前做过一个方案：
哈希(用户名+密码+网站名)发送给服务器，服务器拿到提交的哈希和用户名，再哈希(用户名+密码+网站名+盐)，把最后一步的哈希存在一张哈希表里面，下次用户登录的时候，只需要验证哈希表中是否有元素即可。

[leonshaw]

一般明文就可，但是后端看到明文，对习惯用同一个密码的用户会有问题。可以考虑用 KDF 处理一下

[renfei]

@MigrantWorkers #9 获取 JWT 的时候呢，是不需要传输用户名、密码，我想问的是传输密码时的加密，还没到拥有 JWT 的阶段呢

[renfei]

@cozof #10 非对称加密，有要求，你不能加密比秘钥更长的内容，如果用户的密码很长，那就需要一个比密码更长的秘钥去加密，超大的秘钥存储和计算都会有压力，所以我是先用非对称去交换一个对称秘钥，后续使用对称加密

[zsj1029]

Aes 两个变量 iv 和 key ，iv 前后端约定固定住，
Key 的值登录前向后端请求，每次加密都会变，用不用 HTTPS 都可以防止拦截破解，当然本质没有解决前端不了解密的问题，只是相对增加了破解难度