扫描二维码登入安全吗？

Posted 2020-10-08 今夕是何夕

转载自 https://abcdabcd987.com/qrcode-login/

昨天在知乎上看到了一个问题微信淘宝设计扫码登录的理由是什么，牺牲人性化来加强安全性？，本以为这是一个送分题，可是点开一看，竟然我仰慕的高票答主回答并没有给出我期望的回答，还有许多我关注的大大们点了赞。再一看，下面一排都在无脑喷阿里和腾讯，一点都没有认真答题的意思，气得我一个个点了反对+没有帮助。终于看到了一个@陈裕皓 写的正常的答案，几乎感动得我热泪盈眶。其实我觉得他基本上把我能说的话都说了，不过我还是看热闹不嫌事大，再插一脚进来科普科普吧。

嫌太长不想看的直接翻到最后的“总结”部分吧。

登入网站是如何工作的？

先科普一下最简单的登入一个网站的过程是怎样的吧。

1. 当你的浏览器第一次访问一个网站的时候，这个网站会分配给你一个会话（Session)。
   • 会话的信息都是存在服务器上的，也就是服务器有个自己的小本子记录了会话的信息。
   • 服务器会把 session_id 返回给你的浏览器
   • 之后每一次你访问这个网站的任何页面，你的浏览器都会把这个 session_id 发给服务器
   • 服务器根据这个 session_id 就可以分辨不同的会话，同时，前面说了，也只有服务器自己知道和这个会话相关的任何信息
2. 在还未登入的时候，服务器看到你这个 session_id 对应的会话里面写着“还没有登入”，于是就给你展示了游客的内容。
3. 你进入了网站的登入界面，填写了账号密码，点击登入。
4. 你的浏览器把你的账号密码发送到了服务器。
5. 服务器从数据库里面查了查，发现你的账号密码是匹配的。于是服务器给 session_id 对应的会话设置了新的信息，比如“已登入、用户ID……”
6. 之后你再访问这个网站，你的浏览器还是把同样的 session_id 发给服务器。服务器查一查自己的小本子，发现噢这个会话已经登入了，并且用户ID是多少多少。于是就把属于这个用户（也就是你）的信息展示给你。

这里顺带提一下，session_id 在浏览器这里的具体表现形式就是 Cookie 里的一个键值对。

扫码登入是如何工作的？

回顾一下，其实站在用户浏览器这边，基本上没什么事情好做。每次都只是拿着第一次访问服务器的时候服务器分配的 session_id 傻乎乎地去戳服务器，然后把服务器返回的信息呈现给用户。而服务器这边，每次都是根据会话信息的不同来决定返回什么内容给浏览器。

所以说，重点在于让服务器把会话信息改成已登入的信息。你想要让服务器把你的会话信息改掉，你总不能空口无凭吧？不然你不就可以进入任何人的淘宝了吗。在前面的例子里面，让服务器相信你就是用户本身的方法就是验证你的账号密码。扫码登入其实就是换了一种让服务器相信你确实就是你的方式。

作为一个（自称）全栈工程师，扫码登入是怎么工作的还是很容易想到的：

1. 用户打开登入页面的时候，他的浏览器与服务器产生了一个会话。服务器分配给他一个 login_token并记下它对应的会话 session_id，这个 login_token 会作为某个验证登入的网址 qr_verify_url 的一个参数。让用户输入一大串网址太麻烦了，于是服务器把 qr_verify_url 这个网址用二维码包装一下呈现给用户。
2. 用户用已经登入了的该网站自家的手机APP扫描二维码，得到一个 qr_verify_url。
   • 这里要注意的是，扫描这个二维码的软件不能是随随便便的APP，必须是这个网站自家的APP。
   • 强调自家手机APP已经登入，说明手机APP上有一个服务器颁发的 app_token。
3. 手机APP弹出提示，告诉用户这是一个登入请求，如果确认是本人的操作，那么点击登入按钮。
4. 点击了登入按钮之后，手机APP访问拿着 login_token 和 app_token 这两个令牌去访问 qr_verify_url。
5. 服务器收到了请求，发现 app_token 和 login_token 都是有效的，于是找到 login_token 对应的 session_id。接下来的步骤就和正常登入一样了，往这个 session_id 对应的会话里面写信息，比如说：登入成功、用户ID……
6. 用户的浏览器在这整个过程期间其实都在不断询问服务器：我这个会话 session_id 登入成功了吗？没有的话，就等一会儿再问一次。一旦服务器告诉它，登入成功了，浏览器就跳转到别的页面，结束了登入流程。
7. 这个时候因为服务器已经给会话 session_id 设置了相应的信息，所以服务器知道用户已经登入了，于是返回给用户的页面都是登入后的结果。

举个例子

以登入淘宝为例。在登入界面看到了一个大大的二维码。

我们先不着急用手机淘宝扫它，我们先用在线二维码阅读器看看这个二维码里面写着什么。

可以看到这是一个短链接。我们继续看看这个短链接里面是什么内容。

里面的“目标地址”就是前面说的 qr_verify_url。红色框出来的就是 login_token。值得注意的是，这个 login_token 和我们浏览器中的 login_token 是相同的。顺带提一下 session_id 就是访问服务器的时候那一大串的 Cookie 里面的一部分。

现在让我们用手机扫一扫二维码。扫描完了之后会有安全提示。点击确认登入，然后我们就开心地登入了。

引入新的隐患？

知道了这个登入的流程，我们不妨站在攻击者的角度考虑一下有没有什么空子可以钻。在这里，我想说明的是，就算没有提升安全性，扫码登入相比起传统密码登入也没有引入新的安全隐患。

替换二维码（中间人攻击）

1. 攻击者用自己的浏览器访问登入页面，得到一个二维码
2. 攻击者用某种方法劫持用户流量，当用户打开登入页面时，将二维码替换成自己的二维码
3. 用户扫描二维码，并且用户并不知道这个二维码不是服务器给的而是攻击者替换过的，于是点了确认登入
4. 攻击者成功登入

这是最容易想到的攻击方式。不过这种攻击方式放在今天，尤其是大网站的情况下，几乎不可能发生。现在大网站的登入页面基本上都采用了 https 协议，相比起普通的 http 协议，https 流量都是加密的。并且以现在计算机乃至超级计算机的算力，想要破解是几乎不可能的。

也就是说，黑客完全不知道你访问了登入页面，更不用说在登入页面上做手脚了。这条路行不通。

替换二维码（恶意浏览器插件或者病毒）

1. 用户不小心安装了恶意的浏览器插件或者中了病毒
2. 登入页面的二维码在本地被替换为攻击者的二维码
3. 中招

这个方法可行。但是，这并不是把密码登入换成扫码登入带来的问题。用密码登入同样也会遇到这样的问题：病毒可以把登入页面替换成攻击者的钓鱼网站，或者直接把用户密码发送给攻击者……

二维码公开地显示在屏幕上被别人扫走

（黑人问号脸？？？）那不是你就登入了攻击者的账号吗，你不亏啊，而且为啥攻击者要送呢？

主动跳进坑里

1. 攻击者在朋友圈贴了一个二维码
2. 你扫描，强行忽略“请确认是本人登入”的字样，看到那个大大的按钮就是很想按下去
3. 中招

你硬要把钱塞给我，我也没法不要呀 ╮(╯_╰)╭

另外，从技术上来说，也是困难的。像淘宝的登入二维码过期速度飞快，似乎一分钟就过期了（我前面几张图截图慢了点，于是二维码过期 token 对不上了，只好再全部重新截图一次）。那么问题来了，这个攻击者人气得多高才能在发完朋友圈的一分钟之内立马有人扫码登入呢？

手机丢了被别人捡走

所以说攻击者捡到了你的手机之后，打开淘宝登入页面，心想“哈哈哈，我不用密码就能登入了。”于是在你的手机上打开了手机淘宝，扫码登入……

（黑人问号脸？？？）攻击者为啥不直接用你的手机淘宝啊？这并不是把密码登入换成扫码登入带来的问题，本来手机丢了之后就会有很直接的安全问题，还轮不到扫描登入来背锅。

扫码进入恶意网站

1. 攻击者制作一个诱人的广告或者（克服重重困难）以某种方式替换了登入二维码，指向某恶意网站
2. 扫码中招

你扫了码，然后发现没有一个让你点击“确认登入”的地方，你还会继续吗？

就算攻击者做了一个长得一模一样的恶意网站，骗你点击“确认登入”。可是手机淘宝发现这个网站不是来自 taobao.com，于是就不会把手机上的 app_token 发出去。所以攻击者什么都得不到。

扫码下载病毒

1. 攻击者制作一个诱人的广告或者（克服重重困难）以某种方式替换了登入二维码，指向某恶意软件下载地址
2. 扫码中招

这个是扫码本身的问题，不是扫码登入带来的。扫码登入的时候弹出了一个下载，你不会觉得很奇怪吗？怎么还会继续下载、运行病毒呢？

破解手机APP

1. 攻击者通过某种方式进入了你的手机（可能是远程地），破解了手机淘宝
2. 找到了手机淘宝保存在本地的 app_token
3. 拿着 app_token 伪装是你本人操作，发送登入确认信息

对攻击者来说，这里变数非常多，这三点都是很困难的。

1. 在不接触你的手机的情况下要进入你的手机、然后获得非常高的权限，这很困难。
2. 数据加密。要找到正确的解密方式需要一番波折。
3. 发送给服务器的信息可能非常多，即还需要搞定别的验证信息。

而且这些问题都是手机APP原先就可能存在的安全隐患，和扫码登入无关。

扫码登入带来的些许好处

避免密码泄露

在不考虑电脑中毒的情况下，输入密码也有可能被攻击者肉眼看到或者拍摄到。而扫码登入，尽管二维码是公开的，但只有你自己用手机APP扫描才有用。

原先的核心验证信息是账号密码，是暴露在外界的。现在的核心验证信息变成了手机里的 app_token，而这是外界看不到的，只有手机APP自己知道。就这点来说，安全性确实提高了。

用专用令牌替换通用令牌

许多人都会用同样的密码登入不同的网站，这样一旦任何一个网站被攻破，攻击者拿到了你的密码，他就可以尝试并成功登入其他网站。

而扫码登入的话，就算攻击者拿到了 app_token，也找到了伪造请求的正确方法，他也只能登入一个网站，对其他网站束手无策。

用短期令牌替换长期令牌

用户名密码可以看成是过期时间无穷或者非常大的令牌（毕竟修改密码的频率很低，甚至大多数人是不会去修改密码的）。扫码登入的二维码有效期非常短（比如一分钟）。手机APP上的 app_token 也可以设计成快速过期（比如半个月不打开手机APP则失效），也可以吊销（“删除该设备”）。

短期令牌总是不比长期令牌糟糕的。

便捷性

很多人其实是记不住自己的密码的，每次登入总要试个半天，或者有的人密码很复杂然后打字又慢，这个时候扫一扫就能登入难道不是很诱人的选择吗？

理想很丰满

现实却很骨感。上面说了这么多的好（或者说起码不差），这都是建立在一些前提上的，一旦这些前提不满足，攻击者就能从很多角度攻击。

没有完全强制 HTTPS

举几个例子：

• 攻击者迫使用户使用 HTTP 进行连接
• CDN 部署有问题，导致 HTTPS 降级，二维码被替换
• 服务器没有使用 HSTS，允许夹杂 HTTP 协议的内容，攻击者趁机在 HTTP 访问的 javascript 脚本中插入恶意代码

程序逻辑漏洞

举几个例子：

• 手机APP没有验证页面来自自家服务器，就把 app_token 发了出去
• 手机APP没有强制使用 HTTPS 连接自家服务器
• 二维码过期时间过长

用户自身素质问题

举几个例子：

• 容易使得自己的电脑/手机中毒
• 轻易被攻击者引导
• 扫码自动下载并运行了病毒的安装程序，竟然还主动点击“安装”
• 不看提示，无脑点击，主动把自己卖了

总结

在我看来，扫码登入比起密码登入并没有引入新的安全隐患，甚至从侧面提高了一定的安全性。但是这需要厂商、用户共同努力。厂商不能犯低级错误，用户要提高自身素质。这难吗？

尽管大家非常喜欢抨击BAT，但是还是要相信大厂的安全人员还是不会犯低级错误的。

用户方面，只要厂商把自己的事情做好了，用户的素质并需要多高。另外，随着这些科技不断深入日常生活，用户素质也会逐渐提高的。