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

这测评机构是不是有点呆，还得告诉他用 https 了。。
https 肯定是 ok 的，测评机构自己也认。自己写还得维护，出了问题还得负责。要是有人说 hash 一下传给后端，绝对是想当临时工

在安全部门的检查中，针对全链路 https 还要求加密的情况，基本都是 base64 应对，他们居然认可。

我们甲方是某省级联通...要求 https+非对称加密传递密码信息

不要重复发明 https 啊

说你明文传输，英国指的是你前段把用户的秘密明文发送给后端，后端无论是保存明文密码还是进行各种各样的加密、hash 都是不安全的。
密码的作用只是验证，出于最小化原则，因为服务器不需要知道用户的明文密码，所以服务器应该对用户的明文密码保持 zero knowledge 。也就是在**前端**把用户的密码 hash （加固定盐甚至不加盐也不是很大的问题）后向后端发送 hash 进行验证即可。
不要听信#11 这样的暴论，这种做法除了增加复杂度和向用户掩盖哪些内容被传输以外没有实际意义，服务器仍然有能力访问到用户的明文密码，和 https 内明文传输没有任何区别。

你根本就没明白 https 跟文本加密各自的作用。
防的人都不一样。
https 假设是用户是君子，防止其他小人篡改 记录。
文本加密是假设用户里有小人。他们可以很随意做出协议登录。爬虫等。
如果你认为公司产品没啥值得被爬，没灰黑产盯着，那 https 就足够了。

@Jirajine 你这个恰恰才是最典型误解（同时也是一个非常普遍的误解），原本的“后端不能存储明文”的方案指的是设置密码以及验证密码时前端传输明文，后端进行 hash 后保存，这样即使被脱裤后也无法直接得到明文
而按照你的说法，前端进行 hash ，后端保存这个 hash 值，那么这个 hash 值本身是不是就相当于明文了？不用纠结是不是用户输入的那个明文，在登录流程里它的角色就是明文，被脱裤以后压根就不需要关心真正的明文是什么，直接拿这个 hash 值来登录就行了

@GuuJiang 首先，存储 hash 而非明文密码防的主要不是一方登录，而是使用相同密码的用户在一个网站被脱裤，密码被攻击者用来对所有其他网站撞库，攻击者已经有了用户的明文密码，无论这些网站使用怎样的安全措施都无法避免影响。

前端 hash 而非后端是因为最小化原则，后端能得到明文密码，也可能因为日志、内鬼、漏洞等原因泄漏，所以后端不得到明文密码这种不需要得到的信息才能最大化减少攻击面。

至于防止脱裤后一方登录，后端可以再进行 hash ，和前端 hash 互不干扰。并且这种情况一方网站也更容易处理，更新安全策略、通知用户改密码等。

最后你说的关于反爬、防用户，则是完全不相干的领域。况且你对登录过程加密对反爬也没有什么意义，爬虫可以用浏览器模拟登录然后取得 cookie 。

如果加密后再通过 HTTPS 传输，那就要加一层加密解密，好处是即使被抓包也不会泄露。如果做了 SSL pinning ，那样就不会被抓包，也就不需要加一层加密解密。但是 SSL pinning 还是挺麻烦的，如果是校验的是证书，你换了证书客户端就挂了，必须升级。如果是限制公钥，那可以换证书。

用 https 同样的方式加密一下最安全，不要信任用户浏览器的根证书，自已维护。密码前端 hash 后传给后端记得加盐，后端 input 没有明文密码，防撞库

直接 https 明文，参考 github 等网站就行。
前端 hash 没必要，等于是 hash 了之后等那串 hex 是用户真正的密码，MIMA 该拦截拦截，该修改修改，该重放重放。
RSA 更没必要，既然谁都能拿到公钥，那么加密就跟 hash 是一样的了，谁都可以加密，MIMA 该拦截拦截，该修改修改，该重放重放。
所以传输安全也就建立在 TLS 之上，#1 的 SSL Pinning 是唯一的保障。所以想要绝对安全你可以用自签证书，不过自签证书现在用在了微信支付、支付宝支付之类的资金安全上，对于登录安全大可不必，加个 2FA 比搞这个好的多

还有一个加 nonce 的方法忘了说了，hash(nonce + hash(password)) 也算是比较安全的方式，即使没有了 SSL Pinning ，也能保证安全，不过好像用的不太多？

@renfei 抱歉 没审题，我们登录接口不加密 走 https ，我觉得也不用加密。就两种方式，账号密码验证，手机验证码验证。设置客户端登录错误次数、接口限流。感觉这样就够了吧