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

[userKamtao]

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

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

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

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

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

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

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

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

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

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

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

[idealhs]

@eber #74 苦口婆心说这么多，他除了顶嘴，给你学费了吗？😅

[DefoliationM]

md5 不是加密，最多算个 mac 算法。
前端加盐哈希有用的，可以防止被脱库后造成用户数据的泄漏。
但是前端加密确实是脱裤子放屁，因为 tls 已经加密了一层了，如果真能被劫持，完全可以替换前端页面。

[knightgao2]

密码什么时候都不要明文存数据库呀，这不一脱裤都没了

[dcdlove]

@BGLL 这部分人最起码的安全底线都丢了，依照他们的逻辑家里门都别装了，反正盗贼可以用铁锤砸开，但凡做过正式一点的项目就不能验收通过，明文传输真丢不起那人？
表单数据起码的非对称加密都是现成的库，安全核心混淆，防止浏览器断点调试引入，至少大部分前端狗防住了，

[nutting]

我们被甲方要求整改这种问题，用的是非对称加密算法，前端公钥加密，后台私钥解密

[shenjinpeng]

既然密码必须要 hash, 那其他敏感信息是不是不准用了 ?

比如身份证号码, 银行卡号码 , 支付密码 ,地址 ,电话 甚至登录的验证码是不是也得散列一下 ? ......

[dode]

现在浏览器支持无密码登录了，哈哈，基于公私钥体系

[zsdroid]

楼主显然没有想到，明文密码不变时 md5 也不会变。意味着这串 md5 相当于明文密码。攻击时只需要传这串固定的 md5 不就能登录了。

[jaycelhz]

闹麻了，这么简单的事情，参考下 google ，ms 不就行了，加了能让你舒服点就加

[kaiserzhang123]

简单来说，前端加密是很有必要的，在一些场景下会经常用一些代理/通道进行转发，这种必然会有造到拦截/监听的可能性，所以前端加密必不可少。

[sss15]

@eber #92 没想到我呆的公司竟然属于那 0.1%，我们都是 md5 （密码+盐）保存的，无法逆向成明文

[horizon]

@LaoDahVong #189
登录时明文传输和数据库明文存储是 2 回事

[horizon]

你都假设黑客能拦截你的 https 请求了，前端密码再怎么加密有蛋用？
这点基础的逻辑都理不清

[eber]

@sss15 兄弟，我咋感觉你说的是后端入库加密呢，你确定你公司前端往后端传输用的是 md5 密文？ 这里讨论的是前后端交互，不是最终数据存储形式。最终数据存储肯定是要密文存储的，这没有啥争议的。

[ajan]

密码：不就是用来防自己的么？

[bzw875]

密码是用户隐私，后端和数据库不应该明文存储用户密码，把密码提取 MD5 下次登陆只对比 MD5

[xzeus]

防君子不防小人

[dhb233]

密码前端加密，就是为了保护用户的明文密码的，服务端也不应该知道用户密码的明文。每个网站 md5 加盐不一样，就能生成不一样的密码，这样用户多网站使用相同密码，安全风险相对较小。

你要是说某个垃圾网站直接保存了用户的明文密码，被脱裤了，你的网站密码也不安全了，那确实是，这个没办法。前端 MD5 加密也不是用来防止这种问题的。

[sss15]

@eber “你放十万个心，99.9%的企业就算最终入库的密码也不会是不可逆算法保存的。 你但凡别提 md5 都没那么离谱。前端加密也不是脱裤子放屁，两份双向 RSA 就能解决可靠性。99.9%的企业无论什么数据服务端必须能逆向成明文。”
我回复的就是你说的这句话，你核心意思是 99.9%的企业入库密码是可逆的，碰巧我们公司是 0.1%的公司，我们的密码不可逆，还加了盐，真是该死

[lonenol]

大概就相当于你把钥匙插在门上，然后锁门和不锁门的区别吧

[llsquaer]

对于高手来说，前端加不加密都一样。。但是对于我来说，太感谢你了。明明白白的写出来，不弯弯绕绕。

[liuidetmks]

@jhdxr 即使服务器被黑，也不应该暴露用户的密码明文，密码可能不止用于你一个地方

[Huelse]

按照安全标准，前端的确是安全水桶中最短的一个，而且 https 只是防御中间攻击者不能保护客户端。

所以从这个角度出发前端加密也是保护客户端，可以认为浏览器所运行的系统环境是不安全的，各种恶意软件可以读取浏览器的明文信息等。

另外客户信息数据库无论如何也不该存明文密码或者是 md5 加密的密码，两者都是容易泄露和撞库的。

现在前端加密更多的是保护网站知识产权和用户信息，当你明白这点就理解前端加密的真正意义了。

[eber]

@sss15 哦哦，这个呀。确实很多大厂的入库密码都是可逆的，越是大厂越是留心眼。。。。。。只要加密的细节不被内鬼泄漏出去即使脱库问题也不大。

[userKamtao]

@lichao 目的就是泄漏密文也比原始密码强，防止撞库，保护用户隐私。

[ZhiyuanLin]

与其研究用户密码怎么保存安全，你不如直接弄成 Passkey ，无密码最安全了。

[cheng6563]

有用但不多，比如 HTTPS 是上了一堵墙挡人，前段加密是丢了块砖把人绊倒。

[xuanqb]

@lisongeee #50 好家伙，看这链接有点眼熟，原来是 gkd 作者

[cnoder]

@shenjinpeng #206 是的。我们 tm 敏感信息传输都要求加密

[tutuge]

这居然还需要讨论，不管有没有 HTTPS ，对于用户密码的“非明文传输”、“加盐、哈希、加签”不都是必须的么 =。=

[lovelylain]

前端 RSA 公钥加密后传输，后端解密，至于原因，一是避免日志等不可控环节记录密码明文，二是防止中间人攻击，三是实现完全没难度但可以堵某些人的嘴。

[lichao]

@tutuge 你规定的必须的吗？我刚才试了一下 accounts.google.com ，向后端传密码的时候就是明文

[qeqv]

@userKamtao @kneo 首先摘要算法不止 md5 ，还有很多别的，但是前端用摘要算出来送到后端没有意义。

[mww]

我如果能拿到传输过程中的 md5 ，我就能伪造登陆直接拿 token ，token 我都有了，哪还在乎你真的是什么密码

[qeqv]

@dhb233 明文 https 传到后端，后端摘要加盐入库不也一样么。前端做没有意义。除非登陆程序不是第一个收到这个密码的

[loolac]

传个空字符串 md5 值咋样？

[GuLuDaDuiZhang]

我接触的某安全产品是用 md5+盐 保存密码，可能就是为了防止数据库泄露数据去撞其它产品吧，不过 md5 只在前端做，后端都没校验密码，感觉只是为了应付等保合规随便做做。

[userKamtao]

@mww 多做一步，成本也不高，泄漏密文也比原始密码强，用户 v2 的密码，有可能也是其他平台的密码。

[Ritr]

@eber 模拟操作效率还是不高，而且有行为检测

[LeeReamond]

本帖足见前端程序员水平之低，令人感慨。估计大多数人的脑回路概括就是：
1.tls 如果足够牛逼，我就不用再学了。
2.tls 确实足够牛逼，所以我不用学网安内容了

[rioshikelong121]

把明文传输到后端的目的是什么？密码不应该以明文形式在后端进行存储。
我觉得在前端 MD5 是可行的，但是目的并不是(仅仅)为了加密，而是为了后续存储 / Log 等环节的安全性。

[lslqtz]

想起来那个笑话, 最好把验证用户密码是否正确也放到前端.
我就问几点: 在前端做所谓的加密怎么让用户无法绕过密码规则验证? 怎么防止用户的无效构造数据? 通过 RSA 在 HTTPS 的基础上对数据进行**重复**验证对性能的影响和意义?

[userKamtao]

@LeeReamond 其实感觉回帖的也有很多后端，可能他们接触的产品都是明文传输，认为 https 足够安全，可以保证在后端加密入库之前，不会泄漏出去，而且前端加密就三五行代码，花不到几分钟。

[codespots]

@horizon #212 是的，昨天回复还没满一页的时候，我就说 OP 根本就不懂明文存储和明文传输的区别，而且貌似 OP 根本不知道服务器不可以明文存储这个规则。而且 OP 对摘要算法加密算法误解很深

[LeeReamond]

@userKamtao 你的贴写的也有问题，很多人攻击你搞不清摘要和加密，你标题写摘要估计问题就会明确很多。因为重点很简单，概括起来就是确实没必要维护个私有的加密解密如何如何的协议，但是确实有必要不以明文发送所有涉密内容。

[wxw752]

如果 md5 之后再传，那后端拿不到用户原始表单输入的值，这本身就是不对的。

[dogfood]

原则上不应该在任何地方出现用户 明文密码 必须都做处理后 传输 储存
只要有明文密码就有可能泄露 拿来撞库 密码通杀 这种例子太多了

[lichao]

如果你的 https 是可靠的，那么传输过程中本身就是加密的

如果你的 https 已经被攻破了，那么完全可以给你伪造一个登录页面，你前端简单做个 MD5 解决了哪门子问题？

[yanw]

不要让前端决定后端如何存储，让前端传递原始信息（原密码，后端负责加密）

[xlcheer]

大体上来说，有 https 了不需要前端加密了。不过浏览器插件似乎是可以截获请求数据的。

[userKamtao]

@codespots 有点羞愧经验太少，知识面很单薄，所以在加密方面了解真的比较少，但我肯定知道在服务区不能明文存储，我的意思是在 后端加密存储 之前就一定能保证明文密码不被泄漏吗？

[codespots]

到现在为止，OP 都没分清明文传输和明文存储的区别，从 OP 的回复可知，他以为的密码存储和校验过程是，前端传密码，服务器拿数据库密码做===判断。但是事实上的密码存储和校验过程是，注册时前端提交密码明文，后端用专门的加密算法处理后得到密文，然后存储密文到数据库。登录的时候前端提交密码明文，服务器获取明文后，用注册时所用加密算法的的校验方法校验明文经过校验后的结果和之前存储的密文是否匹配（这里的匹配不是等于，而是专用的校验方式）。


以 PHP 为例，注册时，前端提交明文密码 12345 ，服务器接收到明文密码后，对 12345 使用 passoword_hash('12345',PASSWORD_DEFAULT) ，得到一个 hash 值为 $2y$10$zK8Lz9kfnN40nZQ1hzaLteJLA88dPgBLhQGocmGazjhZwaCo5S/OG ，然后存储 hash 值到数据库中。然后用户登录时，提交明文密码 12345 ，服务器接收后，使用专用校验方法 password_verify('12345','$2y$10$zK8Lz9kfnN40nZQ1hzaLteJLA88dPgBLhQGocmGazjhZwaCo5S/OG') 得到校验结果 true/false 。以上过程，只有在传输时是明文的，在服务器上存的和校验的永远是密文。而且每一次 hash 值都是不一样的。

OP 还差得远呢，附上 PHP 的代码示例


<?php
// 前端提交的密码
$password='12345';

// 后端存储的密文，每一次运行的结果都不一样
$hash=password_hash($password,PASSWORD_DEFAULT);

print($hash);
print PHP_EOL;

// 使用专用密码校验方法验证
$match=password_verify($password,$hash);
// 输出验证结果
print($match);

[LaoDahVong]

@horizon 我的意思前端加密等于是告知用户密码不会明文储存, 从没说过明文传输等于明文储存 -- 这是一个用户和服务供应商相互信任的问题.
但是前端如果得到了妥善的加密, 就不需要用户和服务商互相信任这一环了. 我不用担心我的密码不会被妥善保存.

[userKamtao]

@codespots 我不管后端用什么方式加密，我就想问，前端入参之后，后端拿到明文密码这个过程，有没有可能泄漏？

[codespots]

@userKamtao 以你担心的多平台密码泄露这个事情举例，最出名的莫过于 CSDN 了，当年闹得沸沸扬扬的，但泄露是因为注册和登录过程中使用了明文密码吗？错！大错特错！泄露是因为 CSDN 在存储时存的是明文。传的是明文和存的是明文是完全不同的两个概念！

[ryanlid]

可以但没必要，应用层 TLS 帮你都做好，为什么不直接用？

按你担心的，前端还做一下数据包重传，检测一下，万一用户发送的数据，后端没收到，重传一次，还要校验一下数据的完整性。。。

[LaoDahVong]

@codespots 如果前端用户看得到加密, 还需要担心后端服务器不负责任的储存密码嘛?
我觉得这是一个增加用户信任的 feature 而不是一个纯粹的安全性上的 feature.
当然, 的确也是比较鸡肋的 feature. 大厂没必要, 小厂我觉得大多数人也不会去扣前端代码, 担心明文储存会去看源码的人本身也不会用非随机密码.

[caiqichang]

微软 谷歌 苹果 好像都没加密吧？

[userKamtao]

@ryanlid
@codespots
明文抵达后端，一个项目什么人都有，阴暗和邪恶的人加密前做手脚，这不是没有可能。

[rahuahua]

@V2April 只是你的密码的 md5 被泄漏了，你的密码没泄漏，像我很多平台同密码的。
==========
@userKamtao 如果所有的网站跟你一样做，不一样等于泄露了么 o(╯□╰)o 那如果其他网站跟你不一样，那你要好好考虑下别人为什么不这么做

[userKamtao]

@rahuahua 加盐呀，每个网站加盐又不一样。

[codespots]

算了，你在不断添加预设条件来证明自己的观点。我不和你争论了，我的个人结论放在这，“脱裤子放屁，有时候可以防止放屁崩出屎来，对于你来说有优点有必要性，但对于绝大多数普通人来说，放屁没有必要脱裤子”

[eber]

这破逼帖子还没终结？有啥好争论的？感觉 OP 不光是能力有问题，这也太钻牛角尖了。站在厂商的角度，除了金融类产品会提供双向认证和数据加密来确保前端到后端的传输问题，其他产品为什么要保证你浏览器端的安全问题？说白了你 TM 电脑都给别人看了，这和你直接把密码给别人有啥区别？普通产品我管你电脑有没有病毒？管你键盘有没有被监听？管你网络有没有被监听？脑子有病吧？吃饱撑的？ 我只管好你 TM 浏览器端传给我服务端 我服务端加密入库就行了。你自己网络环境 电脑安全问题是你自己的事情。谁给你兜底？ 这个反诈一样，反诈做成现在这个样子 还 TM 有人被骗，你自己听骗子的话给打钱 清醒过来还怪反诈警察咋没住你家里？

再最后啰嗦一遍 前端加密在能不能被破解的层面不算脱裤子放屁，参考金融场景。其他业务场景 厂商没必要管你电脑上的事情，你 TM 因为自己上网环境或电脑病毒问题密码泄漏关厂商屁事？又不是从厂商服务端那里泄漏的。

一个破逼话题能讨论三页我也是服了，菜就虚心学习别 TM 老顶嘴！！！

[vipfts]

用户的错, 用户就不应该一码平川, 密码泄漏也是活该

[akatale]

这是人我吃，怎么可能传明文到服务器，肯定是前端在本地离线直接不可逆的转密文再传后端，你服务端要明文干什么？有不少人多平台明文密码都是一样的，这是倒逼用户自己手动哈希密码么

[dhb233]

@qeqv 后端计算 MD5 再入库稍微有点差别啊，中间这段链路都有可能获取到明文，只能防止被脱裤的情况下，拿不到明文。比如你的接入服务打印了全部的日志，那日志也可能会泄露明文密码。或者服务器被黑了，那也可以在服务器拿到明文密码了。不是所有环节都有数据库那么高的安全措施的。

前端能做 MD5 是最好的，如果觉得太复杂，后端做 MD5 也比明文存储好；就算明文存储，也不影响用户登录，使用你的服务啊

[dhb233]

我觉得那些说没有意义的人，其实就是没多少安全意识，而且没有为用户去考虑。以一种又不是不能用的心态来对待这个事情。
如果脱裤的问题没暴露，他们一样觉得明文存数据库没问题，数据库不是有密码才能访问吗，为什么我还有给数据库里的内容加密？

[userKamtao]

@eber 我失去虚心，是因为你一开始就阴阳怪气的攻击，让我非常不舒服，感觉自己很牛逼，其实最不虚心的就是这种人，对技术没有敬畏之心，认为 https 安全就可以什么都不做，而且探讨话题的时候，不断对别人进行攻击，这就是你的乐趣。即便你技术再好，但其实你这种人，现实中应该非常难相处，绝对的。

其实自认为自己达到了至高境界，认为自己理解的就是对的，殊不知其实很多企业都是将密码不可逆（ md5+加盐）加密到后端的，你就骂吧，但你绝对是一个极其骄傲的人，你只是活在自己的世界里面。本身我所说的前端加密的意义不是考虑本地安全，而是防止传输或者后端人员参差不齐，导致加密入库之前泄漏，你自己一直在说本地上网环境、电脑安全的角度，所以你自己一直按照你自己理解别人那样来贬低别人？

[thinkershare]

没啥意义。
1. 后端需要原始的密码来保证一些安全策略的实施。
2. 后端程序中预防程序员植入或者无意记录密码明文是 review 和审计的责任。
3. 使用任何 HASH 算法都会导致密码强度的下降(因为密文的信息熵下降了)
4. 你不应该在不同的网站使用同一个密码，这是你自己作为用户的责任。

[ciki]

很有必要，毕竟明文包含了很多敏感信息，可能包括姓名，生日等等，不管 md5 还是 hash ，都能避免明文泄漏，服务器加密那是服务器的事情，传输过程别明文就行

[ciki]

@zsdroid #208 这种无所谓啊，问题是你明文密码可能包含用户敏感信息(生日等)，md5 至少是一串无意义的字符串，你也看不出用户的其他敏感信息

[vsomeone]

OP 确实有点表面虚心学习，实际非常傲慢的感觉。HTTPS 一般情况下都能保证传输安全，真的要有中间人攻击的话通常也得在 victim 的设备上安装一个根证书并使其信任该证书，这种攻击一般都得靠社会工程学的方式去做，否则如果取得了 victim 设备的控制权，直接监听就好了，不需要整这么复杂。在这种前提下，只有少数对安全性要求高的应用程序有在前端加密表单数据的必要。到了服务器端之后的泄露，最有可能的就是开发者在日志里把密码明文 log 出来，然后日志的访问接口被意外公开，但是这个问题对于有 code review 规程的公司来说不太可能会发生。总之这就是一个做和不做都没啥太大坏处的事情。

[userKamtao]

@vsomeone
我其实很欣赏你这种平和的回复，我很开心，但对于那种阴阳怪气的回复我真的顶不住，所以我表现得比较傲慢，抱歉☹️。

其实是想知道更多为什么不加密的理由，而不是冷嘲热讽讨论我技术不行，说我多此一举，如果不能给予实际上的理由，何必要阴阳怪气回复呢。

[freezebreze]

你无敌了孩子，赶紧把这个站所有和你争论的号都盗了吧，我 F12 看了 V2 的登录也是传的明文

[qwong]

[網站前端打 API 時把密碼加密，有意義嗎？]( https://blog.huli.tw/2023/01/10/security-of-encrypt-or-hash-password-in-client-side/)

分享一下这篇文章，里面讲的很清楚了。

顺便摘录一下作者的观点：
1. 在 client 端传送密码前先把密码加密或是 hash ，确实能够增加安全性。
因为：
- HTTPS 因为各种原因失效时，攻击者无法取得明文密码
- 在 Server 端，没有任何人知道使用者的明文密码
- 明文密码不会因为人为失误被记录到 log 中

2. 以技术上来说，就算理论上一定会被破解，这些机制还是有意义的，它的意义在于增加破解难度，加壳、混淆都是一样的，不会因为「在 client 端的东西一定会被看穿」而不去做这些机制。

3. 重点在于你想保护的商业逻辑的价值，有没有高到你需要付出这些成本去做额外的安全机制

[icy37785]

@dhb233 #257 如果你认为说没意义的人是没有安全意识，那只能证明你的不技术不过关了。
如果你举例里不是前端 md5 一下的话，我顶多说一句没意义，但是你举例里是 md5 ，那就不是单纯的没意义了，把不定长的密码转化成了定长的 hash ，这是会降低安全性的。
现在就是死而不学的民科多了，才会让楼主这种帖子成月经贴，底下甚至有人支持。

[LaoDahVong]

的确很多回复比较阴阳怪气, 好像这几乎是'没必要讨论的问题'.

我倒是觉得问题提的很不错. 忽略一些新手的错误,摘要一下值得讨论的是:
1. 前端加密是否更加安全. 这里的安全包括了 zero-trust 的概念, OPSEC 的准则, 以及很多人提到的, 是否会在其他阶段如 log 阶段泄露明文密码等. 这绝对不是没必要讨论的事情.
2. 如果前端加密更安全, 怎么做更安全? 会遇到什么问题? 如很多人提到的要加盐,还有人提到的'如何防止用户构造数据', 性能上和 portability 上会有什么影响. md5 不是加密,但是否 good enough?
这些都是更加值得讨论的.

md5 是摘要不是加密这是很多初学者会忽视的问题, 知乎上有很多类似案例.
很多人没必要抓着这个点就嘲笑 op,谁刚学没犯过一点错误.
甚至拿什么 V2 也明文或者贴上 hellworld 级别的代码告诉 op 后端会加密存储,就觉得讨论终结了...这种 arrogant 很难让人忍受, 真以为大家都是草台班子?

[dswyzx]

涉及密码的除了登录和修改密码,其他接口现在都是鉴权是否登录吧.即使有人说的别人用你的电脑打开 f12,那除非你自己在登录前就开了 f12 传了明文还不清理历史,然后等着别人去 f12 里翻 login 接口.这个场景如果还能发生,我觉得该毁灭就毁灭了.不值得
另外:合规这个事情,规矩都是人定的.日志里重要数据打码,前后端不对称加密.都是要多余操作的.没有紧逼当然是怎么省事怎么来了.
技术不仅仅是 crud helloworld

[fkdog]

github 和微软是直接明文传密码的。
但是也有不少公司是加密一道再传的。

不过有一点，
但凡有人把 md5 和加密放一起的，绝对是个大菜逼，半桶水晃的响的那种。

[shadowyue]

我知道谷歌页面登录密码就是明文传输的，有 https 还加密一层感觉更多是心理安慰

[horizon]

@dhb233 #267
如果一个网站用一个密码，明文存数据库确实没问题。
连数据库都被攻破了，我还在乎我在这个网站的密码吗？

[TeresaPanda]

合规信任问题，用户明文口令不应离开浏览器，更不应该送到后端。
https 只能保证传输过程安全，但如果企业有内鬼，或者被黑，是有能力在服务器上直接窃取客户明文口令的。
特别是考虑到口令经常在不同站点复用，这就会严重侵害用户利益。

哈希后传输可以大幅度降低这个风险，拿到哈希值，碰撞出原文没那么容易。

[dhb233]

@horizon #281 对啊，我的数据库都被攻破了。我为什么还要关心用户的密码？密码公布于众又怎样？这又不是我的错，是那些黑客太不道德没底线了

[dhb233]

@icy37785 #276 你觉得 MD5 不安全，把秘钥变短了，是不安全的，那不用 MD5 做哈希就更安全？觉得 MD5 降低安全性，你可以给出其他安全的方式，而不是说这个没用。

并且 MD5 是 16 字节，密码不超过 16 个字符的情况下，不会降低安全性。密码长度超过 16 字节之后，又有多少安全性的差异？难道还要争论下 100 字节比 16 字节更难爆破？

[tt0411]

从 security 角度看, 有 https 的话单纯加密确实没啥意义;
从 data safety 角度看, 直接传 passwd 这种敏感信息可能是不合规的, 因为这意味着密码这样的用户隐私数据"很容易"被内部人员读取;

[huadi]

完全没用

服务器要用 username 和 credential （不管这个 credential 是明文密码还是 md5 之后的）来验证用户身份。
前端做出花，算法也等于公开的。最终我只要通过网络请求拿到 credential 就好了。你用 md5 加密，我就拿 md5 之后的结果作为“明文密码”，不是一样吗？
至于 https 拿不到 credential ，那你用明文又有啥问题？

[worldqiuzhi]

说没意义的是没经历过十年前的互联网莽荒时代，拿一个免费社工库 可以把百度贴吧 排行榜前 1000 人登录上去一半

[xiangyuecn]

github 微软 谷歌 苹果，如果你能做到和他们一样的安全等级，那确实没必要

如果有人认为以上公司，会把登录相关的敏感 api 和普通 api 混到一起，那就是怎么安全都白搭

就不怕招到我这种半桶水的，上来就一个 log 把你所有请求信息存到文本文件里面，另外我还打印 sql 日志，就问你怕不怕😂

[google2020]

@xiangyuecn 真实，总有人把一流企业标准流程当圣经，也不看看自己的草台班子能做到什么水平。说得好听防黑客，说难听其实就是防呆，防自己人犯错，防有关部门的流量审计。🤣

[nuII]

大网站那是因为有 2FA ，很多都疯狂要求你开启了。前端加密对大部份人没有意义，因为可以避免的攻击场景大部份人遇不到，比如针对性攻击，对外的公共网站做这个是有用但是没收益。

[wszzh]

注册的时候，为了安全，密码都会要你包含特殊字符，数字，字母，大小写等。如果前端计算 MD5 再给后台，后台是无法校验你的密码是否符合安全规范的。

[wentx]

@userKamtao #8 前端做了 md5, 后端拿到的是 md5 ， 能根据 md5 把用户的密码算出来？

[oshio]

前端加盐 hash 可以防止我司内鬼获取用户名密码，然后登录其他公司服务器，但无法阻止内鬼访问我司服务器。
但如果别人不加这个，其他公司的内鬼是可以获取用户名密码登录我司服务器的。
既防不了我司内鬼，也防不了其他公司内鬼，只能防我司内鬼攻击别人的服务器，完全是雷锋啊。。。

[unco020511]

@nomagick #13 可以给出 google 的具体场景吗,我想去看看

[userKamtao]

@unco020511
accounts.google.com
哈哈，去试试

[unco020511]

首先还是忍不住想要纠正一下 MD5 不是加密算法,加密算法是有定义的,最大的特点就是可以复原(解密),参见维基百科关于加密的定义:https://zh.wikipedia.org/wiki/%E5%8A%A0%E5%AF%86

回答 op 的问题:
我觉得是有一些意义的,在大型软件中,你的数据可能会经过 N 多个服务,每个服务都有自己的逻辑,虽然最终你的用户服务去存储时一定会用摘要存储落库,但中间的那些服务也是有可能明文打印或者输出的可能,所以最开始就从源头摘要一下,是有一些意义的.

还有很多所谓的安全扫描工具,如果你直接在 https 中传输原始密码,他们也可能会认定为你的接口存在安全隐患,虽然你明确的知道 https 已经帮我们加密了,但也要耗费精力去跟你的领导解释,既然如此,不如一开始就在前端把密码摘要/hash 处理一下

[unco020511]

@userKamtao #295 确实是,github 也是

[wanguorui123]

你能保证你所有环节脱敏的话，当然可以不加密，其次是 md5 不是加密而且需要配合盐做数据脱敏。

[zhywang]

讨论安全都是在一定的前提下的，一般的前提假设是：
1. 客户端安全：如果客户端安装了乱七八糟的插件、脚本，能获取网页数据，安全无从谈起
2. 传输通道安全：证书、根证书等都需要可信，否则安全无从谈起
3. 后端安全：后端采用各种方式确保敏感信息不被非授权获取，例如禁止将敏感信息明文以任何方式序列化出来
这三点是安全的充分必要条件，只要做到了就安全，如果做不到，不管前端加密多少次，都谈不上安全

[dcdlove]

@eber #108 很好奇那多前端不知道使用非对称加密吗？非对称加密 256(md5 （字符串+私盐）)