HTTPS 用明文传输密码的问题的引申——前端能不能做到比较完美的加密

[Torpedo]

最近密码用不用明文传到后端的问题很火。前端不加密的很重要一个点是加密太容易暴露。因为 js 可以被用户比较轻易的看到，造成加密算法的泄露。

不过开发过程中，还是有些加密需求的。比如防爬虫之类的。像客户端一般都是携带参数算出的 token 。而前端因为上述原因，很少采用类似的方案

其实客户端也不是没法破解，只不过成本比较高。web 上我见过的接口，谷歌地图的接口也是加密过的。

大家实践里有什么破译成本比较高的方案呢？

[CloudMx]

@BeautifulSoap 而且你这主要是考虑登录问题，我这边的角度是不想后端知道我的明文密码。
还有你说的 100 次，其实有啊，pbkdf2Hmac 这种。攻击者要想跑字典得花更多的时间。

[BeautifulSoap]

@CloudMx 等等，你怎么偷偷改了话题？ 话题怎么从防止密码原文入库变成了「这个网站它如果是是恶意的，它就是要想办法搞到我的密码原文去作恶该怎么办」了？ 前者是纯技术话题，而你 19L 的这个话题则并不是技术话题，而是变成了网站内部有恶意第三者搞破坏我该怎么办了。

假设一个网站隐含有主观恶意，它就是要搞到你的密码明文作恶，那么为什么你会觉得这个网站的前端就是安全的？哪怕这个网站的前端登录时把你的 password hash 一下，给了你一种虚假的安全感，它也有一万种方法再变相把你的密码原文发送给服务器。甚至后端想作恶了它都不用动你前端，直接拿你令牌就是了。对于一个有恶意的网站期望密码 hash 就能保护自己的密码原文本来就有点奇怪。这种时候你还不如一个网站一个随机密码实在。这相当你“人肉做了 hash”

[CloudMx]

@BeautifulSoap 没有，我就是一直在说的是“我不同意 HASH 后传输是脱裤子放屁”。

如果要说 HASH 跟不 HASH ，对于后端登录来说，它本来就是没有什么两样，它只是去验证是否一致。其他人获取了如果没有添加 nonce 的，重放肯定是可以正常登录的。

你如果都说有主观恶意了，它其实什么都是不安全的了，你总得在前端输入你的明文密码，就像你说的，这里你如果不关注就算 websocket 发送出去你也不知道。

我的论点就是，在其它都不关注的情况下，HASH 后的密码值传输到后端，比加密到后端更合适，所以我说“我不同意 HASH 后传输是脱裤子放屁”。

HASH 传到后端的目标就是一个，从浏览器传输出去后，就没人能够拿到明文信息。

[connectError]

@BeautifulSoap #22 逻辑清晰啊老哥，我就发现有的人讨论讨论着就，整个话题熵增后，都偏离了主旨了。

[ebushicao]

前端加密有意义，但 Hash 传输没意义。前端加密可以增加破解难度，肯定是更安全一些的，最起码也需要花时间搞清楚前端的加密算法。而 Hash 毫无意义，首先，肯定是不可能直接把前端 Hash 的入库的，这比明文还要危险。那前端 Hash 就相当于把 Hash 值作为密码，本质上和明文密码是一样的，反而还多一个 Hash 处理浪费算力。加密举个简单例子就是比如以时间维度来将密码加密，在不同时间维度内加密出的结果是不同的，后端根据对应算法解密出实际密码。这样就算多了一层保护，安全性或多或少提升了一些。当然，因为前端的代码都在浏览器，即便有压缩和混淆，搞清楚具体算法也只是时间问题。

[jhdxr]

tl;dr 用 https 足矣，非要改进建议放弃密码直接 passless

密码明文入库、日志里明文暴露等在我看来都是借口，CSDN 密码泄露都过去 13 年了，如果还犯这种低级错误，你和你的领导至少有一个人不适合在这个行业干。

那仅仅考虑传输安全呢？
先说加密，对称加密不安全，毕竟不管是 js 里写死（那攻击者直接能看到）还是从服务器端获取/协商（那这个请求的传输安全如何保证）都不行。非对称加密理论上是可以的，但如果你完整地实现一遍，你可能会发现——你重新写了一遍 https 。那凭啥你自己写的 https 就比自带的安全了？

再说哈希。首先我必须打醒某些觉得哈希了再传更安全的人。对于后端来说，你传的是明文密码还是哈希后的密码，都只是一个字符串，对攻击者来说也是如此。抓到请求我拿抓到的值去用就行（重放攻击），密码明文还是哈希，有区别吗？至于那些我被黑了没事，用户密码坚决不能泄露的，你可听说过彩虹表？就算加盐了，弱密码字典+盐跑一遍现在也没啥成本。那就变成要用户变态密码或者一站一密了，不如直接 passless

[BeautifulSoap]

@CloudMx 一个网站的前端后端不是割裂的，不知道为什么你会如此不自觉地将前端和后端如此割裂地来看待，一个网站往往是同一个公司的人写的，有的网站前端后端写代码的甚至是同一个批人或同一个人。可能你用的网站的前端就坐后端边上，两人还天天中午出去吃饭聊天打哈哈。我说这么多只是想提醒一下，一个网站的前后端往往联系是非常紧密的。对于一个整体的网站，当出现内部恶意第三者的时候，你要考虑的就不光只是密码这种微不足道的东西了。

再次整理一下，你完全不信任一个网站后端觉得网站后端就是有恶意的可能想搞到你密码，但同时你又很奇怪地完全信任这个网站的前端，认为这个不安全的网站的前端是完全的好人把你的密码 hash 一下之后你的密码就安全了。所以你认为前端 hash 一下等同于从后端那保护了你原始的密码原文，对不

但我的看法是，是的 hash 一下你说完全没用那是假的，但我上面也说了很多了，前端 hash 这件事本身就没多少用处

[CloudMx]

@BeautifulSoap 前端后端同一个写的，在我遇到的情况现在很少，很多不是全栈，他们都是对自己方便用什么方式。

你如果想说的是安全是一个整体，我肯定是赞同的。

为什么说到前端信任这个问题，因为你说前端也是不安全的那真就没有解法了，你总得输入明文密码，也就不需要说 HASH 再传输到后端了，你无论咋处理，明文就是可以前端拿得到。

我也同意你说的没有多少用处，上面我就说过了，它的用处就是出了浏览器传输开始到后端，没人能知道明文信息了。

[idealhs]

笑看一堆觉得需要处理的，看来大家普遍水平还是不够高，这行还能再多混几年

[cslive]

前端加密脱裤子放屁

[tanranran]

参考银行 密码登录加密

[imnpc]

https 的意义是不是很多人都不愿意去了解？那么多大牛花了这么长时间建立的安全保障 居然都无视了？

[luxor]

如果不考虑中间人，https 足够了。如果存在中间人劫持，那么前端的代码可以任意修改，在加密前获取数据即可，因此#30 说得没错。

[rimutuyuan]

前端 hash 只有一个意义，防止被中间人攻击者拿着密码明文登录其他网站，对于自己网站安全性没有任何提高

[rimutuyuan]

但通过劫持 js ，仍有方式获得密码原文，总结，脱裤子放屁

[hzcer]

https://en.m.wikipedia.org/wiki/Zero-knowledge_password_proof

[ZE3kr]

比较完美的加密当然有啊，比如 TOTP 就是其中一种。更完美的前端加密还有 Passkey 。这些都是客户端参与计算，生成加密后的信息而非密码本身，并且有大量应用，非常成熟的技术。

其他的简单的前端加密都是不完善的，比如简单的 hash 不能解决重放

（ note：我说的加密是广义的，包含 Cryptographic hash function ，所以 hash 也是加密的一种）

[razertory]

只要让每一个请求，都让用户手动做一个 2FA 验证就行了

[terence4444]

前端 hash 用户密码是对用户负责的表现，并不是说因为用了 HTTPS 就可以明文传输用户密码了。

认为这样做“脱裤子放屁”的，在安全编程方面还是有所欠缺。

[lisongeee]

如果前端 hash 密码，那后端怎么校验密码是否匹配大小写字母特殊字符 8-16 位？

如果前端 hash 密码，那一但上线，岂不是这个 hash 规则到死都无法改变，因为一旦后期前端变更 hash 算法，之前的用户密码 hash 不对应则无法登录