认证学习: 了解2FA的认证逻辑，就算移动端离线也可以正常认证

感谢伟大的费曼，应用费曼方法，总结学习！

认证是一个应用的关键环节，2FA的认证方式已经使用了很多次，对其内部实现，总是隐约一种猜想，没有机会得以验证。

在安全领域，证明身份通常有三个因素，分别为：你是什么，你知道什么，你拥有什么。互联网早期，“账号+密码”（你知道什么）的标准认证方式，随着技术的发展，这种方式变得极度脆弱。

依赖“密码”这种单一的证据来证明“你是你”，在现在的网络环境下已经不可靠了，我们需求增加证据的维度，引入了2FA（Two-Factor Authentication，双因素认证），当然也增加了认证的技术复杂度和使用的复杂度。

双因素认证，从认证的三要素中，选取两个不同的维度进行组合。例如密码|PIN码（你知道什么）+短信验证码|银行U盾（你拥有什么），或者密码（你知道什么）+指纹（你是什么）。

现在你应该能理解，为啥银行不厌其烦的让你使用U盾，密码太不可靠了。

以下为一个应用或者网站，接入2FA后的认证流程。

在使用Github或者Pypi提交新的版本时，每次都需要借助Microsoft Authenticator生成的六位验证数字。每次看到进度条时，总害怕时间耗尽，验证码失效，登录失效。

实际上，在平台的验证中，这种使用验证码（TOTP，Time-based One Time Password）的认证方式是存在一个时间窗口的，这个时间窗口，足可以让你：读取验证码->输入验证码->提交认证，时间上是可以从从容容的。

应用侧，实现一个随机的密钥，通过二维码进行展现，然后使用标准的认证器（Microsoft Authenticator/Google Authenticator）进行扫描读取，然后把读取到的密钥保存在手机上，同时应用侧生成的随机密钥，也需要同指定的用户进行映射，该密钥也需要进行保存。

简单些，用户在经过其他因素（密码等）认证后，读取当前映射的密钥，采用密钥+当前系统时间生成一个验证码，等待用户提交匹配；在移动端，打开认证器（Authenticator），读取当前保存的密钥，使用手机系统时间，计算出验证码，用户读取填写该验证码，同系统生成的验证码进行比对，如果比对成功，那么登录认证成功。

算法的核心公式：

这其中有关键性两点：

可能存在一个疑问，就犹如我最开始接触到这种认证方式时的感觉，“如果我手慢了，或者手机时间比服务器快了几秒怎么办？”，实际上TOTP（Time-based One Time Password）的“当前时间”，是按照“时间片”来计算的。

通过以上的介绍，你对2FA和手机上的Authenticator有新的认识吗？欢迎您的讨论。