基于动态口令的增强身份认证

章思宇， 黄保青， 白雪松， 姜开达

（上海交通大学网络信息中心，上海 200240）

0 引 言

基于静态口令的身份认证的脆弱性不言而喻，除了弱口令和暴力猜解的风险，用户口令在通过明文传输、不安全的终端输入等众多场景中都有可能被攻击者截获．尤其现在许多高校和企业都已建成统一身份认证体系，用户一个口令就能登录与之关联的各种信息系统，口令泄露的危害更大，而泄露的途径又随之增多，各种系统中不可避免地会存在FTP、POP3、SMTP等明文传输密码的应用．除此以外，口令泄露的风险也可能来自于外部，如果用户在互联网其他站点使用了相同的用户名和口令，那么任何一个站点的数据库泄露，都会威胁到用户在其他站点的账户安全，即所谓的“撞库”攻击．

动态口令，也称为一次性口令（One－Time Password，OTP），是只在一次登录会话有效的口令，能够规避传统密码的诸多弱点，尤其是可抵御重放攻击．实际应用中，动态口令通常作为静态口令的补充，成为多因子认证（或称为两步认证）的一部分［1，2］．

本文介绍开放标准的动态口令算法、基于动态口令的增强身份认证的实现，以及此方案在上海交通大学统一身份认证和网络信息中心内部系统中的应用．

1 动态口令算法

动态口令生成算法主要可以分为以下三类．

（1）哈希链：利用单向散列函数构建哈希链，由Lamport在1981年的文献［3］提出，新的口令由之前的口令验证；

（2）基于时间同步：认证服务器与客户端时间同步，口令根据时间和共享密钥生成；

（3）挑战应答：口令根据挑战数和共享密钥生成，挑战数由服务器随机生成，或者使用一个计数器值．

1．1 基于HMAC的OTP

HOTP是一种基于HMAC的OTP算法，也是OATH（Initiative For Open Authentication）的基础．OATH作为一个业界的合作组织，旨在利用开放的标准，开发并推广公开的强认证参考架构．

HOTP算法在IETF RFC4226［4］发布，HOTP值的计算基于HMAC－SHA－1算法，其输入是密钥K和计数器值C，算法定义为

其中，Truncate是将160 bit HMAC值转换为32 bit HOTP的函数．它以HMAC最后一个字节的低4位为偏移量（范围在0到15），取HMAC从该偏移量开始的4字节，返回低31 bit的值．Truncate将4字节的最高位置零，为了明确输出是一个无符号整数，避免歧义．

由于HOTP口令是6到8位十进制数，因此，上述过程产生的32 bit无符号整数值，还要取对10d的模后作为HOTP口令．这里d是HOTP口令位数．

HOTP每次使用时，计数器值C都会自增，从而每次产生的HOTP口令都不相同．HOTP的安全性基于HMAC－SHA－1算法的安全性．

1．2 基于时间的OTP

基于时间的TOTP算法在RFC6238［5］公布，它根据一个共享密钥和当前时间计算动态口令，算法基于HOTP，用时间戳取代计数器值．TOTP算法定义为

其中K是共享密钥，T代表初始时间T0到当前时间Tnow所经历的时间步长数：

默认的时间步长X＝30，即每30 s更换一个TOTP口令．Tnow和T0用UNIX时间戳表示，默认T0＝0．最后，同样根据口令位数d，将TOTP值取对10d的模后作为口令．

TOTP算法在公布后得到了广泛的应用，目前Google、Microsoft、Amazon、Facebook、GitHub、WordPress、Dropbox等网站账号的两步认证中都采用了TOTP标准的令牌．

1．3 TOTP验证与时间同步

在一个时间步长内生成的TOTP口令是不变的，但认证服务器收到客户端的口令时，并不知道客户端的准确时间戳．由于客户端的时钟漂移，以及用户输入和网络延迟，认证服务器必须设定策略，接受当前时间步长及其前后数个时间步长对应的口令．

首先，默认时间步长X＝30s是一个安全性和易用性的平衡，提高步长尺寸会向攻击者暴露更大的攻击时间窗口．并且，出于防止重放攻击的考虑，认证服务器不允许同一口令使用两次，因此，用户希望再次提交TOTP认证必须等到下一个时间窗．

认证服务器为了适应客户端令牌的时间漂移，可实现自动同步机制．假设认证服务器策略允许接受当前口令及其前后各2个时间步长的口令，那么认证服务器最多进行5次验证来确定用户提交的口令是否合法，允许约±1min的时间漂移．在验证通过之后，服务器记录检测到的时间漂移值，以漂移的时间步长数D表示．在该客户端下一次认证时，服务器以调整后的时间戳Tadj＝Tnow＋D·X作为基准进行TOTP验证．自动同步机制可以自动适应硬件令牌长时间使用过程中的累计时间漂移，而认证服务器及软件令牌的时间同步易于用NTP服务保证．

当硬件令牌长时间未使用，累计时间漂移已超过自动同步机制所能处理的阈值，则需要通过额外的步骤完成手动同步．在手动同步步骤中，认证服务器开放更大的验证窗口，而客户端则需要提供连续的多个TOTP口令供服务器校验，考虑到伪造连续多个TOTP口令比猜解一个TOTP值要困难得多．

2 TOTP身份认证系统实现

由于TOTP是一个开放的标准，基于TOTP实现动态口令身份认证系统在成本和兼容性上都有明显优势，有众多开源软件能够实现对TOTP的支持．

2．1 系统架构

在上海交通大学网络信息中心部署的动态口令认证系统，作为上海交通大学统一身份认证的一个安全扩展功能，对账户安全有较高要求的用户可选择启用基于TOTP的两步认证．而登录网络信息中心内部系统和VPN，则必须通过OTP认证．动态口令身份认证系统的架构如图1所示．

动态口令系统分为客户端（用户）所持有的动态口令令牌和服务器端的动态口令认证系统这两部分．对于启用了两步认证的统一认证账户，在通过Web界面单点登录时，除了输入用户名和静态口令以外，还会被要求输入动态口令．该认证系统提供基于HTTP的认证API：SSO在通过原有的基于LDAP的机制验证用户的静态口令之后，调用动态口令认证API，对用户输入的OTP进行验证．在进行关键的账户信息修改时（例如密码、绑定的手机号），也需要进行额外的OTP验证．

动态口令系统同时提供管理API，支持软件TOTP密钥生成、硬件令牌绑定等操作．管理与认证API通过SSL保护的HTTPS调用，并且，API服务器与SSO服务器之间通过共享密钥认证，以避免未经授权的第三方操作动态口令系统的API．

图1 动态口令身份认证系统架构

2．2 动态口令令牌

用户所持有的动态口令令牌分为软件令牌和硬件令牌两种．

TOTP作为一个开放的标准，在许多互联网服务中被采用，各个手机系统平台上都有支持TOTP算法的令牌软件．用户在统一身份认证管理界面中生成TOTP密钥（或称为种子）后，将该密钥输入到手机令牌软件（通常以十六进制或Base 32编码形式），即可通过该软件随时获取当前的TOTP口令．软件令牌的优势主要在于：1）无硬件成本；2）直接安装在手机软件中，无需携带额外令牌；3）手机可以自动校时，从而保证与认证服务器时间同步．

软件令牌在安全性上仍有欠缺，例如手机系统的不安全性可能造成TOTP密钥被窃取，密钥生成时必须明文显示给用户以输入到令牌软件中，该过程也可能造成密钥泄露．因此，硬件令牌的安全性相对较高，其密钥在生产时已经写入硬件内，难以读取，并且在绑定到用户账户时，只需输入硬件令牌编号，硬件令牌的密钥已经加密存储在认证服务器中，绑定过程不会泄露密钥．

上海交通大学的动态口令认证系统对软件和硬件令牌均提供支持，可由用户根据自己的需要选择．图2显示了同一个密钥在软件［6］和厂商定制的硬件令牌中生成的一致的口令值．

图2 软件与硬件令牌

2．3 RADIUS集成

基于Web的统一身份认证，在集成了动态口令系统之后，可以通过一个额外的密码文本框要求用户输入动态口令，而VPN等应用的客户端通常不支持两重口令的输入，因此，对于此类应用我们实现了一个定制的RADIUS服务器，用以支持静态口令和动态口令的组合认证．用户在VPN客户端登录时，在账户密码处，将自己的静态口令和当前的TOTP动态口令拼接成一个密码字串输入，形如“secret432555”．

PAP、CHAP和MS－CHAP是目前使用最广泛的密码认证协议，为了使集成了TOTP验证的RADIUS服务器支持上述认证方式，我们需要对静态口令在服务器端的存储方式作额外考虑．

PAP（Password Authentication Protocol）［7］认证的客户端将用户名和密码以明文形式发送给服务器，由于服务器可以得到原始的静态和动态口令字串，因而可以将拼接后的字串切分为静态和动态口令部分分别进行验证，服务器端对静态口令的存储，可以使用明文（或可逆加密）、散列或者带盐的散列形式，其中后者最为安全．PAP的风险在于中间人攻击可以截获客户端提交的明文口令，因此，若使用PAP认证登录VPN服务器，应首先通过SSL／TLS（如SSTP VPN）或预共享密钥（适用L2TP／IPsec VPN）验证服务器身份．

CHAP（Challenge－Handshake Authentication Protocol）［8］认证时，服务器向客户端发送挑战challenge及标识符id，客户端将标识符、口令和挑战值拼接后进行散列计算，作为应答返回给服务器，即MD5（id∥passphrase∥challenge）．在本系统中，passphrase为静态口令和动态口令拼接字串．为了验证口令的正确性，服务器必须保存有口令的明文形式．在与TOTP组合认证时，服务器计算所有接受窗口内的TOTP口令totpi，然后验证与之对应的MD5（id∥secret∥totpi∥challenge）是否与客户端的应答一致，这里secret是服务器端保存的明文的静态口令．

MS－CHAP是微软的CHAP版本，在挑战应答过程中，用户口令首先经过MD4散列计算，因此，服务器只需存储口令Unicode编码后的MD4散列（NT－Hash）．但是，在应用到集成了TOTP的认证系统时，由于服务器在进行验证时需要知道MD4（secret∥totp），因此，服务器必须保存明文的静态口令secret，方可根据目前可接受的TOTP口令计算当前合法的NT－Hash．

表1总结了为支持上述三种认证协议，RADIUS所能采用的静态口令存储方式．为同时实现三种协议的支持，用户的静态口令必须以明文或可逆加密形式保存．考虑到RADIUS服务器同时需要读取明文或可逆加密的TOTP密钥，两者具有同等的重要性，明文存储静态口令对整体的安全性影响有限．

表1 服务器端静态口令存储方式支持

动态口令认证系统的密钥存储必须得到有效保护，以避免静态口令和TOTP密钥泄露．我们定制开发的RADIUS服务器采用JAVA实现，用户的静态口令、TOTP密钥及参数存储在MySQL数据库中，并使用RSA加密保护．作为未来的改进方向，可考虑使用硬件安全模块（HSM）进行密钥存储的加密，以避免攻击者窃取加解密密钥．在我们的部署中，RADIUS仅作认证使用，与授权分离．此外，带有TOTP验证的RADIUS服务器，在每次认证时需要增加一次或多次HMAC－SHA－1计算（根据允许的时钟漂移窗口而定），但这部分额外开销对目前主流的服务器并不构成太大压力．

2．4 独立应用密码

在启用了基于动态口令的增强身份认证之后，由于一些应用的客户端软件并不支持动态口令输入，若要继续兼容这些应用，则可能开放绕过动态口令认证的漏洞．3．3节的VPN就是一个例子，我们通过定制的RADIUS服务器，解决了静态口令和动态口令组合输入的认证．然而，这一方法并不适用于所有的应用，一个典型的例子就是Email服务．动态口令保护了通过Web方式的邮箱访问，但攻击者获取了用户统一身份认证口令之后，仍能够通过POP3、IMAP等途径访问用户邮件．Email客户端需要频繁检查新邮件，若采用类似3．3节对VPN服务RADIUS的改造方式，用户每隔数分钟就需要输入一个新的OTP供Email客户端认证，显然是不合理的．

我们参考了微软和Google的解决方案，设计了针对这些客户端应用的独立应用密码，即针对邮件客户端等，专门生成一个不同于统一身份认证口令的专用的密码．该密码只能用于POP3／SMTP／IMAP协议的客户端认证，且不需要动态口令．由于独立应用密码是随机生成的，且仅保存于Email客户端中，潜在的泄露途径较少．并且，独立应用密码与特定应用绑定，例如Email客户端密码泄露仅影响电子邮件应用，攻击者不能使用该密码访问统一身份认证授权的其他服务．

此外，对于FTP等明文传输用户口令的协议，我们也提供独立应用密码的设定，以避免此类明文协议使用过程中暴露用户的统一身份认证口令．而3．3节中VPN系统所使用的静态口令也是独立应用密码的一个应用．

3 结 论

本文阐述了基于开放标准OATH－TOTP动态口令的增强身份认证在上海交通大学统一身份认证和VPN系统中的部署和应用，通过定制的RADIUS服务器实现了静态口令和动态口令的组合认证，并且同时支持硬件令牌和手机软件令牌．独立应用密码的设计为客户端软件提供向后兼容，防止绕过动态口令认证或明文协议泄露统一身份认证密码．引入动态口令双因子认证之后，可降低弱口令、暴力猜解和用户密码泄露后的账户风险，大幅提升统一身份认证及相关的应用系统的安全性．

［1］ O’GORMAN L．Comparing passwords，tokens，and biometrics for user authentication［J］．Proceedings of the IEEE，2003，91（12）：2021－2040．

［2］ BONNEAU J，HERLEY C，VAN OORSCHOT P C，et al．The quest to replace passwords：a framework for comparative evaluation of web authentication schemes［C］／／2012 IEEE Symposium on Security and Privacy．IEEE，2012：553－567．

［3］ LAMPORT L．Password authentication with insecure communication［J］．Communications of the ACM，1981，24（11）：770－772．

［4］ M’RAIHI D，BELLARE M，HOORNAERT F，et al．HOTP：An HMAC－based one－time password algorithm［DB／OL］．2005－12［2014－7－13］．http：／／tools．ietf．org／html／rfc4226．

［5］ M’RAIHI D，MACHANI S，PEI M，et al．TOTP：Time－based one－time password algorithm［DB／OL］．2011－5［2014－7－13］．http：／／tools．ietf．org／html／rfc6238．

［6］ SOPHOS GmbH．Sophos Authenticator［CP／OL］．（2014－7－8）［2014－7－28］．https：／／itunes．apple．com／us／app／sophos－authenticator／id864224575．

［7］ LLOYD B，SIMPSON W．PPP authentication protocols［DB／OL］．1992－10［2014－7－27］．http：／／tools．ietf．org／html／rfc1334．

［8］ SIMPSON W A．PPP challenge handshake authentication protocol（CHAP）［DB／OL］．1996－8［2014－7－27］．http：／／tools．ietf．org／html／rfc1994．