闲暇之余，探索了一个小伙伴的开源网站，无意中发现了他的修改密码接口，是明文传输的，如下图。

后来我跟他反应了这个问题，我的观点是应该在前端 md5 加密一下，他说，他在后端做了加密处理，明文传输没问题，网站是 https ，前端加密不就等于脱裤子放屁吗？
和他几番讨论之后，无果，也有几个小伙伴觉得前端加密等于自己骗自己。
我经验比较单薄，以至于没有什么实际上的论点去论证，希望有大佬解答一下，这种场景在前端加密有没有意义。

讨论相当激烈，很多大佬说 md5 是摘要算法不是加密算法，加密这方面确实是我的知识盲区。其实 md5 不可逆，我觉得用 md5 没问题，就是要不可逆，后端只负责存储和验证 md5 之后的字符串。

感觉讨论的方向，有点脱离了我起初建立这个帖子的意义，我就是想表达，用户的密码不应该明文到达服务端，这就是我所说的“前端加密”，而不是底下大佬说的那种暴露前端的可逆“前端加密”，暴露在前端的可逆加密算法的确是脱裤子放屁，但是 md5 这种不可逆的算法，暴露无所谓，至少用户的密码已经得到了保护。至于密码难度规则校验，可以在前端实现，

很多兄弟给出了更加安全的做法，但是其实这个帖子的初衷，就是讨论前端加密有没有意义，其实前端加密也就几行代码，不见得多大的成本，但只要有能说得出来的意义，那其实还是值得去放这个屁的。

此话题终结吧，讨论了 3 页了，总结一下双方的观点。有必要加密：1 、防止无意泄露和二次伤害。（打 debug 日志无意间把用户输入打到日志）2 、隐私合规问题，参差不齐的员工可以拿到密码加用户手机号，登录任何设置此密码的网站。无必要加密:1 、https + 后端加密入库足够安全。2 、后端需要验证密码复杂度（业务场景）3 、增加开发成本，没必要。4 、加密后导致密码强度的下降(因为密文的信息熵下降了)

HTTPS 加密的情况下，如果密码以明文形式发送，那么在服务器端（如果被攻击者侵入）仍然可以看到密码的明文

https 的话前端再加一次密确实没啥意义

网站是 https ，前端加密不就等于脱裤子放屁吗

1. md5 是摘要算法不是加密算法2. 你在前端加密是想取得什么样的结果？是想提高安全性？还是防脚本小子？前者加不加密都一样，后者还是能防一些小白的

   如果服务器端被攻击那你密码不是怎样都会泄露吗？

QA 说我的表单密码没加密，然后我 btoa 一下就糊弄过去了。

这种情况下，他拿到的只是 md5 ,也就是你这个网站密码可能丢失，不一定影响用户的其他账号。

只是你的密码的 md5 被泄漏了，你的密码没泄漏，像我很多平台同密码的。

HTTPS 只保证通信过程的安全，不保证服务器上数据的隐秘性。前端加密可以防住很多脚本小子，但如果真要爬，分析分析还是能爬的

他说的对

伺服器端被攻擊者侵入，攻擊者直接替換前端為他自己寫的前端，這樣前後端都是攻擊者掌控了，明文密文都無救.

有点用但不多，防中间人（比如公司电脑加域，签根证书）偷密码，然后猜测你其他网站的密码（无聊的人）

加密信道明文传本身没问题，但需要注意衍生的风险，比如日志暴露明文密码之类的，Google 都是直接传的，我觉得可以终结这个讨论。

加密这个词不对, 也不该用 md5. 应该用 sha256 哈希一下, 为了密码明文不对服务端暴露. 同时, 服务端应该加盐再哈希一次, 为了防止彩虹表撞库

https 报文前端加密确实是脱裤放屁呀. 换个角度来说, https 其实就是保证传输通道在某种程度上的可靠性, 如果你客户端或者是服务器都被挂马了, 那传输过程加不加密又有什么用呢

你密钥放在前端加密有啥意义？自己骗自己？

有用但不多，基本等于脱裤子放屁

＃7 ＃8不敢苟同，你都攻破服务器了，替换个静态资源很难吗？我直接替换个不加密的页面不就行了？

你替换静态资源可能能欺骗一点时间内的用户密码。如果你记录日志，你可以长期拿到明文（ md5 ）

都用了 https 了，再加密不就相当于自己骗自己吗

之前公司的前端是对参数做 aes 加密，后端解密，只是相对破解门槛较高而已。还有密码应该要加密也不会用 md5 这种不可逆的方式吧，不然密码规则后端怎么校验

这还有啥可讨论的。。

＃19 我只需要把加密部分的代码删掉就行了，为什么只能欺骗一段时间内的用户密码。

90%的业务情况是没必要的，因为 https 足够安全。但是，如果你客户端浏览器装了恶意证书，那么请求的内容就会暴露。所以你可以自生成一对证书，在发送前用证书加密，后端拿到后用私钥解密，在一定程度上能避免这个问题

是

在 https 的前提下，前端进行散列或者签名的唯一积极意义是防止初级选手来刷接口或者简单的重放攻击除此以外不具有什么太大的积极意义。

你需要改动前端，然后需要反编译后端的代码/服务，逻辑，然后再编译回来，然后还需要部署。这个工作量会不会很大？

看目的是什么，防密码泄露是用处不大，但是请求体、响应体非对称加密再加上 JS 混淆 vmp 加固对防脚本逆向还是有一点点用的

"还有密码应该要加密也不会用 md5 这种不可逆的方式吧"就是要不可逆，才能防止内鬼拿用户数据去卖钱啊。

用后端传过来的盐算摘要后传回去，数据库只存 salt 和密文，传输过程中也只有 salt 和密文

1. md5 不叫加密。2. 仅用 md5 也起不到保护密码的作用，请搜彩虹表。3. 1 楼说那种情况，一般是指数据库泄露了，导致用户的密码被泄露。 但是楼主正文提到了， 后端说处理过了。4. 确实是脱裤子放屁。

   ＃27 有没有可能我只需要通过前端代码反推出加密逻辑就行，在后端服务前面再套一个服务负责加密用户名密码，在了解了加密逻辑后这一套下来不是快的很

处理不好的话，员工 debug 的时候记一下 log 里的密码再简单不过了。

但如果不加密，那意味着服务端可以拿到用户明文的密码，用户隐私这方面是不是也值得去考虑呢？

如果那是一个独立开发者开发的网站，用户多平台密码一样，服务端不就可以知道用户密码了？

不是脱裤子放屁。可以防止无意泄露和二次伤害。比如打 debug 日志可能会无意间把用户输入打到日志里，这样会泄露用户密码明文。还有黑客流量复制攻击，不是所有攻击都会改代码的，有种攻击是观察者模式，只在网络层增加一个转发插件把流量全部转发给自己。如果用户提交了明文密码，那密码就会泄露。如果是前端摘要过的，那只会泄露 hash 。

不要明文，隐私合规问题。如果明文传输你可能在任意环节暴露出用户的真是密码。如果操作不当你的员工甚至可以拿到密码加用户手机号登录任何设置此密码的网站。在一个如果用户是明文，这样的记录会出现在日志，代理多个地方。所以密文是必须的，不在安全，旨在合规

感谢回答！但是我觉得防密码泄漏就是防所有人，包括服务端本身，服务端不应该直接能拿到用户的密码。

前端密码加密确实没有意义, 如果 md5 加密, 实际上 md5 的密码就可以当成密码, 为了防止密码在传输过程中被监听, 使用 https 即可. 前端加密通常是为了混淆接口请求参数, 防止爬虫, 当然也只是防君子不防小人.

这位绝对是大佬，看 id 就知道了。

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

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

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

看你怎么加密如果你在前端实现了对称加密，那么就无意义。如果你在前端代码里面 实现了 RSA 加密 那么加密还是有意义的

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

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

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

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

18 年的时候，我就问过这个问题： www.hesudu.com/t/466847

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

补充，前面没答到电子上。网络安全是有木桶效应的，也就是最薄弱环节。如果前端不加密，则中间人攻击或者从流量中可能可以逆向出明文密码。这拖累了网站整体的安全。只要有任一环节可以获取到明文（在网络中，存储中），就极有可能发生泄露。

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

好家伙 这个可以

＃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,从而得到 CD7. 通过 CD 解密 Y 得到 X8. 调用 XX 算法计算 hash ，得到 A9. A 与数据库存储的 B 比对，一致则验证通过。无论是传输过程中的 Y 、E 泄漏，还是服务器上存的 F 泄漏，都无法推演得到用户真正输入的 X 。所以你说有用没呢

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

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

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

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

有意义的，对于同账号服务器只存储加盐的密码 hash ，客户端 hash 后再发送密码，可以确保用户在该网站密码泄露的同时此密码无法被用于撞其它网站的账号

密码学经典之不要自己设计加密算法

问题有点多，随便指出一点吧。你说 "我的观点是应该在前端 md5 加密一下"首先 md5 是一个 hash 算法，直接将这个 hash 值传给后端，后端没办法逆向回去，一些业务比如判断密码的复杂度做不了。

如果你把各方面可能的参数和漏洞都考虑了一遍，你最终会发现你要把 https 重新实现了一遍。

＃18 认同你的看法，但凡是泄露，不论是不是 md5 后的结果，都可以伪造请求拿 token 之类的操作了

谢谢大佬，但是这个判断复杂度其实，可以在前端做，后端不需要知道我的密码是什么，这样会安全很多。

你要不再写一个 https 呗

考虑隐私，不应该明文传输密码

＃7 那也应该在后端加密的好吧 前端加密就是无用功 而且 md5 严格意义上来说并不算加密算法

中间人攻击 https 就能阻止好吧

你说服务端拿到明文密码就不太对，这种都不需要你去考虑的，服务端要做的是加密一旦存入数据库就不可能有明文，没有人知道这个用户的明文是什么，目前在我看来 95%以上的系统前端都是直接明文传的， 如果是前端做处理那就会被知道这个系统用了什么加密算法，这也是一个隐患。

不需要加密，你可以学习一下 https 的原理和对应解决的问题

我更喜欢加密的，因为中间可能有 CDN ，虽然 CDN 是可信中间人，但是多一层保险比没有好。

＃66 你是真离谱呀兄弟！ 按你这思路 啥判断都能在前端做？那你这个判断复杂度是不是能被轻松跳过？ 并且 hash 这种无法逆向的算法，你给后端传个这玩意 你让后端怎么处理？ 离大谱！！！ 理论上 https 的网站不用做前端加密，事实上很多大厂的页面已经是这样做的（那些说中间人攻击的，可以开启 HSTS 并加入 HSTS Preload List ，双向认证，HPKP 等，除非你电脑中病毒等情况 这谁都没办法）。 就算要做加密 那也要选可逆的算法呀 比如双向 RSA 加密，否则后端拿不到实际值有啥用。。。

google 登录也是明文传输的，也就用了 https

你前端加不加密都无所谓，反正不管你传的是明文还是密文，后端都一定要对你传过来的东西先加盐然后再做加密，然后再存到数据库里，只是你传密文的话，一些密码合规性的判断，后端就没法做了

的确是脱裤子放屁 OP 再提高一下姿势水平

其实服务端没有任何地方需要用到用户的密码，直接存储 md5 后的字符串即可，md5 不可逆，为什么还要加密算法呢？

安全是多环节的，多一个环节不是坏事，还可以增加用户对网站安全性的信心。你也可以不加密，但是你会遭到用户质疑，用户会觉得你是不是在后台明文存他的密码了。我记得 Github 有的表单就没加密，具体记不得了，好像在 hacker news 上刷到过。加个密屁大点事，建议别偷懒了。和用户为这个扯皮挺没劲儿的。

为什么要拿用户密码？你为什么要知道用户的密码是什么呢？滑天下之大稽

const params = { account: encryptByDES(account.value), cellPhone: encryptByDES(cellPhone.value), password: encryptByDES(password.value), name: encryptByDES(name.value), }; 你想要这种东西吗？？？这种只是看起来是加密的而已，就是从 f12 看不出明文，但是防君子不防小人，只要到到通过 f12 在 js 文件里面去搜索，相关代码和加密用的 key 一目了然，有的甚至还会有对应的 decryptByDES 方法。那有啥实质意义。

我觉得没有几个用户会关心这种事情。甚至没有几个用户去真正关心 ui 。

上面一堆程序怪咖觉得 https 就是一切，还有说 md5 不是加密的，我扔一串 md5 给你，你一个星期解的出来不？就说这最经典的场景： 前端日志上报，一般都会抓接口请求参数，你告诉我日志后台都是明文是吧？一看公司内部就没安全扫描机制，不然就是一个 p0 的安全问题！

可以，但没必要。硬说有什么意义的话，那就是加大了工作量，能消磨时间

不可逆的算法得出的密文密码给后端密码合规怎么判断？并且我不光说密码 我说所有的数据，不同数据后端可能需要不同的校验都传不可逆的给后端有啥用？ 就算要加密也要用类似两套 RSA 的方式。你真的需要再提高一下姿势水平，如果不是姿势水平低我都怀疑你这话题是来骗币的！！！

没理解我意思，我的意思是前端对用户输入的密码直接 md5 ，后端直接用 md5 后的字符串。登录和注册皆是如此。

只传输 hash 相当于在当前站点 hash 就是密码。

除非前端不用可以反编译的语言编写，否则就是脱裤子放屁。

HTTPS.HTTPS,好像用了 https ，就可以包打天下了、那么 HMAC ，SRP 这些设计的协议也是多余？

我感觉应该没有隐私什么事情，前端对字段加密，一般也就是做个对称加密，而且前端代码对任何用户都是可见的。 对称加密 + 代码可见 = 没有隐私。

不是，注册时候数据库存储了前端传过来的 md5("123456")，登录传输的 md5("123456")字符串，这两个字符串，不能比对吗？你非要逆出来 123456 才能判断是吧？

你放十万个心，99.9%的企业就算最终入库的密码也不会是不可逆算法保存的。 你但凡别提 md5 都没那么离谱。前端加密也不是脱裤子放屁，两份双向 RSA 就能解决可靠性。99.9%的企业无论什么数据服务端必须能逆向成明文。

后端库对密码字段存的本来就是 md5 ，不论前端做不做安全。后端的安全性不会依赖前端

大佬，我就单讨论密码这一个场景，密码也需要逆向？

最简单的需求密码规则校验怎么实现呢？你考虑的太片面，产品要多方面考虑的。

肯定不是，加密是为了提高破解的成本，前端随便搞个加密就能过滤 80% 的脚本小子。看你网站的价值了，如何被高手盯上，上啥加密也不行

站在一个安全的角度来说，前端加密多了一道墙，如果不加密比如说在一个网吧用户登录后上来一趟测试，一位懂点技术的 F12 就能看到这个用户的信息了。

什么日志上报不安全，开发不当回事非要把密码忘外送哪个端拦不住

早些年都用 http 的时候是有意义的，毕竟是明文传输。印象中当年校内/人人的密码登录是 http+RSA 加密。这儿的加密，或者 https 的意义是在于传输安全。存储（数据库）中应该存哈希而非明文也是有意义的，避免数据库被脱裤后泄露密码。当然，这和前端加密无关。但是，上面有一些人提到说前端加密/哈希可以应对服务器被黑后导致用户密码泄露的情况。笑死，如果我都能完整控制你的服务器了，你之前怎么做有关系吗？我反正能改成让用户直接提交明文。 『还有说 md5 不是加密的，我扔一串 md5 给你，你一个星期解的出来不？』彩虹表了解一下。加密和哈希的区别也是常见的区分科班和非科班的方法。

脱裤子放屁，是为了放置放屁崩出屎。