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

[userKamtao]

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

后来我跟他反应了这个问题，我的观点是应该在前端 md5 加密一下，他说，他在后端做了加密处理，明文传输没问题，网站是 https ，前端加密不就等于脱裤子放屁吗？

和他几番讨论之后，无果，也有几个小伙伴觉得前端加密等于自己骗自己。

我经验比较单薄，以至于没有什么实际上的论点去论证，希望有大佬解答一下，这种场景在前端加密有没有意义。

讨论相当激烈，很多大佬说 md5 是摘要算法不是加密算法，加密这方面确实是我的知识盲区。

其实 md5 不可逆，我觉得用 md5 没问题，就是要不可逆，后端只负责存储和验证 md5 之后的字符串。

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

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

此话题终结吧，讨论了 3 页了，总结一下双方的观点。

有必要加密：
1 、防止无意泄露和二次伤害。（打 debug 日志无意间把用户输入打到日志）
2 、隐私合规问题，参差不齐的员工可以拿到密码加用户手机号，登录任何设置此密码的网站。

无必要加密:
1 、https + 后端加密入库足够安全。
2 、后端需要验证密码复杂度（业务场景）
3 、增加开发成本，没必要。
4 、加密后导致密码强度的下降(因为密文的信息熵下降了)

[kneo]

@userKamtao md5 聊胜于无。它的问题：

第一，md5 的输入和输出是多对一的关系，对无限数据来说当然不可逆，但是用户密码都是短数据，你如果把用户密码显示在比如 16 位 ascii 字符的范围内，在这个有限的输入集里，碰撞相当少，可以认为是“可逆”的。

第二，md5 属于很落后的算法，应该是有方法可以暴力逆向的。学术方面的研究我就不花时间搜了。即使是普通用户也可能通过 md5 库查询到原始密码（即使你加过盐）。

第三，即使 md5 是不可逆的，它有一个特性，就是同样的密码，md5 结果一定是一样的。如果有人捕获了你传过去的 md5 ，下次就可以用这个 md5 登录。这就相当于一个永久性的 token 。一个好的加密算法应该每次都生成一个不一样的，不能重用的 token 。

[sakilascott]

打个比方，你们公司的运维想窃取用户密码，但他没有 dba 权限，如果明文，他就可以在服务器日志获得。

[kneo]

@996jiucai 没错，一般用户不会看这个。但只要有一个用户注意到了可能就会晒到网上然后变成扯皮。有人可能觉得没必要浪费时间实现这个功能，我的角度是没必要浪费这个时间扯皮。

[luoway]

@kneo #101 第三很对，相当于把密码从人类可读转换为无意义的密码，依旧是明文密码与后端通信。

简单的前端加密可以认为是脱裤子放屁。
合理的加密是前后端配合，以保证每次通信或者每个会话期间是不同的加密结果。

[libinglong9]

这个问题我深入研究过，对于秘钥的传输，正确且安全的做法是前端使用慢 hash ，后端使用快 hash 。

前端慢 hash 用于防止暴力撞库。后端快 hash 则是为了防止数据库，日志等被非法入侵或者数据泄露等造成的秘钥泄露问题。

[userKamtao]

@kneo 你说得不无道理，如果是一个钓鱼网站，前端代码在他那，想钓你的密码，也是很简单的。主要还是防止服务端，如果是很乱的公司，指不定有屌毛把明文输出到日志，然后把日志发给外包排查。

[huijiewei]

不要用 md5 , 要用就用 argon2

[eber]

此贴终结吧！这帖子说来说去就俩问题：
1. 首先从能不能破解这一层来说：前端加密不算脱裤子放屁，因为两套 RSA 可以保证无法在前端被破解。

其次讨论你这个离谱前端 md5 传值到服务端的问题

2. 无论业务场景是否需要前端加密 都不应该选择前端 md5 传给后端，应该选 1 中的方式。
3. 从企业的角度考虑任何到服务端的数据都应该能被服务端计算出实际值，所以还是选择 1 中的方法。

[userKamtao]

@luoway 第三点，那就算不是 md5 加密，有人捕获你的密码也一样能重复登录；这里使用 md 加密的逻辑是，不让别人知道你的密码，然后去其他平台登录，我是这个意思。

[Kaiv2]

@shakoon 客户端 C 可能泄露，请求获取的 D 可能泄露。CD 对称加密 X 。弯弯绕绕可能复杂了一点。唯一有用的是 非对称的 G, 加密了 C 传送给了服务端

[zhw2590582]

我发现我平常访问的知名网站都是明文传输密码的

[mxT52CRuqR6o5]

你先调研看看那些大厂比如 google 微软的密码是咋传的，而不是啥都没研究过全凭自己想象就去指挥

[Ritr]

加密可以有效防止脚本

[Kaiv2]

基于用户角度考虑是有用的, 服务器被黑了，也没法捕获到真实密码（除非暴力计算）

[Kaiv2]

@Kaiv2 坏处就是如果有多端登录需求，都需要统一算法

[eber]

@Ritr 现在有很多可以调用 Chrome devtools 的库了，直接模拟用户输入和鼠标点击操作，所以针对防止自动化脚本这个层面没啥用。你自己可以试一下这个 - chromedp 库

[userKamtao]

@mxT52CRuqR6o5 大佬，你别生气，因为谷歌和微软业务需要在浏览器记录你的登录密码。

[liuhuihao]

@userKamtao #94 后端在很多场景下需要拿到 明文密码的，就最简单的例子就是校验密码是否复合规则，长度、大小写一类的，这个校验的事儿肯定不能只放到前端做，然后你前端给 md5 了后端就没法校验了都

[lasuar]

不管是传输还是处理端，都应该避免出现明文密码。

1. 比如你能够通过 F12 看到传输的密码明文就是不合理的（当别人用你的电脑时就可能看到）；前端（ app/浏览器等）应该对输入的密码编码/加密传输，具体方式根据系统安全要求实施，比如从安全性低到高：baseN 编码、哈希算法、对称加密、非对称加密。如安全要求较高，则还可以使用二进制协议如 protobuf 传输数据，杜绝通过 F12 查看到可读文本的可能。

2. 后端一般收到的是处理过的密码文本（不应该能逆推出明文），比如哈希、或加密过的哈希，二次处理（可能需要解密）后再将其写入 db 或与 db 存储的密文进行匹配验证。（ db 存储的一般是密文二次加盐后的字符串，不应该是明文密码）

这样前端后端都无法获得密码明文，将密码暴露的风险降到最低。

[crysislinux]

属实没必要
1. 假如你们这项目就是个蜜罐专门骗用户密码的，那没必要搞这个
2. 如果你们是正常项目，后端拿到明文就加盐加密了，怎么泄漏，也没必要搞这个

用户已经被教育不要在多个网站用相同密码了，如果你还想提高安全性，上 mfa

[voidemoer]

没必要，但是有用。在大公司里这么做，安全部门直接给你提低危，修不修是你的事，和安全部门掰扯就行。

[voidemoer]

黑客在任何一个环节都有攻击可能，而且成功进去也不会总是完全控制，很多时候就是只能读，但这已经是很大的问题了，因为只要能读就意味着脱裤可能。安全部门要是这么跟你扯，肯定还是得修
@voidemoer

[erwin985211]

我插一句脱裤子放屁 比穿裤子放屁要爽的多，特别是闷屁

[unclemcz]

前端加密是为了防止中间人攻击时泄露明文密码，其他感觉意义不大。

[SilenceLL]

有点用，至少我见到的攻击短信接口大部分都是未经过任何加密的，稍微处理下提升一点点难度就可以让很大一部分攻击者放弃。除非你真的很有价值，值得破解

[Jirajine]

我不知道你和那些认为后端有必要拿到明文密码原始值的人有什么交流的必要。
从这个角度来说，只要后端能拿到明文密码原始值，那些什么 rsa 之类的确实就是脱裤子放屁。

[Nosub]

别说 op ，就是 CSDN 这种专业网站，不也是数据库明文保存的密码吗，程序员的弱//智行为永远比你想的还要弱//智一万倍，其实 op 说的没什么问题，业内早期的做法是 md5 ，不过改了，后来基本改为了①加盐+②md5 ，这样可以保证服务端也不会知道用户的密码，而且保证传送过程中的安全，其实为什么不要单纯的 md5 ，因为容易撞库，就是已经有大量的 md5 密码的对照表了，大部分的密码是可以直接通过 md5 数据库反查出密码，另外如果你直接明文传送，那别人可以知道你程序的处理密码的逻辑，其实这是一种风险，https 这个其实很多人没搞明白，https 不是绝对安全的，依然会有伪造证书的可能，抓包也不是不可能，也就是依然会有中间人攻击的几率。

[isno]

送给你 对称/非对称以及公钥基础知识。

https://www.thebyte.com.cn/http/https.html

[virtual2019]

是不是脱裤子放屁不知道，反正谷歌微软苹果 fb 都是明文传密码

[kenvix]

1. 需要散列，但不是 MD5 SHA 之类的常规通用散列，用 Argon2 ，Bcrypt 之类的专用散列
2. 主要是防止少量特殊情况，比如用户遭到中间人攻击（说的就是企业网络）、以及上面说的打 log 泄露

[monkeyWie]

@gam2046 正解

[0o0O0o0O0o]

你比他正确一点，但还不够正确，可以阅读 https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

[jadeborner]

这块好像讨论过多次了，结论是有意义，聊胜于无。

[renmu]

用户修改的密码你用不可逆的算法传输，那么数据库怎么存进去呢

[Nosub]

op 要相信自己的判断，虽然安全只是相对的，你要做的是把风险一步步降低，你永远挡不住人为的低级失误，业内为什么要加密，绝不是脱裤子放屁，就像前面的说的，如果你服务器被攻破，或是流量被劫持，或是日志文件被窃取，黑客不是一样可以拿到明文。

[halobabyy]

感觉前端加密没有任何必要，因为只要抓到包，就可以复现请求。（但是大佬们总结的避免枚举猜 id 的用处也还是很有用的，因为我也写过爬虫）

[whileFalse]

客户端做对称加密基本上是脱裤子放屁。做 md5 摘要并加盐（盐可以是静态的）可以避免服务端拿明文密码。

[Nosub]

@halobabyy 重复请求个鬼啊，请求参数会加签的，就是防止重放攻击的，除非你破解别人的加签算法 .

[simo]

安全角度，是通过各种手段，提高破坏的成本。
看场景决定使用哪些手段，只要风险可控就行，明文也没问题，比如非公开网络，非重要数据。

[gamexg]

@vmebeh #30 那么攻击者也不需要知道密码明文,一样直接提供 密文就能完成登录.



我是觉的真要想前端加密,那么就用非对称算法加密, 前端只有公钥,没有私钥.后端再用私钥解密密码,然后在对原始密码加盐 hash 去比较数据库.

[arthuryangcs]

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

[icy37785]

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

[Chuckle]

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

[adoal]

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

[NickX]

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

[qiyue0726]

看了一下 V2EX ，它就没加密

[gongquanlin]

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

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

[adoal]

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

[suren1986]

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

[Liftman]

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

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

[adoal]

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

[haoyu7]

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

[jones2000]

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

[CLMan]

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

这里存在几个问题：

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

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

[ZE3kr]

确实是脱裤子放屁，某种程度上来说你 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 这种成熟的加密解决方案（后者也涉及到“前端”加密），而不是去研究自创的前端加密这种脱裤子放屁的事

[ZE3kr]

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

[mayday526]

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

[userKamtao]

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

[Nosub]

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

[userKamtao]

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

[hanai]

我开发的登录页是在前端用公钥做了加密。

[kfish]

是

[userKamtao]

@Nosub 是滴，我的意思就是保证，用户入参之后将原始密码 md5+盐 加密起来，即便是泄露也拿不到原始密码，这样来避免撞库的情况。

[mightybruce]

这都能讨论这么久，一般场景下的前端加密不但愚蠢而且浪费性能。
你当前端代码用户端看不到吗？

有一种场景是另外，那就是前端代码是非常重要的资产，比如游戏，vr 视觉，那么前端代码和逻辑一般不想让别人看到，这时候代码加密并混淆以及 wasm 这些都是要用的。

还有人回答 RSA 、AES 这些， 这些已经是细枝末节了, 麻烦了解一些 Session key establishment protocols 和 一些 anthentication, https 主要是为了防止用户访问了假冒的网站，给你的网站信用背书。
安全不是仅仅靠加密算法，而是靠协议，要保证 key freshness 、effectiveness 、implicit key
authentication 、key confirmation 这几个条件。

[agagega]

防被脱库难道不是靠数据库加密存？前端散列只能防止服务端意外留下明文，其他时候没啥用

[ZE3kr]

@userKamtao 用处微乎其微

1. 如果泄漏行为本身发生在前端（如恶意浏览器插件），那无论如何 hash 还是会泄漏原密码（读密码输入框/键盘事件），从而所有网站登录被攻破（无论是否前端加密）；
2. 原密码在其他未前端加密平台（是大多数网站）的后端或者传输层被泄漏，也一样可以计算出 hash 后的密文在你的平台上登录；
3. hash 后的密码在你的平台上的后端/传输层泄露，那所有用一样前端的前端加密算法的平台也一样可以登录了

下面考虑情况 3 ，能否每个网站做到不同的 hash ，从而实现每个网站的 hash 算法都不一样。这个可以做到（在 hash 前 append/prepend 一个平台 dependent 字符串就行）。但因为有 1-2 的存在所以 3 的意义有限。此外它带来的麻烦也不少，比如需要修改多个前端（不同客户端和网站）

而且我也提供了解决方案，直接用 Passkey 。用 Passkey 才是王道，而且绝大多数新版的 OS 都支持了

[INW017bzMfgkkYGn]

@gam2046 相当于穿了个麻花裤子

[mayday526]

@Nosub 你没做过爬虫啊？第一步获取表单的所有字段，你的隐藏 sign 也拿得到。第二步组装再去发起请求直接获取 token 。所有操作都是基于脚本，验签即使加了时间差也没有问题。
什么重放攻击都是扯淡，我先获取表单的内容只要没有提交过给后端，都不属于重放攻击，都是模拟人为点击触发的。
什么加签算法跟后端交互，更是扯淡，先发起一个请求去后端换取 sign ，再拼接登录表单参数直接换取 token 。
只要基于表单的密码参数是泄露的前提下，换取 token 都是必然事件。

[ZE3kr]

当你使用前端加密，并同时修改后端加密，以尽可能避免这些攻击时，你会发现你最终实现的东西是跟 Passkey 一样的。Passkey 不但不会泄漏原始密码，同时每次登陆所传输的东西还是不一样的

[userKamtao]

@ZE3kr 你说得不无道理，但每个网站和客户端对密码处理方式都不同，可以大大减少撞库概率。

[Nosub]

@mayday526 要不我把我网站的 md5 和加盐的后的密码告诉你，你去模拟登陆看看。

[izToDo]

记得在 V2 之前有人问过同样的问题，我这里也把上次看到的贴文 PO 下： https://blog.huli.tw/2023/01/10/security-of-encrypt-or-hash-password-in-client-side/

[mayday526]

@Nosub 我费那个劲写个爬虫就为了给你证明密码已得的情况下重放攻击都是扯淡？我有病啊？
GitHub 登录账户和密码都是明文传输，你咋不去证明 GitHub 登录明文传输都是漏洞？

[BGLL]

感觉，现在程序员的思考能力平均值，有所下降呢

[mightybruce]

@ZE3kr 感谢分享 PassKey ， 这又提供一个 安全协议可以分析，看了还是用了比较传统的验证身份信息以及 chanllenge response 模型。

[lriushi]

@userKamtao #117 你怕是在滑天下之大稽哪个大厂敢在浏览器记录密码，你不会以为 remember me 是干这个事情的吗。

[userKamtao]

@izToDo 这个非常全面，感谢！

[userKamtao]

@lriushi 抱歉理解错了，github 和谷歌确实明文传递了，只是猜测会不会和谷歌浏览器的自动填充账号密码功能相关。

[lriushi]

@userKamtao #178 普通人说出这个话我能理解，但是作为程序员呵呵呵呵。。。

[alphat]

我觉得严谨的大公司后台，肯定有一套防止前端明文不被内鬼开发或是日志提取的机制
但不是所有公司的后台都能做到

[ivvei]

@shakoon #56 第七步打个日志就知道 X 了。然后你服务器上存的 F ？前面有 F ？

[goophy]

前段这么不信任服务器，https 和浏览环境，别密码了，所有的前端收集的敏感信息都加密一遍得了

[Peek]

chrome 都说过了，如果让贼人进了家里，再加个保险箱没啥意义。前端加密有意义，即用户的密码原始值只存在于用户的应用程序，不存在其他任何地方，应该用长度大于密码的不可逆算法去计算避免重复的情况，将原始值带离自己家都是增加风险的行为

[vmebeh]

twitter 不就干过把密码明文打进日志的事吗

/t/452464
看起来好几个大厂都干过，大厂干过的不一定一定是对的
盲目跟随有魅力的领袖，带来的很可能是灾难呢

[fpk5]

@userKamtao #78 md5 这种算法在密码这种应用下彩虹表非常简单，暴力穷举都是可行的。

[fpk5]

@kneo #79 多一个安全环节就多一个攻击面。

[fpk5]

@dudubaba #83 接口请求日志啥都记下来？你们的日志系统没有 data masking ？这个问题更严重吧。你接口请求 cookie 记不记？用户表单里的电话地址身份证号记不记？

[Anarchy]

看到这里好像后端要明文的场景就一个密码强度校验么，共识也是不能明文入库。这么看前端做个 hash 好像不是很麻烦的事情，不过如果从大厂这种一个账号体系对应无数业务前端来看就会变得难做了，相对来说严格规范后端会更容易。结论上对自己服务器不是很有信心并且做单一产品的话是适合前端 hash 的。

[Ursapharm]

大概和 Macbook 把内部结构 pcb 弄得那么漂亮差不多意义

[LaoDahVong]

肯定是有意义的.
至少对于我来说就好比是我永远不会在稀奇古怪的网站上 (包括 V2EX xD) 用我的 master password, 只敢用随机密码.就是担心哪天这网站被扒做一些明文储存密码的事情.
然而如果是大厂我就无所谓了, 会用我自己常用的几个 master password.
如果前端可以看到密码是加密后传输的, 那我就少很多心理负担了.

[fengchang]

我来说一个前端加密的例子，一个电商系统，会在前端加密信用卡信息。

在一个复杂的大型网站上，数据会流经很多子系统，从前端到中间层到支付后端，最后到专门的安全存储，中间会经历数次加密解密，如果明文传输的话，有权限接触到信用卡号的人成百上千。所以支付系统里有个专门做支付信息存储的组，会提供一个 widget 给前端用，widget 会带一个公钥，加密支付信息，然后通过一层层的系统传回去，回到这个组的时候才解密。这样能接触到支付信息的人就会降低到几十个。

[iseki]

首先，口令应使用专用的哈希算法，bcrypt argon 这种，而不是随便 md5 一下，至少也应该按照有关 RFC 的要求迭代+padding+hash 。
考虑 md5 这种简单的 hash 是否潜在地缩小了用户口令的值域。此外如果你无法在前端完成正确的口令哈希过程，该 hash 的泄漏和用户口令泄漏没什么实质性区别。

[iseki]

如果你真的希望服务器远离用户口令明文，那不得不采用更复杂的方案，比如说采用某种公钥算法，以用户的口令加密私钥，私钥不离开用户的电脑，服务器只用过挑战响应来实现对用户的认证。

[tairan2006]

最安全的是无密码
其次是二次验证
前端加密和明文 https 相比意义确实不大

[luzemin]

@nomagick #13 同意

[bigha]

防一下小白是可以的，老手直接就把裤子给你脱掉了

[lichao]

没有意义，你假定了 MD5 后的密文泄漏了无所谓，反正不知道原始密码。

但是，但是啊，仍然可以通过向服务器发送这个 MD5 后的密文达到登陆目的。

跟明文发送，基本没有区别

[Dragonphy]

@cus #98
admin admin123🐶

[dcdlove]

@1iuh #31 安全没有 100% ，但不是丢掉安全措施的理由，前端至少要做到非明文传输:
1 、浏览器本地存储，敏感信息不能直接存 ，（不要明文，至少混淆加密）
2 、 密码提交，至少 非对称加密 256( md5 （密码+用户盐+地区盐）) , 有的还会要求使用国密算法
3 、不要使用数据记录主键作为参数 ，（后端处理）

[fcfangcc]

@userKamtao 如果传给后端 md5 ，那你后端如何判断密码复杂度是否符合要求呢，在前端判断？