基于動(dòng)態(tài)口令的增強(qiáng)身份認(rèn)證

章思宇， 黃保青， 白雪松， 姜開(kāi)達(dá)

（上海交通大學(xué)網(wǎng)絡(luò)信息中心，上海 200240）

0 引 言

基于靜態(tài)口令的身份認(rèn)證的脆弱性不言而喻，除了弱口令和暴力猜解的風(fēng)險(xiǎn)，用戶口令在通過(guò)明文傳輸、不安全的終端輸入等眾多場(chǎng)景中都有可能被攻擊者截獲．尤其現(xiàn)在許多高校和企業(yè)都已建成統(tǒng)一身份認(rèn)證體系，用戶一個(gè)口令就能登錄與之關(guān)聯(lián)的各種信息系統(tǒng)，口令泄露的危害更大，而泄露的途徑又隨之增多，各種系統(tǒng)中不可避免地會(huì)存在FTP、POP3、SMTP等明文傳輸密碼的應(yīng)用．除此以外，口令泄露的風(fēng)險(xiǎn)也可能來(lái)自于外部，如果用戶在互聯(lián)網(wǎng)其他站點(diǎn)使用了相同的用戶名和口令，那么任何一個(gè)站點(diǎn)的數(shù)據(jù)庫(kù)泄露，都會(huì)威脅到用戶在其他站點(diǎn)的賬戶安全，即所謂的“撞庫(kù)”攻擊．

動(dòng)態(tài)口令，也稱為一次性口令（One－Time Password，OTP），是只在一次登錄會(huì)話有效的口令，能夠規(guī)避傳統(tǒng)密碼的諸多弱點(diǎn)，尤其是可抵御重放攻擊．實(shí)際應(yīng)用中，動(dòng)態(tài)口令通常作為靜態(tài)口令的補(bǔ)充，成為多因子認(rèn)證（或稱為兩步認(rèn)證）的一部分［1，2］．

本文介紹開(kāi)放標(biāo)準(zhǔn)的動(dòng)態(tài)口令算法、基于動(dòng)態(tài)口令的增強(qiáng)身份認(rèn)證的實(shí)現(xiàn)，以及此方案在上海交通大學(xué)統(tǒng)一身份認(rèn)證和網(wǎng)絡(luò)信息中心內(nèi)部系統(tǒng)中的應(yīng)用．

1 動(dòng)態(tài)口令算法

動(dòng)態(tài)口令生成算法主要可以分為以下三類．

（1）哈希鏈：利用單向散列函數(shù)構(gòu)建哈希鏈，由Lamport在1981年的文獻(xiàn)［3］提出，新的口令由之前的口令驗(yàn)證；

（2）基于時(shí)間同步：認(rèn)證服務(wù)器與客戶端時(shí)間同步，口令根據(jù)時(shí)間和共享密鑰生成；

（3）挑戰(zhàn)應(yīng)答：口令根據(jù)挑戰(zhàn)數(shù)和共享密鑰生成，挑戰(zhàn)數(shù)由服務(wù)器隨機(jī)生成，或者使用一個(gè)計(jì)數(shù)器值．

1．1 基于HMAC的OTP

HOTP是一種基于HMAC的OTP算法，也是OATH（Initiative For Open Authentication）的基礎(chǔ)．OATH作為一個(gè)業(yè)界的合作組織，旨在利用開(kāi)放的標(biāo)準(zhǔn)，開(kāi)發(fā)并推廣公開(kāi)的強(qiáng)認(rèn)證參考架構(gòu)．

HOTP算法在IETF RFC4226［4］發(fā)布，HOTP值的計(jì)算基于HMAC－SHA－1算法，其輸入是密鑰K和計(jì)數(shù)器值C，算法定義為

其中，Truncate是將160 bit HMAC值轉(zhuǎn)換為32 bit HOTP的函數(shù)．它以HMAC最后一個(gè)字節(jié)的低4位為偏移量（范圍在0到15），取HMAC從該偏移量開(kāi)始的4字節(jié)，返回低31 bit的值．Truncate將4字節(jié)的最高位置零，為了明確輸出是一個(gè)無(wú)符號(hào)整數(shù)，避免歧義．

由于HOTP口令是6到8位十進(jìn)制數(shù)，因此，上述過(guò)程產(chǎn)生的32 bit無(wú)符號(hào)整數(shù)值，還要取對(duì)10d的模后作為HOTP口令．這里d是HOTP口令位數(shù)．

HOTP每次使用時(shí)，計(jì)數(shù)器值C都會(huì)自增，從而每次產(chǎn)生的HOTP口令都不相同．HOTP的安全性基于HMAC－SHA－1算法的安全性．

1．2 基于時(shí)間的OTP

基于時(shí)間的TOTP算法在RFC6238［5］公布，它根據(jù)一個(gè)共享密鑰和當(dāng)前時(shí)間計(jì)算動(dòng)態(tài)口令，算法基于HOTP，用時(shí)間戳取代計(jì)數(shù)器值．TOTP算法定義為

其中K是共享密鑰，T代表初始時(shí)間T0到當(dāng)前時(shí)間Tnow所經(jīng)歷的時(shí)間步長(zhǎng)數(shù)：

默認(rèn)的時(shí)間步長(zhǎng)X＝30，即每30 s更換一個(gè)TOTP口令．Tnow和T0用UNIX時(shí)間戳表示，默認(rèn)T0＝0．最后，同樣根據(jù)口令位數(shù)d，將TOTP值取對(duì)10d的模后作為口令．

TOTP算法在公布后得到了廣泛的應(yīng)用，目前Google、Microsoft、Amazon、Facebook、GitHub、WordPress、Dropbox等網(wǎng)站賬號(hào)的兩步認(rèn)證中都采用了TOTP標(biāo)準(zhǔn)的令牌．

1．3 TOTP驗(yàn)證與時(shí)間同步

在一個(gè)時(shí)間步長(zhǎng)內(nèi)生成的TOTP口令是不變的，但認(rèn)證服務(wù)器收到客戶端的口令時(shí)，并不知道客戶端的準(zhǔn)確時(shí)間戳．由于客戶端的時(shí)鐘漂移，以及用戶輸入和網(wǎng)絡(luò)延遲，認(rèn)證服務(wù)器必須設(shè)定策略，接受當(dāng)前時(shí)間步長(zhǎng)及其前后數(shù)個(gè)時(shí)間步長(zhǎng)對(duì)應(yīng)的口令．

首先，默認(rèn)時(shí)間步長(zhǎng)X＝30s是一個(gè)安全性和易用性的平衡，提高步長(zhǎng)尺寸會(huì)向攻擊者暴露更大的攻擊時(shí)間窗口．并且，出于防止重放攻擊的考慮，認(rèn)證服務(wù)器不允許同一口令使用兩次，因此，用戶希望再次提交TOTP認(rèn)證必須等到下一個(gè)時(shí)間窗．

認(rèn)證服務(wù)器為了適應(yīng)客戶端令牌的時(shí)間漂移，可實(shí)現(xiàn)自動(dòng)同步機(jī)制．假設(shè)認(rèn)證服務(wù)器策略允許接受當(dāng)前口令及其前后各2個(gè)時(shí)間步長(zhǎng)的口令，那么認(rèn)證服務(wù)器最多進(jìn)行5次驗(yàn)證來(lái)確定用戶提交的口令是否合法，允許約±1min的時(shí)間漂移．在驗(yàn)證通過(guò)之后，服務(wù)器記錄檢測(cè)到的時(shí)間漂移值，以漂移的時(shí)間步長(zhǎng)數(shù)D表示．在該客戶端下一次認(rèn)證時(shí)，服務(wù)器以調(diào)整后的時(shí)間戳Tadj＝Tnow＋D·X作為基準(zhǔn)進(jìn)行TOTP驗(yàn)證．自動(dòng)同步機(jī)制可以自動(dòng)適應(yīng)硬件令牌長(zhǎng)時(shí)間使用過(guò)程中的累計(jì)時(shí)間漂移，而認(rèn)證服務(wù)器及軟件令牌的時(shí)間同步易于用NTP服務(wù)保證．

當(dāng)硬件令牌長(zhǎng)時(shí)間未使用，累計(jì)時(shí)間漂移已超過(guò)自動(dòng)同步機(jī)制所能處理的閾值，則需要通過(guò)額外的步驟完成手動(dòng)同步．在手動(dòng)同步步驟中，認(rèn)證服務(wù)器開(kāi)放更大的驗(yàn)證窗口，而客戶端則需要提供連續(xù)的多個(gè)TOTP口令供服務(wù)器校驗(yàn)，考慮到偽造連續(xù)多個(gè)TOTP口令比猜解一個(gè)TOTP值要困難得多．

2 TOTP身份認(rèn)證系統(tǒng)實(shí)現(xiàn)

由于TOTP是一個(gè)開(kāi)放的標(biāo)準(zhǔn)，基于TOTP實(shí)現(xiàn)動(dòng)態(tài)口令身份認(rèn)證系統(tǒng)在成本和兼容性上都有明顯優(yōu)勢(shì)，有眾多開(kāi)源軟件能夠?qū)崿F(xiàn)對(duì)TOTP的支持．

2．1 系統(tǒng)架構(gòu)

在上海交通大學(xué)網(wǎng)絡(luò)信息中心部署的動(dòng)態(tài)口令認(rèn)證系統(tǒng)，作為上海交通大學(xué)統(tǒng)一身份認(rèn)證的一個(gè)安全擴(kuò)展功能，對(duì)賬戶安全有較高要求的用戶可選擇啟用基于TOTP的兩步認(rèn)證．而登錄網(wǎng)絡(luò)信息中心內(nèi)部系統(tǒng)和VPN，則必須通過(guò)OTP認(rèn)證．動(dòng)態(tài)口令身份認(rèn)證系統(tǒng)的架構(gòu)如圖1所示．

動(dòng)態(tài)口令系統(tǒng)分為客戶端（用戶）所持有的動(dòng)態(tài)口令令牌和服務(wù)器端的動(dòng)態(tài)口令認(rèn)證系統(tǒng)這兩部分．對(duì)于啟用了兩步認(rèn)證的統(tǒng)一認(rèn)證賬戶，在通過(guò)Web界面單點(diǎn)登錄時(shí)，除了輸入用戶名和靜態(tài)口令以外，還會(huì)被要求輸入動(dòng)態(tài)口令．該認(rèn)證系統(tǒng)提供基于HTTP的認(rèn)證API：SSO在通過(guò)原有的基于LDAP的機(jī)制驗(yàn)證用戶的靜態(tài)口令之后，調(diào)用動(dòng)態(tài)口令認(rèn)證API，對(duì)用戶輸入的OTP進(jìn)行驗(yàn)證．在進(jìn)行關(guān)鍵的賬戶信息修改時(shí)（例如密碼、綁定的手機(jī)號(hào)），也需要進(jìn)行額外的OTP驗(yàn)證．

動(dòng)態(tài)口令系統(tǒng)同時(shí)提供管理API，支持軟件TOTP密鑰生成、硬件令牌綁定等操作．管理與認(rèn)證API通過(guò)SSL保護(hù)的HTTPS調(diào)用，并且，API服務(wù)器與SSO服務(wù)器之間通過(guò)共享密鑰認(rèn)證，以避免未經(jīng)授權(quán)的第三方操作動(dòng)態(tài)口令系統(tǒng)的API．

圖1 動(dòng)態(tài)口令身份認(rèn)證系統(tǒng)架構(gòu)

2．2 動(dòng)態(tài)口令令牌

用戶所持有的動(dòng)態(tài)口令令牌分為軟件令牌和硬件令牌兩種．

TOTP作為一個(gè)開(kāi)放的標(biāo)準(zhǔn)，在許多互聯(lián)網(wǎng)服務(wù)中被采用，各個(gè)手機(jī)系統(tǒng)平臺(tái)上都有支持TOTP算法的令牌軟件．用戶在統(tǒng)一身份認(rèn)證管理界面中生成TOTP密鑰（或稱為種子）后，將該密鑰輸入到手機(jī)令牌軟件（通常以十六進(jìn)制或Base 32編碼形式），即可通過(guò)該軟件隨時(shí)獲取當(dāng)前的TOTP口令．軟件令牌的優(yōu)勢(shì)主要在于：1）無(wú)硬件成本；2）直接安裝在手機(jī)軟件中，無(wú)需攜帶額外令牌；3）手機(jī)可以自動(dòng)校時(shí)，從而保證與認(rèn)證服務(wù)器時(shí)間同步．

軟件令牌在安全性上仍有欠缺，例如手機(jī)系統(tǒng)的不安全性可能造成TOTP密鑰被竊取，密鑰生成時(shí)必須明文顯示給用戶以輸入到令牌軟件中，該過(guò)程也可能造成密鑰泄露．因此，硬件令牌的安全性相對(duì)較高，其密鑰在生產(chǎn)時(shí)已經(jīng)寫(xiě)入硬件內(nèi)，難以讀取，并且在綁定到用戶賬戶時(shí)，只需輸入硬件令牌編號(hào)，硬件令牌的密鑰已經(jīng)加密存儲(chǔ)在認(rèn)證服務(wù)器中，綁定過(guò)程不會(huì)泄露密鑰．

上海交通大學(xué)的動(dòng)態(tài)口令認(rèn)證系統(tǒng)對(duì)軟件和硬件令牌均提供支持，可由用戶根據(jù)自己的需要選擇．圖2顯示了同一個(gè)密鑰在軟件［6］和廠商定制的硬件令牌中生成的一致的口令值．

圖2 軟件與硬件令牌

2．3 RADIUS集成

基于Web的統(tǒng)一身份認(rèn)證，在集成了動(dòng)態(tài)口令系統(tǒng)之后，可以通過(guò)一個(gè)額外的密碼文本框要求用戶輸入動(dòng)態(tài)口令，而VPN等應(yīng)用的客戶端通常不支持兩重口令的輸入，因此，對(duì)于此類應(yīng)用我們實(shí)現(xiàn)了一個(gè)定制的RADIUS服務(wù)器，用以支持靜態(tài)口令和動(dòng)態(tài)口令的組合認(rèn)證．用戶在VPN客戶端登錄時(shí)，在賬戶密碼處，將自己的靜態(tài)口令和當(dāng)前的TOTP動(dòng)態(tài)口令拼接成一個(gè)密碼字串輸入，形如“secret432555”．

PAP、CHAP和MS－CHAP是目前使用最廣泛的密碼認(rèn)證協(xié)議，為了使集成了TOTP驗(yàn)證的RADIUS服務(wù)器支持上述認(rèn)證方式，我們需要對(duì)靜態(tài)口令在服務(wù)器端的存儲(chǔ)方式作額外考慮．

PAP（Password Authentication Protocol）［7］認(rèn)證的客戶端將用戶名和密碼以明文形式發(fā)送給服務(wù)器，由于服務(wù)器可以得到原始的靜態(tài)和動(dòng)態(tài)口令字串，因而可以將拼接后的字串切分為靜態(tài)和動(dòng)態(tài)口令部分分別進(jìn)行驗(yàn)證，服務(wù)器端對(duì)靜態(tài)口令的存儲(chǔ)，可以使用明文（或可逆加密）、散列或者帶鹽的散列形式，其中后者最為安全．PAP的風(fēng)險(xiǎn)在于中間人攻擊可以截獲客戶端提交的明文口令，因此，若使用PAP認(rèn)證登錄VPN服務(wù)器，應(yīng)首先通過(guò)SSL／TLS（如SSTP VPN）或預(yù)共享密鑰（適用L2TP／IPsec VPN）驗(yàn)證服務(wù)器身份．

CHAP（Challenge－Handshake Authentication Protocol）［8］認(rèn)證時(shí)，服務(wù)器向客戶端發(fā)送挑戰(zhàn)challenge及標(biāo)識(shí)符id，客戶端將標(biāo)識(shí)符、口令和挑戰(zhàn)值拼接后進(jìn)行散列計(jì)算，作為應(yīng)答返回給服務(wù)器，即MD5（id∥passphrase∥challenge）．在本系統(tǒng)中，passphrase為靜態(tài)口令和動(dòng)態(tài)口令拼接字串．為了驗(yàn)證口令的正確性，服務(wù)器必須保存有口令的明文形式．在與TOTP組合認(rèn)證時(shí)，服務(wù)器計(jì)算所有接受窗口內(nèi)的TOTP口令totpi，然后驗(yàn)證與之對(duì)應(yīng)的MD5（id∥secret∥totpi∥challenge）是否與客戶端的應(yīng)答一致，這里secret是服務(wù)器端保存的明文的靜態(tài)口令．

MS－CHAP是微軟的CHAP版本，在挑戰(zhàn)應(yīng)答過(guò)程中，用戶口令首先經(jīng)過(guò)MD4散列計(jì)算，因此，服務(wù)器只需存儲(chǔ)口令Unicode編碼后的MD4散列（NT－Hash）．但是，在應(yīng)用到集成了TOTP的認(rèn)證系統(tǒng)時(shí)，由于服務(wù)器在進(jìn)行驗(yàn)證時(shí)需要知道MD4（secret∥totp），因此，服務(wù)器必須保存明文的靜態(tài)口令secret，方可根據(jù)目前可接受的TOTP口令計(jì)算當(dāng)前合法的NT－Hash．

表1總結(jié)了為支持上述三種認(rèn)證協(xié)議，RADIUS所能采用的靜態(tài)口令存儲(chǔ)方式．為同時(shí)實(shí)現(xiàn)三種協(xié)議的支持，用戶的靜態(tài)口令必須以明文或可逆加密形式保存．考慮到RADIUS服務(wù)器同時(shí)需要讀取明文或可逆加密的TOTP密鑰，兩者具有同等的重要性，明文存儲(chǔ)靜態(tài)口令對(duì)整體的安全性影響有限．

表1 服務(wù)器端靜態(tài)口令存儲(chǔ)方式支持

動(dòng)態(tài)口令認(rèn)證系統(tǒng)的密鑰存儲(chǔ)必須得到有效保護(hù)，以避免靜態(tài)口令和TOTP密鑰泄露．我們定制開(kāi)發(fā)的RADIUS服務(wù)器采用JAVA實(shí)現(xiàn)，用戶的靜態(tài)口令、TOTP密鑰及參數(shù)存儲(chǔ)在MySQL數(shù)據(jù)庫(kù)中，并使用RSA加密保護(hù)．作為未來(lái)的改進(jìn)方向，可考慮使用硬件安全模塊（HSM）進(jìn)行密鑰存儲(chǔ)的加密，以避免攻擊者竊取加解密密鑰．在我們的部署中，RADIUS僅作認(rèn)證使用，與授權(quán)分離．此外，帶有TOTP驗(yàn)證的RADIUS服務(wù)器，在每次認(rèn)證時(shí)需要增加一次或多次HMAC－SHA－1計(jì)算（根據(jù)允許的時(shí)鐘漂移窗口而定），但這部分額外開(kāi)銷對(duì)目前主流的服務(wù)器并不構(gòu)成太大壓力．

2．4 獨(dú)立應(yīng)用密碼

在啟用了基于動(dòng)態(tài)口令的增強(qiáng)身份認(rèn)證之后，由于一些應(yīng)用的客戶端軟件并不支持動(dòng)態(tài)口令輸入，若要繼續(xù)兼容這些應(yīng)用，則可能開(kāi)放繞過(guò)動(dòng)態(tài)口令認(rèn)證的漏洞．3．3節(jié)的VPN就是一個(gè)例子，我們通過(guò)定制的RADIUS服務(wù)器，解決了靜態(tài)口令和動(dòng)態(tài)口令組合輸入的認(rèn)證．然而，這一方法并不適用于所有的應(yīng)用，一個(gè)典型的例子就是Email服務(wù)．動(dòng)態(tài)口令保護(hù)了通過(guò)Web方式的郵箱訪問(wèn)，但攻擊者獲取了用戶統(tǒng)一身份認(rèn)證口令之后，仍能夠通過(guò)POP3、IMAP等途徑訪問(wèn)用戶郵件．Email客戶端需要頻繁檢查新郵件，若采用類似3．3節(jié)對(duì)VPN服務(wù)RADIUS的改造方式，用戶每隔數(shù)分鐘就需要輸入一個(gè)新的OTP供Email客戶端認(rèn)證，顯然是不合理的．

我們參考了微軟和Google的解決方案，設(shè)計(jì)了針對(duì)這些客戶端應(yīng)用的獨(dú)立應(yīng)用密碼，即針對(duì)郵件客戶端等，專門生成一個(gè)不同于統(tǒng)一身份認(rèn)證口令的專用的密碼．該密碼只能用于POP3／SMTP／IMAP協(xié)議的客戶端認(rèn)證，且不需要?jiǎng)討B(tài)口令．由于獨(dú)立應(yīng)用密碼是隨機(jī)生成的，且僅保存于Email客戶端中，潛在的泄露途徑較少．并且，獨(dú)立應(yīng)用密碼與特定應(yīng)用綁定，例如Email客戶端密碼泄露僅影響電子郵件應(yīng)用，攻擊者不能使用該密碼訪問(wèn)統(tǒng)一身份認(rèn)證授權(quán)的其他服務(wù)．

此外，對(duì)于FTP等明文傳輸用戶口令的協(xié)議，我們也提供獨(dú)立應(yīng)用密碼的設(shè)定，以避免此類明文協(xié)議使用過(guò)程中暴露用戶的統(tǒng)一身份認(rèn)證口令．而3．3節(jié)中VPN系統(tǒng)所使用的靜態(tài)口令也是獨(dú)立應(yīng)用密碼的一個(gè)應(yīng)用．

3 結(jié) 論

本文闡述了基于開(kāi)放標(biāo)準(zhǔn)OATH－TOTP動(dòng)態(tài)口令的增強(qiáng)身份認(rèn)證在上海交通大學(xué)統(tǒng)一身份認(rèn)證和VPN系統(tǒng)中的部署和應(yīng)用，通過(guò)定制的RADIUS服務(wù)器實(shí)現(xiàn)了靜態(tài)口令和動(dòng)態(tài)口令的組合認(rèn)證，并且同時(shí)支持硬件令牌和手機(jī)軟件令牌．獨(dú)立應(yīng)用密碼的設(shè)計(jì)為客戶端軟件提供向后兼容，防止繞過(guò)動(dòng)態(tài)口令認(rèn)證或明文協(xié)議泄露統(tǒng)一身份認(rèn)證密碼．引入動(dòng)態(tài)口令雙因子認(rèn)證之后，可降低弱口令、暴力猜解和用戶密碼泄露后的賬戶風(fēng)險(xiǎn)，大幅提升統(tǒng)一身份認(rèn)證及相關(guān)的應(yīng)用系統(tǒng)的安全性．

［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．a(chǎn)pple．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．