首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

在没有 https 的情况下,如何确保用户登录安全

  •  
  •   NoKey · 76 天前 · 10240 次点击
    这是一个创建于 76 天前的主题,其中的信息可能已经有所发展或是发生改变。
    考虑了一下这个问题
    目前把这个问题分成两步
    第一,注册
    第二,登陆

    注册这部分,我这里无解,我想不到有效的办法。。。

    登陆这个,有一个办法
    将用户的密码做 md5,然后加上当前的时间戳,再做一次 md5
    伪代码表达:
    md5(md5(passwd)+timestamp)
    返回给服务器的时候,将这个结果和 timestamp 一起返回

    服务器除了常规的字段验证之外,需要验证时间戳,每个时间戳,只能使用一次
    这样应该可以避免使用抓包数据登陆

    各位大佬,有没有更好的办法呢?一起讨论一下吧~~~
    148 回复  |  直到 2019-08-29 02:03:08 +08:00
    1  2  
        101
    type   76 天前 via Android   ♥ 1
    @type 写了一堆,才发现第一步的公钥返回给客户端时,就存在被中间人替换的可能,后面的步骤就没用了。https 是浏览器内置了 CA 根证书
        102
    fuxiaohei   76 天前   ♥ 1
    你可以去找一下支付宝和微信支付当年没有上 https 时候的签名算法,也许是 http 下能做的足够可靠的吧。
        103
    nowgoo   76 天前
    模拟 https,做密钥交换那一步的时候,服务器通过短信发送随机数呢?
        104
    Torpedo   76 天前
    短信验证,第三方登录。
    都知道自己不安全,那还不搞个三方的
        105
    no1xsyzy   76 天前   ♥ 1
    @VensonEEE 直接插 js 录键鼠屏
    都直接知道你密码了还有什么不知道的?
        106
    rookiejin   76 天前
    这还是不安全的,
    https 是在握手的时候把公钥下发,客户端拿着公钥签名了,中间人获取到内容也看不到真实的东西,

    以你的例子来说,其实是不想把密码以明文的方式提交到服务器,
    其实可以做成 rsa 加密一下(跟 https 差不多)

    服务器存私钥,客户端放公钥,

    客户端公钥加密数据,服务器私钥解密数据

    提交的数据如下:


    加密内容:

    password=123465


    加密后:

    {"sign":"xxxxxxxxxxxxxxxxxxx"}


    服务器解出 sign 就行了。
        107
    chennqqi   76 天前
    服务端下发公钥
    客户端用公钥把数据加密
    服务端用私钥解密
    HTTPS 主要是解决传输过程的安全。HTTPS 用非对称加密传递对称加密的密钥。

    自己登录和注册数据比较少可以直接使用非对称加密
    为了防止重放攻击可以在下发数据中加入随机数,要求客户端一起加密上送
        108
    type   76 天前
    @no1xsyzy 是的,只要中间人往返回内容插 JS,记录用户操作,用户的账号密码就泄露了。
    除非全站加密,问题是基于 HTTP 全站加密,浏览器端也解不了密,那用户看到的全是乱码
        109
    chinvo   76 天前 via iPhone
    @fuxiaohei #102 那个靠的是安装控件的时候预置在控件内的 CA 证书
        110
    Livid   V2EX Moderator   76 天前   ♥ 1
    2019 年了,没有任何理由不上 https 了。
        111
    blless   76 天前 via Android
    😃看 v 站讨论登陆业务能否看出 v2 的人均业务水准?感觉像几年前自己没接触任何安全的时候问得问题
        112
    blless   76 天前 via Android
    另外说一句,这两种业务都是最常见且业内有套标准流程的业务
        113
    no1xsyzy   76 天前
    花了一个小时,搜索中间人方案、下载(包括 pip 安装失败 —— brotli 当场编译需要 VS,那为什么打包 whl ?)、安装、看样例改代码,随手写了个中间人键盘记录器

    结合前端录屏审计工具就无敌了
    其实这个想法早前就有人实现过了,有人发现自己的网站用某些网访问的时候,登录会同时以明文 query 带账号密码请求一张图片,但远端没有收到这个请求 —— 很显然是 ISP 方面干的。
    如果只是靠加密一层防监听数据,防的叫旁听人攻击,而不是中间人攻击。
        114
    killerv   76 天前
    没有第三方信任的证书,你怎么都防止不了中间人,还是老老实实上 https 吧
        115
    kingiis   76 天前
    1.防抓包 对请求 响应 作最简单得 对流加密 拦截器 把整体 postbody 加密、
    2.防 hook 禁止 root 启动
    3.防本地 xml 存储文件注入攻击 加 Androidid+serNo,如果本地识别码不一致就清空各种登录方式

    当然可以考虑第三方 瑞数什么得来帮帮忙 如果公司有钱 可以考虑 https
        116
    fuxiaohei   76 天前
    @chinvo 我看的是这个 2017 年的文档写的方式,https://docs.open.alipay.com/58/103591/,走 MD5Key 的模式吧。
        117
    no1xsyzy   76 天前
    延伸说下去,其实如果真有中间人要从开头开始搞你,也不是问题,连你的浏览器可能都是被中间人替换的
    你说浏览器安装程序被系统签名确认了?被包管理器公钥验证了?你的系统也可能被中间人替换了
    如果说真深究下去,你连 CPU、内存、主板、甚至你的示波器是否有后门都不知道。
    说不定你自己焊电路接 LED 来看都可能不能保证发现问题:你怎么知道这个电烙铁没有后门在特定的时机虚焊导致你的检测电路失效?你怎么知道这个 LED 没有后门可以被远程控制亮灭?
    你怎么知道你的弱电知识没被中间人替换?
    或者哪天物理定律失效?
    听起来有点杞人忧天,但确实如此不是?

    现实没有 “保证”,只有 “风险控制”。
        118
    shdcn   76 天前 via Android
    rsa..... 很多都 ecdhe 了啊,早就做到前向安全了。and 登录又不是一定要发送用户名和密码,challenge 也行啊,kerb 那种不就可以了吗...... 带 timestamp 的 challenge 机制,不过实现起来蛮麻烦就是了.
        119
    alphatoad   76 天前   ♥ 1
    自己实现一遍 Diffie-Hellmann key exchange 呗……
    but why?
        120
    no1xsyzy   76 天前
    @type 你是说不管用户如何解密先加个密?
    那和 cat /dev/urandom 有什么区别吗?(笑哭
        121
    type   76 天前
    @no1xsyzy 所以说,在没有浏览器的支持下,想再模仿一遍 HTTPS 都是不可能做到的。除非自己做一个客户端。
        122
    chinvo   76 天前 via iPhone
    @fuxiaohei #114 这个文档是后端开发者调用支付宝接口进行应用鉴权的说明吧,和支付宝自己前端登录的实现无关
        123
    ClericPy   75 天前
    如果排除掉 https 但是又不限定 http 的话, 那选择可多了... 没想到这帖这么热, 可以去某些不存在的网站里搜一下
        124
    AstroProfundis   75 天前
    @rookiejin 你说的这个流程的问题在于:最开始客户端要怎么获得服务端的公钥呢?
        125
    xiangyuecn   75 天前
    @xuanbg #37 老哥,https 天然带防重放,你说的这个 bug 是应该不存在的
        126
    honeycomb   75 天前 via Android
    不能,防不了中间人
        127
    xiangyuecn   75 天前   ♥ 1
    想到一个绝佳的方案:做一个浏览器控件,发送给客户安装,为了保证控件安装包传输的安全性,打算用 u 盘拷贝+顺丰包邮(被调包也许可以理赔) [此处为核心思想] 。然后所有信息用这个控件进行加密解密,完美😂
        128
    dangyuluo   75 天前
    底裤都被脱掉了,怎么可能不被看光?
        129
    reself   75 天前
    @xiangyuecn 哈哈这时快递公司就相当于 CA 的角色了,快递公司保证送到的 u 盘是 ok 的,中途被调包或者打开过则打回而不会继续派送
        130
    reself   75 天前
    @xiangyuecn 如果快递公司信任级别不够,甚至不可信,则快递公司无法成为 CA,那送到的 u 盘是不可靠的
        131
    reself   75 天前
    @xiangyuecn 等于物理上造了个 https 的轮子~
        132
    alphatoad   75 天前 via iPhone
    为啥都在说不可能?我觉得完全可能啊,而且还很有意思
    把 HTTP 纯粹当 TCP 用,按照 TLS1.3 的 spec 自己实现一遍,从握手到 PKI
    虽然工作量很大,但是在我看来没有任何不可行的问题,尤其是现代浏览器提供了 WebCrypto API,可以产生密码学安全的随机数
        133
    alphatoad   75 天前 via iPhone
    哦对。现在有 WebSocket 了,连 HTTP 都省了,直接当 TCP 用
    所以我认为完全可以,毕竟我自己实现过一次,虽然只到了 TLS 那一层
        134
    no1xsyzy   75 天前
    @alphatoad 问题在于 HTTPS 没有其他渠道分发证书的话也是不可靠的,何况你网页本身就是不安全的
    先把 #113 的给过了再说,装个 mitmproxy
    mitmdump -s mitm_keyboard_recorder.py 然后把浏览器代理设置过去
    或者 mitmdump -ns mitm_keyboard_recorder.py 来 iptable 抓所有流量
    不用 https 的话你写什么有用?

    你其实就是实现了一个机会加密,然而机会加密防旁听不防
        135
    no1xsyzy   75 天前
    @no1xsyzy 手滑,防旁听不防中间人
    要真有可能,说说为什么 HOSTS 方法越壁必须 HTTPS ?
    Google 没这实力,你有?
        136
    alphatoad   75 天前 via iPhone
    @no1xsyzy ……我说的是用 TCP 自己实现一遍 TLS,包括 DH key exchange
    唯一在这个场景下的难题甚至不是一个技术问题,就是客户端需要内置 PKI 的公钥和一段代码,用于执行握手和握手后的远端代码执行
    这个问题可以用拓展解决
        137
    alphatoad   75 天前 via iPhone
    @no1xsyzy 你的第二个问题只要学过最基础的现代密码学就可以回答,我就不回复了
        138
    no1xsyzy   75 天前
    @alphatoad 那就是上面说的自写客户端。
    但其实你并不能保证这个客户端没有被篡改
    最终走线下,其实就是 PGP TrustNet 了
    第二个问题是设问句,设问句一般也不需要回答。
        139
    alphatoad   75 天前 via iPhone
    @no1xsyzy 我觉得楼主的问题非常有意思,在只允许 plain HTTP 协议和浏览器的情况下在不安全的信道实现可靠的加密传输非常有意思,基本就是在浏览器里实现一个浏览器了,非常很有趣
    结果大哥你一直在跟我说 HTTP 不安全,废话我当然知道 HTTP 不安全,要不然我费心思实现 TLS 干嘛
    我很喜欢有建设性的讨论,但这个讨论实在是没有意思
        140
    no1xsyzy   75 天前
    @alphatoad 你先写个能过了 #113 我写的那个 gist 的再说
    talk is cheap show me the code
        141
    lcdtyph   75 天前 via iPhone
    @alphatoad
    自己实现 tls 解决不了可信 ca 的问题,内置公钥的扩展如何分发呢,如何升级和召回呢
        142
    alphatoad   75 天前 via iPhone
    @no1xsyzy 我全程说的都是实现 TLS,您来一个应用层 HTTP 的 eavesdropping,密钥交换完了哪还有明文?
        143
    alphatoad   75 天前 via iPhone
    @lcdtyph 我认为这个问题可以用自建 PKI 的问题解决,当然用已有的 PKI 也可以,不过咱们还是简化一下这个问题吧
    公钥随拓展分发我认为可以解决这个问题。因为浏览器厂商的拓展商店肯定会有 HTTPS,所以信任链是可以建立的。
    至于升级和吊销是我们 CA 服务器的工作,一旦我们的可信链路建立,就可以实现相应的协议了
        144
    lcdtyph   75 天前 via iPhone
    @alphatoad
    如果可以用浏览器拓展商店的 https 那为什么还要自己实现一遍呢,题主的环境是不可以使用 https。
    如果有安全的预共享机制那的确是可以自己实现一套 tls 协议的,问题就是信任链的起点不好解决
        145
    alphatoad   75 天前 via iPhone
    @lcdtyph 因为这个问题很有趣啊,那还有人把 Win2k port 到浏览器呢,不都是因为 we can
    我仔细看了楼主的问题,楼主的服务不能使用 HTTPS,但没有说不能访问使用 HTTPS 其他站点,我就姑且 assume 这是可以的吧,如果不算作弊的话
    这个情况下浏览器就是我们的操作系统,考虑正常情况下用户都会依赖于操作系统内置的公钥获取浏览器,我们的用户依赖「操作系统」(浏览器)获取到「浏览器」(拓展),也可以理解
    如果说不能依赖任何已有的安全体系的话,如何分发代码我还真没想出来
    除非参考 ssh 模式,默认第一次连接的指纹是可以信任的
        146
    no1xsyzy   75 天前
    @alphatoad 你发放客户端的过程是不是明文传输的?
    确实,我没考虑到其他站点可以走 HTTPS,审题不够细,不过也没说可以,应该算 undefined behavior 吧
    有趣…… 其实还是玩具……
        147
    no1xsyzy   75 天前
    @alphatoad 俺寻思其实就是个 VPN Addon ?自建 VPN 这个其实前面也有人提过了
        148
    FS1P7dJz   75 天前
    你说 VPN 我寻思你说的应该是某饮料协议中的混淆协议实现方式?
    某饮料设计目的并非是"安全"而是跨越某些检测
    服务器本身就可以视为一个中间人,若你访问的网站不提供 https,那么服务器就可以发动中间人攻击的

    另外传统 VPN 本身也是基于证书颁发机制
    绕不开的...
    1  2  
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4094 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 30ms · UTC 03:15 · PVG 11:15 · LAX 19:15 · JFK 22:15
    ♥ Do have faith in what you're doing.