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

[NoKey]

考虑了一下这个问题
目前把这个问题分成两步
第一，注册
第二，登陆

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

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

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

各位大佬，有没有更好的办法呢？一起讨论一下吧～～～

[type]

@type 写了一堆，才发现第一步的公钥返回给客户端时，就存在被中间人替换的可能，后面的步骤就没用了。https 是浏览器内置了 CA 根证书

[fuxiaohei]

你可以去找一下支付宝和微信支付当年没有上 https 时候的签名算法，也许是 http 下能做的足够可靠的吧。

[nowgoo]

模拟 https，做密钥交换那一步的时候，服务器通过短信发送随机数呢？

[Torpedo]

短信验证，第三方登录。
都知道自己不安全，那还不搞个三方的

[no1xsyzy]

@VensonEEE 直接插 js 录键鼠屏
都直接知道你密码了还有什么不知道的？

[rookiejin]

这还是不安全的，
https 是在握手的时候把公钥下发，客户端拿着公钥签名了，中间人获取到内容也看不到真实的东西，

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

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

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

提交的数据如下：


加密内容：

password=123465


加密后：

{"sign":"xxxxxxxxxxxxxxxxxxx"}


服务器解出 sign 就行了。

[chennqqi]

服务端下发公钥
客户端用公钥把数据加密
服务端用私钥解密
HTTPS 主要是解决传输过程的安全。HTTPS 用非对称加密传递对称加密的密钥。

自己登录和注册数据比较少可以直接使用非对称加密
为了防止重放攻击可以在下发数据中加入随机数，要求客户端一起加密上送

[type]

@no1xsyzy 是的，只要中间人往返回内容插 JS，记录用户操作，用户的账号密码就泄露了。
除非全站加密，问题是基于 HTTP 全站加密，浏览器端也解不了密，那用户看到的全是乱码

[chinvo]

@fuxiaohei #102 那个靠的是安装控件的时候预置在控件内的 CA 证书

[Livid]

2019 年了，没有任何理由不上 https 了。

[blless]

😃看 v 站讨论登陆业务能否看出 v2 的人均业务水准？感觉像几年前自己没接触任何安全的时候问得问题

[blless]

另外说一句，这两种业务都是最常见且业内有套标准流程的业务

[no1xsyzy]

花了一个小时，搜索中间人方案、下载（包括 pip 安装失败 —— brotli 当场编译需要 VS，那为什么打包 whl ？）、安装、看样例改代码，随手写了个中间人键盘记录器
https://gist.github.com/no1xsyzy/1b342ed48b09bb2c22d368b161cb351d
结合前端录屏审计工具就无敌了
其实这个想法早前就有人实现过了，有人发现自己的网站用某些网访问的时候，登录会同时以明文 query 带账号密码请求一张图片，但远端没有收到这个请求 —— 很显然是 ISP 方面干的。
如果只是靠加密一层防监听数据，防的叫旁听人攻击，而不是中间人攻击。

[killerv]

没有第三方信任的证书，你怎么都防止不了中间人，还是老老实实上 https 吧

[kingiis]

1.防抓包 对请求 响应 作最简单得 对流加密 拦截器 把整体 postbody 加密、
2.防 hook 禁止 root 启动
3.防本地 xml 存储文件注入攻击 加 Androidid+serNo，如果本地识别码不一致就清空各种登录方式

当然可以考虑第三方 瑞数什么得来帮帮忙 如果公司有钱 可以考虑 https

[fuxiaohei]

@chinvo 我看的是这个 2017 年的文档写的方式，https://docs.open.alipay.com/58/103591/，走 MD5Key 的模式吧。

[no1xsyzy]

延伸说下去，其实如果真有中间人要从开头开始搞你，也不是问题，连你的浏览器可能都是被中间人替换的
你说浏览器安装程序被系统签名确认了？被包管理器公钥验证了？你的系统也可能被中间人替换了
如果说真深究下去，你连 CPU、内存、主板、甚至你的示波器是否有后门都不知道。
说不定你自己焊电路接 LED 来看都可能不能保证发现问题：你怎么知道这个电烙铁没有后门在特定的时机虚焊导致你的检测电路失效？你怎么知道这个 LED 没有后门可以被远程控制亮灭？
你怎么知道你的弱电知识没被中间人替换？
或者哪天物理定律失效？
听起来有点杞人忧天，但确实如此不是？

现实没有 “保证”，只有 “风险控制”。

[shdcn]

rsa..... 很多都 ecdhe 了啊，早就做到前向安全了。and 登录又不是一定要发送用户名和密码，challenge 也行啊，kerb 那种不就可以了吗...... 带 timestamp 的 challenge 机制，不过实现起来蛮麻烦就是了.

[alphatoad]

自己实现一遍 Diffie-Hellmann key exchange 呗……
but why?

[no1xsyzy]

@type 你是说不管用户如何解密先加个密？
那和 cat /dev/urandom 有什么区别吗？（笑哭

[type]

@no1xsyzy 所以说，在没有浏览器的支持下，想再模仿一遍 HTTPS 都是不可能做到的。除非自己做一个客户端。

[chinvo]

@fuxiaohei #114 这个文档是后端开发者调用支付宝接口进行应用鉴权的说明吧，和支付宝自己前端登录的实现无关

[ClericPy]

如果排除掉 https 但是又不限定 http 的话, 那选择可多了... 没想到这帖这么热, 可以去某些不存在的网站里搜一下

[AstroProfundis]

@rookiejin 你说的这个流程的问题在于：最开始客户端要怎么获得服务端的公钥呢？

[xiangyuecn]

@xuanbg #37 老哥，https 天然带防重放，你说的这个 bug 是应该不存在的

[honeycomb]

不能，防不了中间人

[xiangyuecn]

想到一个绝佳的方案：做一个浏览器控件，发送给客户安装，为了保证控件安装包传输的安全性，打算用 u 盘拷贝+顺丰包邮（被调包也许可以理赔） [此处为核心思想] 。然后所有信息用这个控件进行加密解密，完美😂

[dangyuluo]

底裤都被脱掉了，怎么可能不被看光？

[reself]

@xiangyuecn 哈哈这时快递公司就相当于 CA 的角色了，快递公司保证送到的 u 盘是 ok 的，中途被调包或者打开过则打回而不会继续派送

[reself]

@xiangyuecn 如果快递公司信任级别不够，甚至不可信，则快递公司无法成为 CA，那送到的 u 盘是不可靠的

[reself]

@xiangyuecn 等于物理上造了个 https 的轮子~

[alphatoad]

为啥都在说不可能？我觉得完全可能啊，而且还很有意思
把 HTTP 纯粹当 TCP 用，按照 TLS1.3 的 spec 自己实现一遍，从握手到 PKI
虽然工作量很大，但是在我看来没有任何不可行的问题，尤其是现代浏览器提供了 WebCrypto API，可以产生密码学安全的随机数

[alphatoad]

哦对。现在有 WebSocket 了，连 HTTP 都省了，直接当 TCP 用
所以我认为完全可以，毕竟我自己实现过一次，虽然只到了 TLS 那一层

[no1xsyzy]

@alphatoad 问题在于 HTTPS 没有其他渠道分发证书的话也是不可靠的，何况你网页本身就是不安全的
先把 #113 的给过了再说，装个 mitmproxy
mitmdump -s mitm_keyboard_recorder.py 然后把浏览器代理设置过去
或者 mitmdump -ns mitm_keyboard_recorder.py 来 iptable 抓所有流量
不用 https 的话你写什么有用？

你其实就是实现了一个机会加密，然而机会加密防旁听不防

[no1xsyzy]

@no1xsyzy 手滑，防旁听不防中间人
要真有可能，说说为什么 HOSTS 方法越壁必须 HTTPS ？
Google 没这实力，你有？

[alphatoad]

@no1xsyzy ……我说的是用 TCP 自己实现一遍 TLS，包括 DH key exchange
唯一在这个场景下的难题甚至不是一个技术问题，就是客户端需要内置 PKI 的公钥和一段代码，用于执行握手和握手后的远端代码执行
这个问题可以用拓展解决

[alphatoad]

@no1xsyzy 你的第二个问题只要学过最基础的现代密码学就可以回答，我就不回复了

[no1xsyzy]

@alphatoad 那就是上面说的自写客户端。
但其实你并不能保证这个客户端没有被篡改
最终走线下，其实就是 PGP TrustNet 了
第二个问题是设问句，设问句一般也不需要回答。

[alphatoad]

@no1xsyzy 我觉得楼主的问题非常有意思，在只允许 plain HTTP 协议和浏览器的情况下在不安全的信道实现可靠的加密传输非常有意思，基本就是在浏览器里实现一个浏览器了，非常很有趣
结果大哥你一直在跟我说 HTTP 不安全，废话我当然知道 HTTP 不安全，要不然我费心思实现 TLS 干嘛
我很喜欢有建设性的讨论，但这个讨论实在是没有意思

[no1xsyzy]

@alphatoad 你先写个能过了 #113 我写的那个 gist 的再说
talk is cheap show me the code

[lcdtyph]

@alphatoad
自己实现 tls 解决不了可信 ca 的问题，内置公钥的扩展如何分发呢，如何升级和召回呢

[alphatoad]

@no1xsyzy 我全程说的都是实现 TLS，您来一个应用层 HTTP 的 eavesdropping，密钥交换完了哪还有明文？

[alphatoad]

@lcdtyph 我认为这个问题可以用自建 PKI 的问题解决，当然用已有的 PKI 也可以，不过咱们还是简化一下这个问题吧
公钥随拓展分发我认为可以解决这个问题。因为浏览器厂商的拓展商店肯定会有 HTTPS，所以信任链是可以建立的。
至于升级和吊销是我们 CA 服务器的工作，一旦我们的可信链路建立，就可以实现相应的协议了

[lcdtyph]

@alphatoad
如果可以用浏览器拓展商店的 https 那为什么还要自己实现一遍呢，题主的环境是不可以使用 https。
如果有安全的预共享机制那的确是可以自己实现一套 tls 协议的，问题就是信任链的起点不好解决

[alphatoad]

@lcdtyph 因为这个问题很有趣啊，那还有人把 Win2k port 到浏览器呢，不都是因为 we can
我仔细看了楼主的问题，楼主的服务不能使用 HTTPS，但没有说不能访问使用 HTTPS 其他站点，我就姑且 assume 这是可以的吧，如果不算作弊的话
这个情况下浏览器就是我们的操作系统，考虑正常情况下用户都会依赖于操作系统内置的公钥获取浏览器，我们的用户依赖「操作系统」（浏览器）获取到「浏览器」（拓展），也可以理解
如果说不能依赖任何已有的安全体系的话，如何分发代码我还真没想出来
除非参考 ssh 模式，默认第一次连接的指纹是可以信任的

[no1xsyzy]

@alphatoad 你发放客户端的过程是不是明文传输的？
确实，我没考虑到其他站点可以走 HTTPS，审题不够细，不过也没说可以，应该算 undefined behavior 吧
有趣…… 其实还是玩具……

[no1xsyzy]

@alphatoad 俺寻思其实就是个 VPN Addon ？自建 VPN 这个其实前面也有人提过了

[FS1P7dJz]

你说 VPN 我寻思你说的应该是某饮料协议中的混淆协议实现方式?
某饮料设计目的并非是"安全"而是跨越某些检测
服务器本身就可以视为一个中间人,若你访问的网站不提供 https,那么服务器就可以发动中间人攻击的

另外传统 VPN 本身也是基于证书颁发机制
绕不开的...