验证器上的 6 位验证码是用手机时间算出来的
验证器上的 6 位数一个个照着敲进去，网站还是回一句验证码错误，这时候该看的是手机上的时间。那 6 位数是手机拿当前时间现算出来的，按算法规范 RFC 6238 的默认值是 30 秒换一个；手机的钟偏了，算出来的就是别的时间段的码，敲得再仔细也对不上。
安卓版谷歌验证器（Google Authenticator）的设置里有一项 Time correction for codes，可以用它校一次时。别的验证器只要也是按时间出码，道理相同，手机时间不准，码就跟着错。校完时间仍然过不了，原因就在时钟以外了。
两步验证码输对了还提示错误的排查顺序
从上往下查，前一项排除了再看后一项。
| 你遇到的现象 | 先查什么 | 怎么做 |
|---|---|---|
| 每一个码都被拒，等它换成新的再输也一样 | 手机时间有没有偏 | 安卓版谷歌验证器用应用内的校时；别的验证器把手机自身的日期和时间校准 |
| 码快要跳走时才提交，被拒 | 提交的那一刻是不是已经进了下一个时间段 | 等新码刚出现时再输，把输入和提交的时间留足 |
| 这个码刚通过一次验证，紧接着的另一步又输它，可能被拒（按规范的要求，验证通过的码不应再被接受） | 屏幕上的码换了没有 | 等它跳成新的再输 |
| 应用提示时间本来就是准的，码照样不过 | 输的是不是这个账户对应的那一条 | 核对验证器里条目的名称和账户 |
| 已经连着错了好几次 | 要不要继续试 | 停手，先把上面几项查完；被锁定了走平台官方客服渠道 |
两步验证核对的是两样东西：你知道的密码，和你手里的验证器。提示里说的若是密码不对，那属于找回登录密码的范围，调时间不起作用。
判断手机时间偏没偏，要拿一个信得过、显示到秒的时间来对。一个码默认只管 30 秒，只看分钟是看不出来的。
在安卓版谷歌验证器里校准验证码的时间
按 Google 账号帮助中心的校时说明，验证器生成的码依赖安卓设备上的正确时间，码不管用，可能就是设备上的时间不对。操作顺序：
- 打开 Google Authenticator 应用。
- 点 More，再点 Settings。
- 点 Time correction for codes。
- 点 Sync now。
这几个名称是英文界面上的写法，手机语言设成中文时，按意思找对应的那几项。点完以后，下一个画面会确认时间已经同步，接着用新跳出来的码去登录。
同步会确认时间不准是不是问题的根源；是的话，把时间对到 Google 服务器的时间上。受影响的只有验证器应用内部的时间，手机系统的日期和时间设置不会被它改动。
应用如果告诉你时间本来就是准的，Google 的建议是去看它的 Common issues 页，找验证码不管用的其他原因。时钟这一项到这里就排除了。
6 位验证码的算法只用到密钥和当前时间
按时间出码的验证器，算法出自 RFC 6238，名字叫 TOTP，意思是基于时间的一次性密码。它是一份公开的技术规范，不是法规；一个码管多长时间叫步长，这类数值由验证器和网站在绑定环节事先约定。
算码只用到两样：手机里存的密钥，和手机当前的时间。密钥是绑定验证器的时候定下的：手机和网站共用同一串，规范要求每一个验证器都有自己独立的密钥。两样都在手机里，码是手机自己算出来的；网站那头拿同一串密钥、按它自己的时钟也得出一个数，和你提交的做比对。
时间要先折成一个整数 T。把时间按步长切成一格一格，规范里管每一格叫时间步，T 就是从起点到现在走完了几格：
T =（当前 Unix 时间 − T0）÷ 步长，结果向下取整
Unix 时间是从 1970 年 1 月 1 日 UTC 零点数到现在的秒数；T0 是开始数格子的起点，默认取 0；步长的默认值是 30 秒。T0 取 0、步长取 30，Unix 时间走到 59 秒时 T 是 1，到 60 秒 T 变成 2。用同一条公式往后推：89 秒时 89 ÷ 30 ≈ 2.97，取整还是 2；到 90 秒，90 ÷ 30 = 3，T 才变成 3。同一格里 T 不变，生成的码也就是同一个。实际的 Unix 时间比这组数大得多，算法是同一条。
手机慢了会怎样，接着用这组小数字看。真实时间走到第 100 秒，网站这边 100 ÷ 30 ≈ 3.33，T 是 3。手机慢了 45 秒，它以为现在是第 55 秒，55 ÷ 30 ≈ 1.83，T 是 1。3 − 1 = 2，两边差了 2 格：手机屏幕上显示的，是网站那边两格以前的码。
验证码默认 30 秒换一次，这个数是怎么定的？
30 秒是 RFC 6238 给步长定的默认值，也是它推荐的取值，理由是在安全和好用之间取一个平衡。
步长放大，安全这一头先吃亏。一个码在被用掉之前如果让第三方看到了，对方在这一格之内就能拿它去用，步长越大，留给对方的时间越长。另一个代价在使用上：下一个不同的码要等到下一格才出现，步长要是放到 10 分钟，很可能不适合典型的网上登录。
码从手机到网站还要花时间。网站收到码的时候并不知道它是哪一秒生成的，通常拿收到的时刻去比对；一个在这一格快结束时生成的码，送到时很可能已经落进下一格。所以规范建议网站定一个可以接受的传输延迟窗口，除了收到那一刻所在的那一格，延迟范围内刚过去的格子也拿来比对。可接受的窗口越大，暴露给攻击的窗口也越大，推荐的上限是网络延迟最多放一个时间步。
手机时钟本身的偏差另有一条建议：网站给对不上的格数设一个明确的上限，往前、往后都可以设，超出上限的码会被拒绝。
验证码一直提示错误时还能接着重试吗？
接着试的代价，是可能撞上次数上限被锁定。TOTP 的底层是另一份公开规范 RFC 4226 定义的 HOTP 算法。它要求码至少 6 位，也允许取 7 位或 8 位。6 位数字总共 100 万种组合，把运算结果截成这么短，暴力猜测就有了机会，所以它要求服务器能发现并拦住这种猜法。
建议的办法是给验证次数设上限：服务器逐次记下失败的尝试，上限在不明显妨碍正常使用的前提下尽量设低；次数用完，服务器应当锁定账户，并启动通知用户的程序。另一种可选的办法是每错一次，就让下一次多等一会儿。延迟也好、锁定也好，都要跨登录会话生效，目的是防住多路并行的猜测。
对不上的格数上限、验证次数上限各设成几，锁定之后怎么解开，由各个网站自己配置。码被拒了一次，就停下来把时间校好，等一个新码，只再输一次；仍然不过，走平台官方的客服或身份核验渠道，别继续往输入框里敲。
还有一种被拒和猜码无关。同一格里验证器给出的是同一个码，TOTP 的规范要求，一个码验证成功之后，网站不得再接受它第二次，这样才保证它只能用一次。登录时刚用过的码，紧接着的另一步验证又输它，照这条要求办的网站会把它拒掉。按 30 秒的步长，新码最多等 30 秒就出现。
iPhone 上同样先校准手机自身的时间
iPhone 上验证码一直提示错误，先看什么？
先校准 iPhone 自身的日期和时间，这一步安卓和 iPhone 都适用：验证器算码要用设备的当前时间，设备时间准了，算出的码才和网站那头一致。