问个前端公钥加密防止中间人攻击的问题

[FreeWong]

Baidu 的登录页在用户登录前使用了公钥对用户的密钥进行了加密 然后再到服务端进行密码正确的判断 其中登录页本身使用了 https 我的问题是，这样的做法可以在即便中间人攻击的情况下也无法得到明文的密码 但是，如果中间人截获了这个公钥加密后的文本，中间人即使不能看到明文密码，但是中间人一样可以把这个截获的文本向 Baidu 的服务器提交，中间人一样可以正常登录

所以从这个角度来看 似乎不是特别有意义啊 我的理解对吗，多谢多谢

[301]

就算能登录，传回来的数据中间人也没法解密吧

[jybox]

因为响应也是加密的，中间人只能把请求转交过去而看不到响应的内容；同时因为 https 握手的时候会有随机数来避免重放攻击，所以中间人也只能转交一次，或者不转交。

[unixeno]

防中间人还是得靠 https
这种前端的加密可能增大爬虫难度的作用更大一些

[jim9606]

在防 MITM 这个问题上，JS 自己造轮子不可能比 HTTPS 完备。
靠谱的做法是使用一次性 key 的 HMAC，这个可以防止重放。

[imjamespond]

https 可以验证证书指纹的合法性, 普通公钥指纹不能验证

[superrichman]

比如我知道你的百度账号的明文密码，那你的 qq，微信或者其它密码可能会和这个密码有关。万一如果全一样，等于所有账号都被盗。
这道加密就是保护明文用的。

[crab]

你说的这个也不能防止中间人

[jadec0der]

分情况吧，如果中间人没有针对 baidu 的话，这种方式可以保护密码不被中间人记录，但是如果针对 baidu 的话，中间人完全可以替换成自己的公钥，再做一次解密-加密的操作，密码还是暴露了。

表面上看这样可以进行进一步的防护，多保护一部分用户，但是我觉得从系统设计上看有一个 Web 系统的安全的边界在哪里的问题，在 SSL 里面再套一层自定义的加密好像更安全了，甚至还可以在客户端再做一次自定义的公钥验证，这样下去哪里是个头？我个人认为这样过度了，不够优雅。

[FreeWong]

@301 根据我的理解 ，是可以解密 的，因为公钥是公开的

[FreeWong]

@unixeno 感谢回复，是在 https 的基础上再使用公钥

[FreeWong]

@jim9606 感谢回复 哥们你可能没有仔细 看 是在 https 的基础上再使用公钥加密

[yaphets666]

如果中间人 获取到了 客户端的证书 和 服务端的证书呢?

[geelaw]

如果百度做的只是普通公钥加密则无意义，因为 HTTPS 已经实现了客户端和服务器的安全信道。

[lovecy]

@jadec0der 你说的和楼主想问的好像没啥关系。另外如果用户没有安装奇怪的证书，密码不可能暴露吧，除非中间人获取百度的解密秘钥。

[qinxi]

前端加密是为了防止 cdn/日志系统等阶段 获取到明文数据

[lovecy]

外部网络传输，在 HTTPS 基础上做这个，确实没有意义。
我猜是防内鬼？比如所有产品共用账号，账号是一个独立的系统管理，产品服务器获取到密码后（公钥加密的密码），与账号系统连接，由账号系统解密并验证。防止产品服务器获取明文密码

[gefranks]

在 SSL 环境中再次实现一次公钥的加密我觉得没啥意义,在存在中间人的情况下, 再次发过来的密钥我都可以替换掉,然后返回的结果我解密再转发就可以了

[yuningWang8]

我的理解：如果只看传输过程，加密确实没有意义。但是如果考虑数据到达服务端内部流转过程，这种加密还是有意义的。毕竟用户名密码一类的，在各种服务器之间明文传输，还是不太好的。

[kop1989]

中间人攻击，只有 https 能解。
前端的任何加密都是单向加密，即明文》密文。只是让 hack 的复杂度增加。
web 前端不可信原则，在当前的 html 标准下（ html+js+css ）永远存在。

[sujin190]

虽然可以，但是加盐加防重放 token 加时间过期可以防止大部分，只要保证虽然你通过中间人获取到了，但是在很短时间就失效了，基本你拿来也没啥用，相对来说还是毕竟安全的