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

[a7217107]

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

[sobigfish]

@lhx2008 #26 您说的在理，日志不脱敏加几次密都是无用的

[explore365]

@zzzzzzZ 已经讲的很全了，怎奈还有很多没有安全常识的人。。。

了解一下撞库，了解一下社工。。。

任何一个小的爆破点，都能被做网安人无限放大来用。。。

还是要慎重一些好。。。

最后再说一句，前端做个 hash 还是非常非常非常有必要的。

[dongyx]

服务器每次发一个随机盐过来，前端先把密码哈希，然后把哈希值加盐再哈希发回去，服务器拿到二次加盐哈希后，把数据库里的密码哈希用这个盐做二次哈希再比对嘛。 监听到二次带盐哈希也没用，下次盐就变了。

[zzzzzzZ]

@reself
是的，回复完就发现我在这件事情上戾气太重了，谢谢你的 block
其实这么简单的低级错误我何必这么生气呢，佛系佛系

[chinvo]

@explore365 #77 前端 hash 和直接发明文，对于后端和数据的安全性上来说是没有任何差别的

[agagega]

@zzzzzzZ 后端存储的时候把密码再加密当然是有意义的。我的意思是，如果说前端实现的各种加密是后面的 0 的话，完整的 HTTPS 就像是开头的 1。在我第一次看到知乎那个问题的时候，一帮人在争论没有这个 1 的前提下怎么自己造轮子比较重要，有点不知道该说什么，所以说话也绝对了点。80 楼说得很好了。

每个应用都有自己独特的要求，比如像 LastPass 这样的，就算有了 SSL，直接发明文密码也不合适。但是对大多数网站而言，恐怕先把传输过程中的安全做好比较要紧。顺便，发 hash 的话怎么做 regex ？我很好奇。

另外，我可从来没有用过 123456 这种东西做过密码：）

[agagega]

Dropbox 的密码保护实践是：先用 SHA-256 散列密码让长度一致，然后 bcrypt，再用 AES 加密。这应该是比较靠谱的实践，不过是否一定要在前端完成呢？

另外，国外一部分网站要考虑没有 JavaScript 运行环境或者没有启用的用户，这种情况下就算要给前端做也没法做了。

[Mohanson]

唯一的正确做法是用“签名”，而不是用 n 个复杂的你所谓加密 /哈希算法。

r = a(b(c(password)))

无论 a, b, c 函数多复杂，你发给服务端的永远是 r. 因此最后的 r 实际上就是明文密码。

[ihciah]

有的系统是后端提供一个随机盐给网页，前端 hash(pwd)后再加盐 hash，传给后端。

[zzzzzzZ]

@agagega
* 用散列当然做不了 decrypt，但是前端 encrypt 当然是可以后端 decrypt，我从来没有讨论过散列的解密，并且 md5 都是带引号声明过。
* 其实本帖很多人一边坚持推崇 HTTPS 的 SSL 是多么安全，一边又用中间人做开脱才是我真正愤怒的原因，明摆着的双标。
* 大家可以不做加密，让用户的隐私赤条条的在互联网上到处跑，不过是企业信息安全的一个小漏洞外带一点点用户隐私相关道德层面的不负责而已。
* 但是一边担保 HTTPS 的安全，一边又用中间人等方式加密与否都能登录做借口。后者的存在才是前端需要加密的真正原因。
* 另外，由于很多不可抗因素的存在，很多 HTTPS 通讯其实从用户到服务器的过程中并不是完全的 HTTPS，中间可能会由于 DNS 等存在进行非 HTTPS 的数据传输。这等同于未被启用的中间人攻击，或者说其实有启用监控但未被滥用的中间人。
* 推崇 HTTPS 而不加密的那些用户数据，正在这些监控下裸奔

[legiorange]

我求你们别用 MD5 了行吗？
HTTPS 在中间人的情况下，采用一样的证书就看得见明文密码，在此声明，所有的证书都是可以伪造的。
传统的密码输入，应该在不久后被摒弃，1 是注册量很多，要记得密码很多，2 是没有 2FA 验证安全。
我们应该推崇的是更换密码验证的方式。

[ruandao]

@lzvezr #24

前端非对称加密怎么实现的?

用户的密码做秘钥, 然后 生成公钥, 把公钥传给服务端
服务端每次使用公钥验证?

怎么把密码作为秘钥 然后生成验证数据, 然后 用公钥验证?

[lzvezr]

@ruandao 客户带 cookie 请求盐和公钥，得到返回以后密码加盐再公钥加密，服务端不知道怎么处理的，但可以肯定的是能拿到密码明文

被中间人除非第一步盐和公钥就替换了，否则也解密不了