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

[Torpedo]

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

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

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

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

[lisongeee]

思考了一下，hash 算法确实是一开始定死的，请忽略我上一条评论的下半部分

[ShuWei]

你连加密、哈希、混淆都没有搞清楚

[zlowly]

前面说 Hash 传输没意义，这只是从单一系统角度视角考虑的结果。
要知道现在没有系统会保持明文密码，是因为用户密码的泄露，不但对本系统有风险，更是对用户使用的其它系统都照成风险，因为很多人是多个系统登录注册都用同一个密码的。
同理，将用户密码明文传输，就会出现通信链路中通过中间人攻击可能获取到这个密码，给攻击者有机会利用这个密码试探将用户所有可能使用的系统，扩大了用户损失。

[busier]

@CloudMx 防中间人那是传输层的事情，SSL/TLS 做好就可以了。别指着前端搞全家桶什么都考虑进去。

前端加密无非就是防止客户端调试类工具查看传输了什么
前端又无法保证密钥和加密算法安全，使用非对称方式再合适不过了。

[chaoschick]

usbkey

[luxor]

@terence4444 @zlowly 为什么很多人认为中间人劫持只能看到明文密码或者密码 hash 的传输呢？密码是怎么输入的？直接劫持网页密码输入不就行了？好好想想 CS 和 BS 的区别吧。中间人是无法修改 CS 的 C 端代码的(漏洞除外)，因此只要通讯协议可以对抗中间人（例如浏览器+HTTPS ），就是安全的。而 BS 的 C 端代码中间人是可以篡改的，再怎么加密混淆都阻止不了窃取数据。

@busier 密码是用户输入的，用户自己还需要用调试工具来查看吗？

[CloudMx]

@busier 防止中间人是 HTTPS 的事情，没问题。

如果在没有中间人攻击的前提下，密码我还是建议 HASH ，理由之前说过。
其他的敏感信息，你可以 RSA 这种非对称，反正现在的机器配置不低，在传输数据量不那么大的情况下，性能没啥问题。

[terence4444]

@luxor 你还在纠结中间人，中间人是一个问题但不是主要问题。
明文密码在系统处理过程中会不知不觉留下痕迹，如果本着对用户负责的思维设计系统的话，就会考虑把用户明文密码在系统里的痕迹减少到最低。

[zlowly]

@luxor 目前的安全防护都趋向于零信任安全的理念，你不能指望只靠通讯协议可以完全对抗中间人，https 虽然对通信内容进行加密，但建立 https 过程仍然有很多步骤是有可能钻漏洞获进行中间人攻击的。当然安全的程度也要考虑成本，但是如果你前端采用 HASH 传输几乎就是 0 成本的，为何不做？万一你这个项目出现信息安全事故，遇到严厉的领导或甲方，你就算再怎么辩解这个用户密码不是从你前端漏出去的，追责时这个偷懒行为都够你喝一壶的。

[forty]

>“前端不加密的很重要一个点是加密太容易暴露”

非对称加密，就是解决这类问题的，加密算法是公开的，不怕你看。具体到网站前端来说，就是后端给前端公钥，前端加密，发给后端，后端解密。也就是 HTTPS 。当然，你的目的是，防止被人从调试器查看你的加密，那就自己再来一层非对称加密，用 JS 代码来调用。