盼大佬解答，前端加密到底是不是脱裤子放屁？

1. 鉴权：密码本身是不安全的，因为用户的各种不安全的做法。所以现在都建议使用两步验证，短信登录等 OTP 。甚至现在直接使用 passkey 替换密码。
2. 泄露：所有的安全建议都说过不要重复使用密码。如果没用，加密无所谓。如果用了，一个应用加密没有任何用。

敲一半才发现只有一点，其实应用加不加密是无所谓的，完全取决于用户习惯。

@userKamtao 你又没办法限制独立开发者一定要在前端做哈希，独立开发者想要拿你密码当然可以拿。我们讨论的话题是在 https 的前提下， 前端不做加密是否安全。 后端会偷密码或者日志输出密码这种都是属于系统内部的问题，就算要求前端做哈希，那前端还能在哈希之前把密码存下来，这种问题讨论没有意义。

@1iuh 你说的好像也有道理，如果是小人，前端页面也可以拿到密码。

看你怎么加密

如果你在前端实现了对称加密，那么就无意义。

如果你在前端代码里面 实现了 RSA 加密 那么加密还是有意义的

要哈希的，md5 是摘要算法，不是加密，加密是可逆的，可以解密，摘要是不可逆的，单向的。

为什么要哈希密码之后再传输，主要是 防止明文泄露，即使最差的情况，被拖库了，也只能获取到哈希的密码，而不能得到明文，因为明文密码可以用于撞库，而哈希不可以，因为不同的网站往往对密码的处理不同，比如，有些网站会加盐后哈希，这样即使大家用的同一种哈希算法，因为盐的存在也只会影响该用户在本网站的安全，而不会影响到用户其他的网站（很多用户多个网站的密码往往是一样的。）。

前端那不叫加密，那叫摘要（毕竟你不能把加密代码和密钥放在前端），这种情况后端存的应该也是摘要。

只能说不是没有用，有一点用。
比如有中间人攻击啥的，用户无视证书有问题之类的，这种就算是 https 请求，也会被看到请求内容；但是这种情况，会的人也会看你前端的摘要算法，然后找相应库去撞。
或者明文密码进入后端的时候，后端设计上只要想，就能看到明文密码，那这样对用户来说是不公平的。

用非对称加密算法，前端用公钥加密是有意义的

为什么 v 站一提到前端加密就扯 https?
这两者有半毛钱关系吗？

18 年的时候，我就问过这个问题： https://yangjunhui.monster/t/466847

你为什么不直接参考大型网站的做法呢？比如 Github


@somebody1
补充，前面没答到电子上。

网络安全是有木桶效应的，也就是最薄弱环节。如果前端不加密，则中间人攻击或者从流量中可能可以逆向出明文密码。这拖累了网站整体的安全。

只要有任一环节可以获取到明文（在网络中，存储中），就极有可能发生泄露。

至于前端 hash ，毫不客气的说就是脱了裤子放屁。

@lisongeee 好家伙 这个可以

@userKamtao #7 多平台同密码泄露影响到你是因为泄露你密码的平台直接存的明文，而不是因为传输过程是明文，这两者区别大了去了

要传输的数据是不是密码，完全是两个不同的问题。

「密码」就是要原地消灭，只传 hash 后的值，尽可能的减少暴露密码的可能。

举个例子给你说吧，某项目的登录验证是这样的：
​
1. 密码控件自身生成一个随机数 C ，并从 webserver 获取一个随机数 D 。
2. 密码控件将 C 、D 组成一个新的对称密钥 CD 。
3. 密码控件用密钥 CD 对输入的 X 进行对称加密，获得加密结果 Y 。
4. 密码控件使用非对称公钥 G 对 C 进行加密，产生加密结果 E 。
5. 将 Y 和 E 传送给 webserver 。
6. webserver 解密 E 得到 C,从而得到 CD
7. 通过 CD 解密 Y 得到 X
8. 调用 XX 算法计算 hash ，得到 A
9. A 与数据库存储的 B 比对，一致则验证通过。

无论是传输过程中的 Y 、E 泄漏，还是服务器上存的 F 泄漏，都无法推演得到用户真正输入的 X 。所以你说有用没呢

比较建议传递密码明文至后端, 后端自行 HASH 后存储.
启用了 HTTPS, 如果没有合规要求, 可直接传明文, HTTPS 就是保证传输安全的; 如果有合规性要求, 则按要求对密码进行前端加密处理. 前端加密虽然可破解, 但可以挡住大部分攻击者.

@userKamtao 在以前 https 不那么流行，运营商劫持 http 的时候，好多站点都是前端 rsa 加密的。淘宝，金山这些都是。后面 https 普及了，基本都是明文了。泄漏密码和前端加不加密关系不大。

我前端再混淆一下，加密就能刷掉一大把二把刀的人，意义还是有的

我在网吧忘了下机, 被后面坐我那的程序员盗了密码
我工位忘了锁屏, 被坐在旁边的同事拿到了密码
我使用了代理软件, 我电脑到代理之间不是 tls
......