讨论：前端”加密“是不是脱裤子放屁？
起因
问题
问题：HTTPS环境下，前端在传输密码时，是否有必要进行加密？
观点
有必要
1 、防止无意泄露和二次伤害。（打 debug 日志无意间把用户输入打到日志）
2 、隐私合规问题，参差不齐的员工可以拿到密码加用户手机号，登录任何设置此密码的网站。
无必要
1 、https + 后端加密入库足够安全。
2 、后端需要验证密码复杂度（业务场景）
3 、增加开发成本，没必要。
4 、加密后导致密码强度的下降(因为密文的信息熵下降了)
讨论
1、实际项目中，确实遇到过对接口访问的路径/入参进行打印的情况，而且是默认全局的，没有做好数据脱敏；
2、观点二属于数据管理问题，
3、确实有部分项目，甲方要求在回传password时不能使用明文
结论
数据脱敏、数据管理等问题无法通过单一手段进行加固，需要完善安全管理，更建议采取2FA等方式。
不推荐的做法
1、前端在HTTPS下实现自己的对称/非对称加密，重复实现HTTPS所做的工作
2、前端采用不安全的摘要算法进行数据处理，例如md5
常规的做法
1、前端回传明文，后端使用sha256crypt/sha512crypt/bcrypt等摘要算法保存摘要结果，结果中包含了随机添加的salt
3、每次请求时读取salt进行hash计算，进行摘要结果匹配，以判断password正确性
在有合规需求时的做法
1、前端使用“用户名+自定义字符串”作为自定义盐，添加至原有的password
2、前端使用sha-256/sha-512等足够安全的摘要算法，将hash后的结果传递给后端
3、后端拿到前端结果后，使用传统的 sha256crypt/sha512crypt/bcrypt 处理后保存
关于自定义salt
“用户名+自定义字符串”：
- 前者对于每个用户都是不同的，不同系统下可能是相同的，
- 后者对于所有用户都是相同的，但是在不同系统下必须是不同，
这样生成的盐，在每个用户的每个系统下都是不同的，增加了彩虹表攻击的难度，能在一定程度上减少用户被撞库的风险。
