前端 web 密码加密是否有意义

[a7217107]

个人认为意义不大，再被劫持的情况下，明文和 md5 是没有区别的吧。大佬轻喷

[leoleoasd]

1. 传 md5 有用 可以防止被爆库
2. 说无法加盐的 后端可以再次加盐后用后端的方式加密
3. 还有一个好处就是用户调用 api 的时候 可以可以直接是密码的 md5

[lasuar]

传 MD5，即使监听请求也是看到 md5 后的秘钥，无法解密 /模拟，不加密的话在请求中你的密码就是以明文在网络中传输。

[lasuar]

最主要是防楼上的已经说过的 log 以及脱裤。

[lincanbin]

@Rubicker666 很多大厂都做过这种事，这两家公开说过自己发生过这种事。
因为量级大的情况下，bug 会更容易被发现，但是一般收到用户反馈后又很难复现。
有的人为了方便就会不对数据脱敏直接写日志，方便重现现场。

[IvanLi127]

个人认为，前端密码哈希是保护用户隐私的一种方式，仅此而已。前端哈希对自己系统没啥意义，对用户可能有点意义，至少不可能把用户原始密码公之于众。不过，自己搞加密是真的没啥用，瞧不起 HTTPS 这些？

[geelaw]

@hanru #55 哈哈哈哈哈哈 请论证一下这个例子怎么说明 **中文** 术语不严谨。

[zzzzzzZ]

@agagega #55
你发的这个 answer 已经把你的脸打肿了，还再说啥？
##任何场合下都不应该传输明文密码，无论它是什么密码。

请告诉我后端在什么场合下需要得到明文密码？得到明文密码有什么用？用来 regex ？非明文的就不能 regex 了？
只有在你这样的垃圾程序员懒得写代码解密直接一撸到底明文放到数据库顺便打个 log 的情况下后端才需要明文密码，其他任何场合后端都不需要明文密码

然后上面就有菜鸡又提了，别人可以拆包呀，找 js 的加密 key 照样可以解密了呢。
公私钥了解一下？

然后上面又有菜鸡又提了，别人做中间人，做重放，照样可以拿到**md5**，重现请求照样可以操作呢，反正黑客攻击能做到，关我前端什么事呢。
脱库了解一下？撞库了解一下？攻击成本了解一下？

真以为加密就是后端的事情咯
得到用户第一手的隐私信息不脱敏就直接扔
我不是性别歧视，我只是想说：如果女人的 B 有密码，那你这样的肯定是 123456

[zzzzzzZ]

@geelaw #65
他想说的就是**web 前端**应不应该包含 app，或者说移动设备的浏览器
毕竟在很多菜鸡眼里这些是一个东西

[hanru]

@geelaw 我是针对前面提到的知乎上把端到端等同于前端发的评论，我应该说的是知乎上对于中文术语的使用太不严谨了。

[zzzzzzZ]

@agagega #55
看错了，既然是完全公正客观地从学术角度谈 js 加密。那我不应该是这样的讨论语气，在这里道歉。

顺便，第一条浏览器 SSL 的事情，猎豹浏览器窃取用户信息，UC 浏览器 DNS 污染这些事情可以了解一下。

被脱库的事件，泄露 500 万密文和泄露 500 万明文的差别很大，前者顶多击中 500 万，后者可能会击中三四千万账号。不然大家何必用 1password

[kingcc]

首先，劫持了做不做 hash 都一样吧……

第二，做 hash 应该是为了安全等级吧。一般注重用户信息保护的都不会存用户的明文密码的

[cyrbuzz]

歪个楼，
除了劫持方面，前端进行加密的话还能起到防止数据轻易得到的作用吧。

比如要抓取一个 APP 里必须登陆后才会返回的数据，抓包得到的请求数据是这样的：
```
username=123456&password=654321
```
这个抓取成本不用说...，随随便便都能模拟出登陆然后抓取。

但如果抓到的是
```
f11d8b13da6e83cf588b6d6dd0c13a5f
```

在不了解具体的加密算法之前无论如何都不太可能模拟出登陆这个步骤。

[pinews]

@lhx2008 一样的密码，加密之后不一样，也就是说，你获得的加密密码只能使用一次

[wolfie]

针对会劫持，但懒得看加密过程😂😂

[reself]

@cyrbuzz http 这种明文传输的，黑客想干啥都行，密码 hazh 了也没用，直接重放攻击，管他内容是啥，劫持下来，原样发过去照样登录。要在 http 下防止这些，这几乎等于自己写了一套 ssl/tls，没准还考虑不周全有漏洞，所以还不如用 https 呢。

[reself]

@zzzzzzZ 睿智如你，已 block

[reself]

@zzzzzzZ 技术讨论都这么戾气，全世界的人都欠你？

[chinvo]

你 JS/wasm 再怎么加密，中间人都只需要重发数据包而已，真要保安全，还是 HTTPS + cert pinning

密码学最忌讳闭门造车和自己造轮子。一切需要靠算法保密来维持“安全性”的加密方式都是不可靠的。在前端实现对称加密连密钥都是随时会泄露的，而实现非对称加密根本上和 HTTPS 是一样的（而且你的实现还会因为自己造轮子得不到广泛的审计从而不能快速发现并修补可能的弱点

[eslizn]

说记录日志会泄漏的，没考虑过前端加密和没加密有啥区别吗？而且一般请求日志是不写 body 内容的

[reself]

@cyrbuzz 抱歉打错了，hazh->hash
先说结论，客户端散列是有意义的，但不在于防属于信道安全的劫持问题，而是防端点安全问题。针对楼主的分场景讨论一下。
不可信传输信道下（例如 http ），就密码散列而言，没啥卵用，毫无安全性，中间人可以直接篡改密码字段，改成由他构造的密码。当然如果前端用 rsa 加密，那光有加密还不行，还要做签名防篡改。用户名和密码的加密了也不够，用户的敏感操作（比如付款）也要加密，内容一多就有性能问题，要引入更快的对称加密和密钥协商。这基本上等于手撸一套 ssl，成本太高，而且非常容易出 bug。
可信传输信道下（例如 https，在这里不讨论 https 本身的安全问题，如果讨论的话就成了拜占庭问题了），这么做也颇有意义。解决了传输信道的安全问题就万事大吉了吗？还有端点的安全问题。客户端和服务端总有一个加密和解密的过程：客户端加密之前的步骤得小心翼翼，上钩子防键盘窃听，内存保护，各层的日志得仔细审核防止记录密码，还有就是楼主质疑的这点，服务端不完善的话（就算确认了对端的身份，也要假设对端存在泄露风险），要对密码进行散列，而且直接散列都不行，要加盐散列，防止用户密码泄露后被字典攻击和在别的网站密码重放。服务端解密后的过程也是，拿到密码也要再进行一次散列（这里就是包含密钥的加盐散列了），日志层要仔细审核防止记录密码，还要保证散列密钥、私钥的安全。随着计算性能的提高，加密和散列算法或者短密钥也会暴露出问题，如何及时替换老旧算法或者老旧密钥也是个问题。
扯远了，总之客户端做密码散列也是有意义的，意义不在于劫持问题，而是端点的安全问题，区分传输信道的安全和端点安就很好理解了。