微信淘宝等越来越多软件设计扫码登录的理由是什么，是一种「牺牲人性化来加强安全性」的设计吗？

之前电脑登录微信要用手机扫码，现在登录淘宝也要扫码登录。这些人设计扫码登录的出发点难道只是为了安全，或者说增加app的使用率。用户的操作就是打开app扫一下就完了，看似简单，但从用户的角度讲，我要想登录淘宝就要保证手机在身边还要装淘宝app并且处于登录淘宝状态手机还要联网（我其实只是想用电脑购物而已）。厂商这样设计的原因是不是就是和捆绑销售一样变相的增加app使用率。就像手机厂商声称不支持内存卡扩展是怕你们用劣质内存卡影响用户体验。

有关回应 · 2021-5-15 09:18:50

（2017.1.6更新）
我先从不同用户方面分析现在这扫码登陆的不合理性，欢迎提意见。我算是手机轻度用户，回家进门就把手机、钥匙、钱包放桌上，做饭吃饭等，忙完了，电脑前一座，打开淘宝开始剁手。这时候问题来了，我是起来去拿手机，亮屏开锁扫码登陆呢还是输密码？手机轻度用户基本不会手机处处随身。手机重度用户：”我TM不碰电脑的好吗？手机就是我的全部“
看到有的朋友说扫码登陆没有改变淘宝的安全性，但是网页版的淘宝你所能看到的信息和所操作的内容要比手机APP多，举个栗子，历史订单的查询数量，网页版全都在，手机APP只能看最近的一部分，这些内容足以分析一个人过去现在生活习惯个人爱好等信息，所以我认为扫码登陆让淘宝安全性降低了。
说到二维码，我觉得我对支付宝、微信的付款功能很没安全感。无须经过验证确认打开软件扫一下钱就没了。（试想一下这个情景，在麦当劳排队付款，前边小姑娘打开了支付宝付款二维码准备付款，我在后边偷偷扫了她的二维码收款，这算不算抢劫？当然我不知道这样是否可行。）不可否认的是，扫码支付太方便了！太快捷了！你可以忘记带钱包，但是不会忘记带手机！我的扫码支付功能是关闭了，用的时候再打开，并注意遮挡。

——————————————————————
非常同意你的观点，并且淘宝等把扫码登陆设为默认，进去登陆页面时首先闪过的是密码登陆，接着就跳到扫码了，好多次密码输了一半跳到了扫码登陆。产品经理脑残（骂产品没错吧？）？。至于安全性，如果手机丢了，以往如果不知道密码是登陆不了的（不考虑手机验证密码找回），现在直接扫码就登陆了，更安全了吗？我看未必。总之我觉得扫码登陆就是个鸡肋

有关回应 · 2021-5-15 09:18:49

不安全，曾经在朋友圈发了个二维码，分分钟登到别人账号。

有关回应 · 2021-5-15 09:18:48

最烦的就是密码输入了一半，跳到扫码页面
谁喜欢扫码，还要找手机，还要开淘宝app还要点扫一扫
不知道这脑残设计是谁想的
事倍功半

有关回应 · 2021-5-15 09:18:47

主要目的是为了保证你手机上开着app，换句话说这个设计可以提高手机app的kpi（业绩指标）。

至于什么安全性什么用户体验，相比手机app的业绩来说都是可以忽略不计的。

另外，二维码扫描就相当于去访问一个去向不明的url（因为多数app在访问扫描的结果之前无需确认），对扫描二维码的那一端是有很大安全风险的。你都用上二维码了还谈什么安全？方便与安全是互斥的，二维码本身只是为了方便，而非安全。如果真为了安全就应该完全拒绝使用二维码。

附带说一下，为了安全，请尽量让别人扫你，别人扫你，你没有不安全（风险在他），你扫别人风险更大。

有关回应 · 2021-5-15 09:18:46

很多程序员可能在自己的领域很厉害，但是对安全的理解有很大偏差，可以说是一团浆糊。

先说结论：扫码登陆确实可以增加安全性，而不是有些人说的安全性更差。（当然前提是和淘宝微信做出同样的水准）

扫码登陆并不是从根本上解决安全问题的，也不是什么突破性技术，所以用密码登陆可能受到的攻击：钓鱼、中间人等等都不能被解决。但是它能转移风险和控制风险。

从扫码登陆的原理讲起：
原理很简单，用户用客户端扫网页上的二维码，客户端有已经登陆的 cookie ，带着这个 cookie 访问二维码内容所显示的 URL ，用户点击“同意登陆”即再发起一个 post 请求。与此同时 web 端也在不停地轮询，当客户端扫码并点击登陆之后，轮询的某个请求会返回一个 url，web端直接访问这个 url 就能得到登陆认证通过的cookie。

1. 整个过程二维码的作用只起到了信息传递的作用，这个信息传递的“信道”相当于你手动在屏幕输入密码登陆。在你身旁有人、键盘监控、摄像头、等物体的监控下，这个“信道”是不够安全的。直接手动输入明文密码有泄露的风险，但泄露一个二维码并没有用，这个二维码完全可以是公开的，二维码->扫码->点击登陆每个环节都可以公开。而真正有效的 token 认证，发生在你看不见的手机客户端，通过 https 加密传输，这条信道相比输入密码要安全许多。这样基本就可以把登陆环节中的一条不安全“信道”排除掉，也能把“人”的一些不安全因素排除。当然，这也直接把风险转移到了手机端。

很多人说，

“如果浏览器有恶意插件、电脑中木马、网络被劫持、页面被注入了 js，把这个二维码替换成攻击方的，用户不知道，一扫，点击登陆不就被盗号了吗？”

你都能做到替换二维码了，还要啥扫码登陆盗号啊？直接拿 cookie 不就行了？或者直接取那些密码登陆框里的密码不就行了？

2. 登陆过程从本质上看，就是用一个长期的临时 token 换取一个短期临时 token。微信、手淘客户端的 cookie中 token 的有效期是很长的，所以你几乎什么时候打开这个客户端都不需要输入账号密码登陆。web 的 token 有效期反而是非常短的，淘宝十几分钟不操作，就自动“登出”了，微信网页版时间久了也会自动登出，关闭网页也会。

而密码可以看做是永久的 token，直到你改密码为止。用这个“永久 token”可以换取客户端、web 的 “临时”token。用“临时 token” 换“临时 token”，和用“永久 token”换“临时 token”风险是不同的。如果临时 token 泄露，像手机被偷了、丢了、换手机了，可以通过管理账户删除这个设备，相当于把这个临时token 置为失效。最不济是等这个临时 token 过了有效期自然失效。而如果明文密码泄露了，就和你把 root 密码泄露了一样，你其他user再安全也于事无补。

你可能觉得我说的这些有点扯，但这就是风险控制，虽不是从根本上解决安全问题，确实可以提高安全性。

3. 多一个风险监控设备。
我之前写过淘宝自动发货，为了维持web版的cookie有效，每分钟发一次请求作为心跳，这样一个 cookie 也最多只能有效8个多小时。最后就用手淘客户端的 cookie，模拟扫码登陆过程，每8小时多就重新登陆一次。当时觉得这扫码登陆好不安全啊，又不用输入验证码啥的。

但是后来发现有时候扫码登陆会失败，但有时候就会成功，找不到规律。最后忽然发现，扫码登陆成功或失败居然跟我最近有没有打开过手淘客户端有关！！也就是说你光发扫码登陆环节的请求还不够，从打开淘宝到扫码，一系列“无关”请求中可能其中有几个是“风控点”，如果你不发这几个，也是无法登陆成功的。而扫码前一堆请求可能每次都不同，可能有的请求带了点验证算法，你还得分析每个请求甚至逆向客户端，这其中的时间成本大大增加。

微信网页版也类似，可以参见这个微信机器人的项目中遇到最大的阻碍：https://github.com/littlecodersh/ItChat/issues/70 。这个问题最后的结论差不多就是，如果微信断线超过一定时间了，那么微信网页版的 cookie也会失效了。

倘若你的客户端 cookie 泄露，事情也不是很多人想象的那么简单，轻轻松松拿着这个 cookie 去扫码登陆就可以的。因为多了手机这样一个设备，官方有一百种方法做风险控制，而你却无可奈何被牵着鼻子走。例如，你扫码的手机的 IP 或定位在上海，而要登录的 web 却是在北京的 IP 访问的，那么完全可以拒绝登陆。通过手机其他一些传感器还能得到更多的信息，未来可发挥的空间也更大。

4. 风险转移到客户端，专注做好客户端防御，当然微信是这么想的，毕竟微信客户端不需要考网页版推广。淘宝推荐扫描登陆肯定是有一定原因为了推广客户端，提高客户端活跃率。

不过个人认为相比 web 端，客户端更安全一些或者说更容易做安全。因为前端的所有运行代码都是可以直接看得到的，即便 js 做了混淆压缩，但逻辑都是能看得到的。而客户端虽然也可以反编译，但相比于直接“审查元素”，门槛要高不少（可以去了解一下各种第三方“加固宝”防反编译的手段，想得到混淆后的代码这一层都很不容易，而前端则可以直接得到）

总结一下，扫码认证的好处：
1. 规避人工输入密码这一不安全环节，排除相关不风险因素。
2. 用长期的 token 换取临时 token，控制风险。
3. 多一个可帮助风险监控的设备。
4. 转移风险到客户端，尽力做好客户端安全。

坏处也是有一些的，比如扫码相对于密码，不会让一些人提高警惕，容易被钓鱼。但同时对于“钓鱼者”，要想实现扫码登陆的钓鱼页面比密码登陆的钓鱼要难一些(要轮询还要同步二维码状态，及时更新二维码等等)，所付出的成本，可能并不能多钓到几条鱼，所以目前扫码钓鱼网站几乎没有。

微信淘宝等越来越多软件设计扫码登录的理由是什么，是一种「牺牲人性化来加强安全性」的设计吗？

5 个回复

浏览过的版块