扫码登录的安全性分析

时至今日，各大互联网公司都已提供并鼓励使用扫码登录功能。扫码登录通过二维码在设备之间传递信息，使得用户可以使用安全可信任的设备（比如自己的手机）来控制不可信任的设备上的登录行为。其省去了在不便手动输入的设备（比如电视）上输入的环节，所以更方便；避免了在安全等级低的设备和环境（比如公共电脑、Web页面）中输入密码，因此更安全。

本文分析二维码扫码登录功能通常的实现方式，并重点总结实现过程中需要注意的安全点。

扫码登录流程有以下几个步骤：

非授信设备访问服务端生成token，并将token通过二维码展示在界面上；

授信设备扫描展示在非授信设备上的二维码，获取到token；

授信设备使用token访问服务端获取非授信设备的设备信息，并将非授信设备的设备信息展示在界面上，请用户确认；

用户确认在授信设备上确认后，授信设备访问服务端，告知服务端该token已被用户确认可用来登录；

非授信设备使用token登录。非授信设备并不知道用户何时会确认，所以需要轮询服务端，一直使用token尝试登录，直到成功；

需要注意的安全点有：

所有接口访问，要使用https；

token要有一个较短的有效期比如5分钟，且一次有效，用过即失效；

流程中第4步：展示被扫码端设备信息并请用户确认，必须有，不能省略；

总结以上两点，token有四个状态：NEW（新生成）、SCANNED（已扫描待确认）、CONFIRMED（已确认）、USED（已使用）；

相应的，流程中第5步，使用token尝试登录可能有5种返回：token不合法、待扫描、已扫描待确认、登录成功并返回用户登录凭证、token已被使用过，失败的情况可以展示相应的信息以提升用户体验；

token只允许在生成该token的设备上进行登录，这需要有支持防伪造的唯一标识设备的能力，比如设备指纹；

扫码端必须是授信设备；

Web端不能成为扫码端；

必要时，第3步和第4步，可以使用非HTTP协议；

本文不讨论服务端安全，比如token怎样存储等；

就想到这么多:)