基于时间的一次性密码算法

TOTP基于HOTP，附带的时间戳用于替代递增计数器。

通过定义一个纪元（epoch, T0）的起点并以时间步骤（time step, TS）为单位进行计数，当前时间戳被转换成一个整形数值的时间计数器（time-counter, TC）。举一个例子：

TC = 最低值((unixtime(当前时间)−unixtime(T0))/TS)，

TOTP = HOTP(密钥, TC),

TOTP-值 = TOTP mod 10^d，d 是所需的一次性密码的位数。

根据RFC 6238标准，供参考的实现如下：

• 生成一个任意字节的字符串密钥K，与客户端安全地共享。
• 基于T0的协商后，Unix时间从时间间隔（TI）开始计数时间步骤，TI则用于计算计数器C（默认情况下TI的数值是T0和30秒）的数值
• 协商加密哈希算法（默认为SHA-1）
• 协商密码长度（默认6位）

尽管RFC 6238标准允许使用不同的参数，Google开发的验证应用不允许不同于默认的T0、TI值、哈希方法和密码长度。RFC 3548也同时鼓励K密钥以base-32编码输入（或以QR码的形式提供）。[2]

一旦参数协商完毕，密码开始按照如下方法生成：

1. 从T0开始已经过的时间，每个TI为一个单位，总数记为C。
   
2. 使用C作为消息，K作为密钥，计算HMAC哈希值H（定义来自之前的HMAC算法，但是大部分加密算法库都有支持）。K应当保持原样继续传递，C应当以64位的原始无符号的整形数值传递。
3. 取H中有意义最后4位数的作为弥补，记为O。
4. 取H当中的4位，从O字节MSB开始，丢弃最高有效位，将剩余位储存为（无符号）的32位整形数值I。
5. 密码即为基数为10的最低N位数。如果结果位数少于N，从左边开始用0补全。

服务器与客户端都会计算密码，但是由服务器来检查客户端提供的密码是否匹配服务器本地生成的密码。考虑到轻微的时钟偏移、网络延迟或用户延误等情况，有些服务器允许接受本应该在早先已生成或稍后才生成的密码。

尽管攻击者需要实时代管凭证，而不能之后收集，但是TOTP代号跟密码一样可能被钓鱼。

不限制登录尝试的TOTP实现容易被暴力破解，因此尝试次数限制必须非常少。

窃取到预共享密钥的攻击者可以随意生成新的非法的TOTP代号。如果攻击者攻破大型的认证数据库，这就会是个问题。[3]

由于TOTP设备可能会发生电力用尽、时钟不同步等情况，用户手机上的软件也可能丢失或失窃，所有现存的实现都可以绕开相应保护（如：打印的代码、电子邮件重置等），这对于大型用户群支持来说是个负担，并给了欺诈用户更多的操作空间。

TOTP代号的有效期会长于屏幕上显示的时间（通常是2倍或更长）。这是对认证双方的时钟可能有较大幅度偏移而作出的让步。

所有基于一次性密码的认证方案（包括TOTP、HOTP和其他方案）都会暴露于会话劫持当中，比如可以在登录后强征用户的会话。

尽管如此，TOTP仍然比单独使用传统静态密码验证的安全性强很多。上述的一些问题也可以通过简单的方法解决（比如为防止暴力破解，可以增加TOTP的位数，或者使用多个TOTP同时验证）。

TOTP草案由数位OATH成员合作开发，目的是创建一个行业通用标准。它完善了基于事件的一次性标准HOTP，并为终端用户组织和企业在选择最适合的应用要求与安全规范技术提供了更多选择。2008年，OATH向IETF提交了一份草案规范。这一版本的草案以之前提交的版本为基础，包含作者从技术社区收到的全部反馈与评论。[4]2011年5月，TOTP正式成为RFC 6238标准的一部分。