扫码登陆真的安全吗？ 外汇需要别人帮忙登录吗安全吗是真的吗知乎

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

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

登入网站是如何工作的？

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

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

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

扫码登入是如何工作的？

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

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

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

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

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

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

可以看到这是一个短