V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
FreeWong
V2EX  ›  问与答

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

  •  
  •   FreeWong · 2020-11-10 11:01:32 +08:00 · 2885 次点击
    这是一个创建于 1503 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    28 条回复    2020-12-26 19:55:31 +08:00
    301
        1
    301  
       2020-11-10 11:33:20 +08:00 via Android
    就算能登录,传回来的数据中间人也没法解密吧
    jybox
        2
    jybox  
       2020-11-10 11:41:50 +08:00
    因为响应也是加密的,中间人只能把请求转交过去而看不到响应的内容;同时因为 https 握手的时候会有随机数来避免重放攻击,所以中间人也只能转交一次,或者不转交。
    unixeno
        3
    unixeno  
       2020-11-10 12:36:09 +08:00 via Android   ❤️ 3
    防中间人还是得靠 https
    这种前端的加密可能增大爬虫难度的作用更大一些
    jim9606
        4
    jim9606  
       2020-11-10 12:42:35 +08:00
    在防 MITM 这个问题上,JS 自己造轮子不可能比 HTTPS 完备。
    靠谱的做法是使用一次性 key 的 HMAC,这个可以防止重放。
    imjamespond
        5
    imjamespond  
       2020-11-10 12:45:29 +08:00
    https 可以验证证书指纹的合法性, 普通公钥指纹不能验证
    superrichman
        6
    superrichman  
       2020-11-10 12:45:34 +08:00 via iPhone
    比如我知道你的百度账号的明文密码,那你的 qq,微信或者其它密码可能会和这个密码有关。万一如果全一样,等于所有账号都被盗。
    这道加密就是保护明文用的。
    crab
        7
    crab  
       2020-11-10 12:49:06 +08:00
    你说的这个也不能防止中间人
    jadec0der
        8
    jadec0der  
       2020-11-10 13:18:12 +08:00
    分情况吧,如果中间人没有针对 baidu 的话,这种方式可以保护密码不被中间人记录,但是如果针对 baidu 的话,中间人完全可以替换成自己的公钥,再做一次解密-加密的操作,密码还是暴露了。

    表面上看这样可以进行进一步的防护,多保护一部分用户,但是我觉得从系统设计上看有一个 Web 系统的安全的边界在哪里的问题,在 SSL 里面再套一层自定义的加密好像更安全了,甚至还可以在客户端再做一次自定义的公钥验证,这样下去哪里是个头?我个人认为这样过度了,不够优雅。
    FreeWong
        9
    FreeWong  
    OP
       2020-11-10 14:28:17 +08:00
    @301 根据我的理解 ,是可以解密 的,因为公钥是公开的
    FreeWong
        10
    FreeWong  
    OP
       2020-11-10 14:33:03 +08:00
    @unixeno 感谢回复,是在 https 的基础上再使用公钥
    FreeWong
        11
    FreeWong  
    OP
       2020-11-10 14:34:22 +08:00
    @jim9606 感谢回复 哥们你可能没有仔细 看 是在 https 的基础上再使用公钥加密
    yaphets666
        12
    yaphets666  
       2020-11-10 14:43:12 +08:00
    如果中间人 获取到了 客户端的证书 和 服务端的证书呢?
    geelaw
        13
    geelaw  
       2020-11-10 14:46:34 +08:00 via iPhone
    如果百度做的只是普通公钥加密则无意义,因为 HTTPS 已经实现了客户端和服务器的安全信道。
    lovecy
        14
    lovecy  
       2020-11-10 14:55:34 +08:00
    @jadec0der 你说的和楼主想问的好像没啥关系。另外如果用户没有安装奇怪的证书,密码不可能暴露吧,除非中间人获取百度的解密秘钥。
    qinxi
        15
    qinxi  
       2020-11-10 14:58:22 +08:00
    前端加密是为了防止 cdn/日志系统等阶段 获取到明文数据
    lovecy
        16
    lovecy  
       2020-11-10 15:04:47 +08:00
    外部网络传输,在 HTTPS 基础上做这个,确实没有意义。
    我猜是防内鬼?比如所有产品共用账号,账号是一个独立的系统管理,产品服务器获取到密码后(公钥加密的密码),与账号系统连接,由账号系统解密并验证。防止产品服务器获取明文密码
    gefranks
        17
    gefranks  
       2020-11-10 15:27:34 +08:00
    在 SSL 环境中再次实现一次公钥的加密我觉得没啥意义,在存在中间人的情况下, 再次发过来的密钥我都可以替换掉,然后返回的结果我解密再转发就可以了
    yuningWang8
        18
    yuningWang8  
       2020-11-10 15:35:05 +08:00
    我的理解:如果只看传输过程,加密确实没有意义。但是如果考虑数据到达服务端内部流转过程,这种加密还是有意义的。毕竟用户名密码一类的,在各种服务器之间明文传输,还是不太好的。
    kop1989
        19
    kop1989  
       2020-11-10 15:51:30 +08:00
    中间人攻击,只有 https 能解。
    前端的任何加密都是单向加密,即明文》密文。只是让 hack 的复杂度增加。
    web 前端不可信原则,在当前的 html 标准下( html+js+css )永远存在。
    sujin190
        20
    sujin190  
       2020-11-10 16:09:32 +08:00
    虽然可以,但是加盐加防重放 token 加时间过期可以防止大部分,只要保证虽然你通过中间人获取到了,但是在很短时间就失效了,基本你拿来也没啥用,相对来说还是毕竟安全的
    jim9606
        21
    jim9606  
       2020-11-10 16:25:22 +08:00
    @FreeWong
    没看漏,HTTPS 和 HMAC 要同时使用。
    因为在浏览器跑的 JS 代码也是从服务器下载的,如果不用 HTTPS 保护的话就存在 JS 代码被篡改的问题,那浏览器那边会发生什么都不奇怪了。
    用 HMAC 的目的是避免 PIN 被还原出来,对于被动 MITM,这个方法可以避免重放攻击,也不用担心 PIN 泄漏。大厂喜欢用 RSA 估计还是为了获得 PIN,我严重怀疑它们是在数据库直接存 PIN 的,这个方式用来防被动 MITM 是足够的。
    firefox12
        22
    firefox12  
       2020-11-10 17:48:47 +08:00
    有 https 再加这个,估计是怕 浏览器其实是被控制的,js 再加一层,那么就又麻烦很多。
    webshe11
        23
    webshe11  
       2020-11-10 17:52:05 +08:00 via Android
    有一种刚学完现代密码学胡搞毛搞的感觉
    jadec0der
        24
    jadec0der  
       2020-11-11 00:00:11 +08:00
    @lovecy 我不知道百度工程师的想法,但是我猜就是想在 HTTPS 上加一层防护。用户安装奇怪的证书是很常见的,至少在公司的电脑上很普遍。
    lovecy
        25
    lovecy  
       2020-11-11 11:05:19 +08:00
    @jadec0der 既然用户都安装了奇怪的证书,那估计也会安装奇怪的插件,直接改你的加密秘钥。
    我觉得主要还是#14#15 这类似的原因
    FreeWong
        26
    FreeWong  
    OP
       2020-11-11 11:56:58 +08:00
    @all 这里的中间人攻击行为我们假设为 颁发假证书 在这个前提下讨论就不会有理解上的差异了
    感谢大家回复,帮我解除心中的困惑
    YouLMAO
        27
    YouLMAO  
       2020-12-26 19:51:21 +08:00 via Android
    @jim9606 不应该用 hmac,就是应该对称加密,hmac 你需要跟进用户名问后端拿盐呢,对称加密后端自己解密即可,再加盐
    FreeWong
        28
    FreeWong  
    OP
       2020-12-26 19:55:31 +08:00
    @YouLMAO 感谢回复,晚点时间再继续 这个话题。。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   964 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 19:15 · PVG 03:15 · LAX 11:15 · JFK 14:15
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.