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

如果前端传给后端的只有 md5 而没有明文，那么只要这个 md5 被拿到，同样可以请求相同的接口登录成功，这和原始密码有什么区别吗？

前端把密码 md5 当然不是脱裤子放屁，把本来不定长度的字符串转化成定长的字符串，我如果想穷举密码，简直不要太开心。本来撞库还要跑一下彩虹表的，现在省了一步。

非对称加密下呗，公钥放前端加密，私钥服务端解密，中间人获取了数据也解密不了，反正不能明文传输，和裸奔没区别

这不说日经话题，算月经话题是可以的了吧。

先说结论，密码确实是要前端加密一下的。
不是说有 https 就可以万事大吉，它只是确保传输的时候不给盗窃，你怎么能确保传到服务器后不会泄露呢？
上面有人说既然服务器都被攻破了那还说个 JB ？
确实，但是只有被攻破才会泄露？
你的 NGINX 或者其他服务监控或者日志系统确定不会记录出入参？
只要有一个地方有记录密码，就会有泄露的可能。

看了一下 V2EX ，它就没加密

加密必要的前提是前端的混淆能不被逆向，如果能比逆向出来，公钥肯定也是写在前端里的。
像遇到的几个站，rsa 公钥加密，明文返回某对称加密私钥，然后后续用对称加密通讯。看着无懈可击，实际上公钥直接在源码里稍微逆向一下就搞到了，除了中间人一点用也没有。

感觉最好的办法还是用 jvmp 之类类似于抖音的加密/混淆，只能黑盒无法逆向，这时候才加解密才最有用

关于这个屁事，我就说一个看起来像是空话但估计很多程序员甚至很多安全人员都理解不了的结论：安全是一项多环节、多方位的系统工程，同时安全性又只是衡量信息系统的指标之一。如果不能用系统工程的方法来整体做安全，结果就是每个环节的草台班子都从“别人是比我更不靠谱的草台班子”的视角出发，极度不信任上下游，用各种山寨的、同时又是过度防御的所谓安全措施来把系统拖得无比复杂，影响业务可用和产品可维护性，并提高成本。

看情况：
1. 如果公司人不多，没有各种保密、合规要求，用了 https 的前提下，可以不加密
2. 如果公司人多，有保密、合规要求，要求尽量减少密码泄露的可能性，比如避免因为运维在网关打日志泄露密码，要用 https 和非对称加密（前端用公钥加密，后端只有一个服务可以有私钥解密）

当然有意义了。等保+密评的 表示 等保要求二级就建议在传输中进行加密处理。但此处的加密并不包含 md5 。 三级则是强制要求有加密。而且 md5 的你不要觉得不可逆。彩虹表只是目前还不够大而已。md5 再怎么不可逆。他也不算加密。他只是 hash 处理。不可逆不代表不会碰撞。

不管怎么样。就一句话。前后端都要加密。这个是基础中的基础。md5 也不是加密。这也是基础。简单的测试的时候都是直接在现场抓包看。不要说什么黑客无法在现场进行操作这种假设。现实中跳板机多了去了。

@adoal “极度不信任上下游”，我想说的意思是，同一个项目里不信任上下游的其他团队，甚至同一个团队里不信任上下游的其他角色。比如设计接口的人担心写业务代码实现的人没有安全意识顺手打 log 而 log 又会被运维的人随处乱放不妥善管理，所以传到业务逻辑实现处的信息先混淆或变换掉……特么的这不应该是团队治理要管的事么？当然现实中也确实有很多单位里做信息安全的部门是管不动业务部门信息化开发的，所以只能做各种渗透扫描、跨网段封管理端口和数据库端口、监听明文协议里的口令字段检查睿口令，然后发一堆整改报告等等。各种脱裤子放屁的扭曲安全设计，不一定对实际的安全有多大提高，但是对付安检倒是真的清净了。

有点用，但是用处不大，属于防君子不防小人的操作吧

不都短信登录， 或者扫码登录。 用密码的地方很少了。

你应该是指前端对明文密码进行 hash ，也就是用 hash 值作为密码，避免后端因为日志等原因导致用户原始密码泄露，从而被拿去撞库。

这里存在几个问题：

- 这种方式，唯一的作用就是密码传输的中间环节泄露后防止撞库其它应用。对用户而言，不同应用使用不同密码是个人信息安全的基本准则。对开发者而言，避免日志记录密码明文是常识。此外，密码明文在 TLS 的中间环节被泄露，而服务器却没有被攻破的场景太过理想。
- 这是一种魔改，不符合已有的密码认证协议，比如 Basic access authentication 。
- 对于多端应用，现有系统改造，需要废弃掉旧的应用版本。

简单来说，有用但没太大用，而且存在兼容性问题，以及升级成本。

确实是脱裤子放屁，某种程度上来说你 md5 后反而更不安全了，甭管你是否加盐，也甭管换啥更安全的 hash ，原本密码的不均匀的分布规律在 md5 后也一样不均匀，并且 md5 后的密码长度反而成为了固定值（ 128bits ），墒反而可能会降低，黑客可以确切的知道要 brute force 的密码格式；常用密码攻击也一样无法避免，原本用常用密码攻击，现在是用 hash 后的常用密码攻击

而且就像之前人所说的，如果黑客原本能拿到密码，那黑客现在也能拿到 hash ，而这个 hash 也一样是永久有效的，等同于密码

至于服务器 log ，如果 POST Body 都明文 log 下来了，那 hash 后的密码不也一样 log 下来了，而且很多同样敏感的 POST Body 也一样会 log 下来。这种属于 XY Problem ，应该去解决本质问题，而不是去其他地方脱裤子放屁

99%的情况下，没有学习过密码学的人自创的加密方法都是不安全的或者是没意义的。建议用现成的工具，比如 https 。确实明文传密码有不安全之处，此时的解决方案是去用 TOTP 、Passkey 这种成熟的加密解决方案（后者也涉及到“前端”加密），而不是去研究自创的前端加密这种脱裤子放屁的事

常规的解决方案就是前端不额外加密，密码直接 HTTPS 传，加盐 hash 后存数据库。我敢说绝大多数大厂的登录都是这样的。而且只要是 https 了，那就绝对不是“明文传输”了。如果 OP 觉得 devtools 里是明文有危险，那我可以告诉你，如果黑客都已经能读到这一层数据了，那直接监听键盘，或者直接读密码输入框都是可以做到的。

楼上都在假设密码在传输过程泄露，或者假设在服务端泄露。
那么泄露个 md5 加密后的密码和泄露原文密码有啥区别？
我直接拿泄露的 md5 加密后的密码去请求登录接口，同样可以换取 token 。
综上，有 https 的提前下，前端加密就是脱裤子放屁。（ Github 的登陆接口，前端传的就是明文）。
一切好听的话都是为了面试, 让面试官觉得你很注重细节罢了。

@mayday526 所以你看完我的帖子，泄露原文密码，用户多平台同一个密码，是不是很危险？泄露 md5 是可以换取 token ，只是这个应用被破解，但是只是泄露了一个密文。

@mayday526 完全胡说八道，拿到 md5 去请求，如果请求接口对所有请求参数做了加签，你怎么重放，你可以说破解加签算法，如果加签算法需要和后后端交互了。。。虽然安全只是相对的，拿到明文和拿到 md5 的结果当然不一样，撞库也不穷举所有密码，一个密码你不需要破解，一个你需要破解 10 年，是一样吗。

@ZE3kr 我这里加密的意义指的是避免密码原文泄露，而不是你所说的变成 md5 不安全，退一万步黑客破解了，那只是拿到了我的密文，而我原始密码没有泄露，像我多个平台都是同一个密码，原文被泄露了可以登陆我其他的应用。