本發(fā)明涉及一種身份認(rèn)證方法，特別是涉及一種用于hadoop集群的身份認(rèn)證方法。

背景技術(shù)：

早期，hadoop(hadoop是一個(gè)由apache基金會(huì)所開發(fā)的分布式系統(tǒng)基礎(chǔ)架構(gòu))集群的初始用途是管理大量的公共web數(shù)據(jù)，因此數(shù)據(jù)安全性和隱私并不是最初設(shè)計(jì)的考慮因素。設(shè)計(jì)時(shí)總是假定hadoop集群將會(huì)由相互協(xié)作的、可信的機(jī)器組成，并由在可信環(huán)境中的可信用戶使用。因此hadoop不認(rèn)證用戶或服務(wù)，沒有數(shù)據(jù)隱私，任何人都可以提交執(zhí)行代碼。

后來隨著hadoop成為一個(gè)更加流行的大數(shù)據(jù)分析平臺(tái)，hadoop開發(fā)社區(qū)意識(shí)到有必要為hadoop增添更加健壯的安全控制。開發(fā)人員選擇了kerberos作為hadoop集群的基礎(chǔ)身份認(rèn)證機(jī)制。雖然kerberos認(rèn)證具有實(shí)現(xiàn)簡(jiǎn)單、可靠性好、性能優(yōu)越等諸多優(yōu)點(diǎn)，但是安全性上也具有以下兩個(gè)較明顯的弱點(diǎn)：

一、系統(tǒng)的安全性完全基于用戶口令和對(duì)稱加密算法，用戶口令需要存儲(chǔ)在身份認(rèn)證服務(wù)器的數(shù)據(jù)庫中，管理員等高權(quán)限用戶可以查看任何用戶的口令。

二、由于系統(tǒng)安全性很大程度上取決于用戶口令的復(fù)雜度，因此不可避免的容易遭受弱口令攻擊。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明所要解決的技術(shù)問題是提供一種用于hadoop集群的身份認(rèn)證方法，其能夠大大降低系統(tǒng)遭受弱口令攻擊的風(fēng)險(xiǎn)。

本發(fā)明是通過下述技術(shù)方案來解決上述技術(shù)問題的：一種用于hadoop集群的身份認(rèn)證方法，其特征在于，其包括如下步驟：

步驟一，客戶端向認(rèn)證服務(wù)器發(fā)送請(qǐng)求，請(qǐng)求獲得票據(jù)許可票據(jù)：先以明文方式向認(rèn)證服務(wù)器發(fā)出請(qǐng)求；請(qǐng)求報(bào)文包括用戶名稱、授權(quán)服務(wù)器名稱、有效生存期限、第一隨機(jī)數(shù)和用戶所在的kerberos領(lǐng)域用戶信息；

步驟二，認(rèn)證服務(wù)器收到客戶端的請(qǐng)求報(bào)文后，先根據(jù)用戶名稱在本地?cái)?shù)據(jù)庫中查找用戶密鑰，如果查找成功，則認(rèn)證繼續(xù)；

步驟三，認(rèn)證服務(wù)器生成會(huì)話密鑰，該會(huì)話密鑰用于客戶端和授權(quán)服務(wù)器之間的加密通信；

步驟四，認(rèn)證服務(wù)器產(chǎn)生用戶請(qǐng)求的授權(quán)服務(wù)器的票據(jù)許可票據(jù)，該票據(jù)包括用戶名稱、授權(quán)服務(wù)器名稱、用戶ip、隨機(jī)數(shù)、有效生存期限以及會(huì)話密鑰，并用授權(quán)服務(wù)器的密鑰進(jìn)行加密，以保證只有授權(quán)服務(wù)器才能解密；

步驟五，認(rèn)證服務(wù)器發(fā)送應(yīng)答報(bào)文，該報(bào)文包括票據(jù)許可票據(jù)和用戶密鑰加密的信息；

步驟六，當(dāng)客戶端收到認(rèn)證服務(wù)器返回的應(yīng)答報(bào)文后，使用用戶密鑰進(jìn)行解密，得到會(huì)話密鑰，客戶端向授權(quán)服務(wù)器發(fā)送訪問hadoop應(yīng)用服務(wù)器的請(qǐng)求報(bào)文，請(qǐng)求獲得服務(wù)許可票據(jù)：

報(bào)文內(nèi)容包括要訪問的hadoop應(yīng)用服務(wù)器的名稱、有效生存期限、第二隨機(jī)數(shù)、票據(jù)許可票據(jù)、第一認(rèn)證符，第一認(rèn)證符用會(huì)話密鑰進(jìn)行加密，包括用戶名稱、用戶所在的kerberos領(lǐng)域以及時(shí)間戳；

步驟七，授權(quán)服務(wù)器收到客戶端發(fā)來的請(qǐng)求報(bào)文后，用自己的授權(quán)服務(wù)器的密鑰對(duì)票據(jù)許可票據(jù)進(jìn)行解密處理，該票據(jù)的含義為“使用會(huì)話密鑰的客戶是c”，授權(quán)服務(wù)器用從票據(jù)許可票據(jù)中取出的會(huì)話密鑰解密第一認(rèn)證符，并將第一認(rèn)證符中的數(shù)據(jù)與票據(jù)許可票據(jù)中的數(shù)據(jù)進(jìn)行比較，從而可以相信票據(jù)許可票據(jù)的發(fā)送者用戶就是票據(jù)許可票據(jù)的實(shí)際持有者；

步驟八，授權(quán)服務(wù)器驗(yàn)證用戶的合法身份之后，生成隨機(jī)會(huì)話密鑰，該隨機(jī)會(huì)話密鑰用于客戶端和hadoop應(yīng)用服務(wù)器之間的加密通信；

步驟九，授權(quán)服務(wù)器產(chǎn)生用于訪問hadoop應(yīng)用服務(wù)器的服務(wù)許可票據(jù)，服務(wù)許可票據(jù)包括用戶名稱、hadoop應(yīng)用服務(wù)器名稱、用戶ip、有效生存期限和隨機(jī)會(huì)話密鑰，并用hadoop應(yīng)用服務(wù)器的密鑰來加密，以保證只有hadoop應(yīng)用服務(wù)器才能解得開；

步驟十，授權(quán)服務(wù)器發(fā)送應(yīng)答報(bào)文，該應(yīng)答報(bào)文包括服務(wù)許可票據(jù)和會(huì)話密鑰加密的信息；

步驟十一，當(dāng)客戶端收到授權(quán)服務(wù)器的應(yīng)答報(bào)文后，用會(huì)話密鑰解密得到會(huì)話密鑰；

步驟十二，客戶端向hadoop應(yīng)用服務(wù)器發(fā)送請(qǐng)求報(bào)文，該請(qǐng)求報(bào)文的內(nèi)容包括hadoop應(yīng)用服務(wù)器名稱、用于訪問hadoop應(yīng)用服務(wù)器的服務(wù)許可票據(jù)以及用隨機(jī)會(huì)話密鑰加密的第二認(rèn)證符；

步驟十三，hadoop應(yīng)用服務(wù)器收到客戶端發(fā)來的請(qǐng)求報(bào)文后，用自己的密鑰對(duì)服務(wù)許可票據(jù)進(jìn)行解密，得到隨機(jī)會(huì)話密鑰來解密第二認(rèn)證符，并將解密后的第二認(rèn)證符中的數(shù)據(jù)與服務(wù)許可票據(jù)中的數(shù)據(jù)進(jìn)行比較，用戶的身份得到驗(yàn)證；

步驟十四，hadoop應(yīng)用服務(wù)器向客戶端發(fā)送應(yīng)答報(bào)文，包括用隨機(jī)會(huì)話密鑰加密的用戶名稱用戶信息；

步驟十五，當(dāng)客戶端收到信息后，解密信息并確認(rèn)hadoop應(yīng)用服務(wù)器的身份后，認(rèn)證結(jié)束。

優(yōu)選地，所述步驟一的客戶端向認(rèn)證服務(wù)器發(fā)送票據(jù)許可票據(jù)申請(qǐng)請(qǐng)求時(shí)，在一個(gè)as_req消息中增加一下skprv-c字段，該字段是客戶端使用自己的私鑰采用非對(duì)稱簽名算法對(duì)消息內(nèi)容的簽名；認(rèn)證服務(wù)器收到客戶端的請(qǐng)求報(bào)文后，先根據(jù)用戶名稱在本地?cái)?shù)據(jù)庫中查找用戶的公鑰，并對(duì)消息內(nèi)容進(jìn)行驗(yàn)簽運(yùn)算，如果驗(yàn)簽通過，則認(rèn)證繼續(xù)；認(rèn)證服務(wù)器生成會(huì)話密鑰，該會(huì)話密鑰用于客戶端和授權(quán)服務(wù)器之間的加密通信；認(rèn)證服務(wù)器產(chǎn)生用戶請(qǐng)求的授權(quán)服務(wù)器的票據(jù)許可票據(jù)，該票據(jù)包括用戶名稱、授權(quán)服務(wù)器名稱、用戶ip、隨機(jī)數(shù)、有效生存期限以及會(huì)話密鑰用戶，并用授權(quán)服務(wù)器的密鑰進(jìn)行加密生成tickettgs，以保證tickettgs只有授權(quán)服務(wù)器才能解密；用用戶的公鑰加密另外一份包含會(huì)話秘鑰的信息ekpub-c；認(rèn)證服務(wù)器再對(duì)整個(gè)消息用自己的私鑰簽名生成skprv-as，并返回應(yīng)答報(bào)文，該應(yīng)答報(bào)文被用戶接收到后，用戶先用預(yù)先保存的認(rèn)證服務(wù)器公鑰驗(yàn)證簽名，驗(yàn)簽通過后，再用自己的私鑰解密得到會(huì)話秘鑰后續(xù)流程需要用到的信息。

優(yōu)選地，所述步驟一至步驟五是關(guān)于認(rèn)證服務(wù)器向用戶發(fā)放票據(jù)許可票據(jù)，步驟六至步驟十是關(guān)于授權(quán)服務(wù)器向用戶發(fā)放服務(wù)許可票據(jù)，所述步驟十一至步驟十五是關(guān)于用戶向應(yīng)用服務(wù)器獲取服務(wù)。

優(yōu)選地，所述用于hadoop集群的身份認(rèn)證方法通過稱為密鑰分發(fā)中心的第三方服務(wù)來驗(yàn)證集群中實(shí)體的相互身份，并建立密鑰以保證實(shí)體間的安全連接。

本發(fā)明的積極進(jìn)步效果在于：

一，本發(fā)明由于采用了基于pki的認(rèn)證模式后，無需在kdc上保存用戶的口令，減少了系統(tǒng)的風(fēng)險(xiǎn)點(diǎn)，這樣大大提高了hadoop集群身份認(rèn)證的安全性。

二，由于本發(fā)明改造的是hadoop集群身份認(rèn)證中執(zhí)行頻率非常低的as_req和as_req流程，因此對(duì)系統(tǒng)的性能幾乎沒有什么影響。

三，系統(tǒng)認(rèn)證采用雙因子模式后，可以大大降低弱口令攻擊的風(fēng)險(xiǎn)，對(duì)hadoop集群的安全性也是一個(gè)比較明顯的提升。

附圖說明

圖1為本發(fā)明的標(biāo)準(zhǔn)認(rèn)證流程示意圖。

圖2為本發(fā)明基于pki的認(rèn)證流程部分示意圖。

具體實(shí)施方式

下面結(jié)合附圖給出本發(fā)明較佳實(shí)施例，以詳細(xì)說明本發(fā)明的技術(shù)方案。

本發(fā)明通過稱為kdc(keydistributioncenter，密鑰分發(fā)中心)的第三方服務(wù)來驗(yàn)證集群中實(shí)體的相互身份，并建立密鑰以保證實(shí)體間的安全連接。kdc由認(rèn)證服務(wù)器as和授權(quán)服務(wù)器tgs兩部分組成。kerberos(kerberos是古希臘神話中守衛(wèi)地獄入口狗，長(zhǎng)著三個(gè)頭。mit麻省理工學(xué)院之所以將其認(rèn)證協(xié)議命名為kerberos，是因?yàn)樗麄冇?jì)劃通過認(rèn)證、授權(quán)和審計(jì)三個(gè)方面來建立完善的安全機(jī)制)認(rèn)證系統(tǒng)總共包括三個(gè)相關(guān)方：認(rèn)證服務(wù)器as，用于在登錄時(shí)驗(yàn)證用戶的身份并發(fā)放票據(jù)許可票據(jù)tgt；授權(quán)服務(wù)器tgs，用于發(fā)放服務(wù)許可票據(jù)ts；hadoop應(yīng)用服務(wù)器v，客戶端請(qǐng)求工作的實(shí)際執(zhí)行者。在執(zhí)行具體的認(rèn)證流程前，系統(tǒng)需要做必要的初始化?？蛻舳耸紫刃枰趉dc做開戶操作，將自己的口令及基礎(chǔ)信息保存到kdc的數(shù)據(jù)庫中，之后才能完成后續(xù)的認(rèn)證。

如圖1所示，本發(fā)明用于hadoop集群的身份認(rèn)證方法包括如下步驟：

步驟一，客戶端向認(rèn)證服務(wù)器發(fā)送請(qǐng)求，請(qǐng)求獲得票據(jù)許可票據(jù)tgt：

c→as：as_req＝{idc，idtgs，times，nounce1，realmc，options}

as→c：as_rep＝{realmc，idc，tickettgs，ekc(kc,tgs，times，nounce1，realmtgs，idtgs)}tickettgs＝ektgs(

realmc，idc，idtgs，ipc，times，kc,tgs，flags)

先以明文方式向認(rèn)證服務(wù)器發(fā)出請(qǐng)求，請(qǐng)求報(bào)文包括用戶名稱、授權(quán)服務(wù)器名稱、有效生存期限、第一隨機(jī)數(shù)和用戶所在的kerberos領(lǐng)域等信息；

步驟二，認(rèn)證服務(wù)器收到客戶端的請(qǐng)求報(bào)文后，先根據(jù)用戶名稱在本地?cái)?shù)據(jù)庫中查找用戶密鑰kc，如果查找成功，則認(rèn)證繼續(xù)；

步驟三，認(rèn)證服務(wù)器生成會(huì)話密鑰kc,tgs，該會(huì)話密鑰用于客戶端和授權(quán)服務(wù)器之間的加密通信；

步驟四，認(rèn)證服務(wù)器產(chǎn)生用戶請(qǐng)求的授權(quán)服務(wù)器的票據(jù)許可票據(jù)tgt，該票據(jù)包括用戶名稱、授權(quán)服務(wù)器名稱、用戶ip、隨機(jī)數(shù)、有效生存期限以及會(huì)話密鑰kc,tgs等，并用授權(quán)服務(wù)器的密鑰ktgs進(jìn)行加密，以保證只有授權(quán)服務(wù)器才能解密；

步驟五，認(rèn)證服務(wù)器發(fā)送應(yīng)答報(bào)文，該報(bào)文包括票據(jù)許可票據(jù)tgt和用戶密鑰kc加密的信息；

步驟六，當(dāng)客戶端收到認(rèn)證服務(wù)器返回的應(yīng)答報(bào)文后，使用用戶密鑰kc進(jìn)行解密，得到會(huì)話密鑰kc,tgs，客戶端向授權(quán)服務(wù)器發(fā)送訪問hadoop應(yīng)用服務(wù)器的請(qǐng)求報(bào)文，請(qǐng)求獲得服務(wù)許可票據(jù)ts：

c→tgs：tgs_req＝{idv，times，nounce2，tickettgs，authenticator1，options}

authenticator1＝ekc,tgs(idc，realmc，ts1)

tgs→c：tgs_rep＝realmc，idc，ticketv，ekc,tgs(kc,v，times，nounce2，realmv，idv)}

ticketv＝ekv(idc，idv，ipc，times，kc,v，realmc，flags)

報(bào)文內(nèi)容包括要訪問的hadoop應(yīng)用服務(wù)器的名稱、有效生存期限、第二隨機(jī)數(shù)、tgt、第一認(rèn)證符等，第一認(rèn)證符用會(huì)話密鑰kc,tgs進(jìn)行加密，包括用戶名稱、用戶所在的kerberos領(lǐng)域以及時(shí)間戳；

步驟七，授權(quán)服務(wù)器收到客戶端發(fā)來的請(qǐng)求報(bào)文后，用自己的密鑰ktgs對(duì)票據(jù)tgt進(jìn)行解密處理，該票據(jù)的含義為“使用會(huì)話秘鑰kc,tgs的客戶是c”，授權(quán)服務(wù)器用從票據(jù)許可票據(jù)tgt中取出的會(huì)話密鑰kc,tgs解密第一認(rèn)證符，并將第一認(rèn)證符中的數(shù)據(jù)與票據(jù)許可票據(jù)tgt中的數(shù)據(jù)進(jìn)行比較，從而可以相票據(jù)許可票據(jù)信tgt的發(fā)送者用戶就是票據(jù)許可票據(jù)tgt的實(shí)際持有者；

步驟八，授權(quán)服務(wù)器驗(yàn)證用戶的合法身份之后，生成隨機(jī)會(huì)話密鑰kc,v，該密鑰用于客戶端和hadoop應(yīng)用服務(wù)器之間的加密通信；

步驟九，授權(quán)服務(wù)器產(chǎn)生用于訪問hadoop應(yīng)用服務(wù)器的服務(wù)許可票據(jù)ts，服務(wù)許可票據(jù)ts包括用戶名稱、hadoop應(yīng)用服務(wù)器名稱、用戶ip、有效生存期限和隨機(jī)會(huì)話密鑰kc,v等，并用hadoop應(yīng)用服務(wù)器的密鑰kv來加密，以保證只有hadoop應(yīng)用服務(wù)器才能解得開；

步驟十，授權(quán)服務(wù)器發(fā)送應(yīng)答報(bào)文，該報(bào)文包括服務(wù)許可票據(jù)ts和會(huì)話密鑰kc,tgs加密的信息；

步驟十一，當(dāng)客戶端收到授權(quán)服務(wù)器的應(yīng)答報(bào)文tgs_rep后，用會(huì)話密鑰kc,tgs解密得到隨機(jī)會(huì)話密鑰kc,v；

步驟十二，客戶端向hadoop應(yīng)用服務(wù)器發(fā)送請(qǐng)求報(bào)文ap_req：

c→v：ap_req＝{options，ticketv，authenticator2}authenticator2＝ekc,v(idc，realmc，ts2，subkey，seq#)

v→c：ap_rep＝{ekc,v(idc)，realmc，ts2，subkey，seq#}

報(bào)文內(nèi)容包括hadoop應(yīng)用服務(wù)器名稱、用于訪問hadoop應(yīng)用服務(wù)器的服務(wù)許可票據(jù)ts以及用隨機(jī)會(huì)話密鑰kc,v加密的第二認(rèn)證符；

步驟十三，hadoop應(yīng)用服務(wù)器收到客戶端發(fā)來的請(qǐng)求報(bào)文tgs_rep后，用自己的密鑰對(duì)服務(wù)許可票據(jù)ts進(jìn)行解密，得到隨機(jī)會(huì)話密鑰kc,v來解密第二認(rèn)證符，并將解密后的第二認(rèn)證符中的數(shù)據(jù)與票據(jù)ts中的數(shù)據(jù)進(jìn)行比較，用戶的身份得到驗(yàn)證；

步驟十四，hadoop應(yīng)用服務(wù)器向客戶端發(fā)送應(yīng)答報(bào)文，包括用隨機(jī)會(huì)話密鑰kc,v加密的用戶名稱等信息；

步驟十五，當(dāng)客戶端收到信息后，解密信息并確認(rèn)hadoop應(yīng)用服務(wù)器的身份后，認(rèn)證結(jié)束。

為了實(shí)現(xiàn)無需在kdc上存儲(chǔ)用戶口令，保證用戶口令除了用戶自己外，沒有任何人能夠知曉，本發(fā)明主要針對(duì)上述標(biāo)準(zhǔn)認(rèn)證流程中的步驟一至步驟五(as_req和as_rep)進(jìn)行改進(jìn)，改進(jìn)的措施主要是采用pki(publickeyinfrastructure)即公開密鑰體系來替換原來基于對(duì)稱算法和用戶口令的認(rèn)證體系。其認(rèn)證消息格式和流程如下：所述步驟一的客戶端向認(rèn)證服務(wù)器發(fā)送tgt申請(qǐng)請(qǐng)求時(shí)，在as_req(as為認(rèn)證服務(wù)authenticationservice，req為request請(qǐng)求，rep為reponse，as_req就是認(rèn)證請(qǐng)求)消息中增加一下skprv-c字段，該字段是客戶端使用自己的私鑰采用非對(duì)稱簽名算法對(duì)消息內(nèi)容{idc，idtgs，times，nounce1，realmc，options}的簽名：

c→as：as_req＝{idc，idtgs，times，nounce1，realmc，options,skprv-c}

as→c：as_rep＝{realmc，idc，tickettgs，ekpub-c(kc,tgs，times，nounce1，realmtgs，idtgs),skprv-as}

tickettgs＝ektgs(realmc，idc，idtgs，ipc，times，kc,tgs，flags)

認(rèn)證服務(wù)器收到客戶端的請(qǐng)求報(bào)文后，先根據(jù)用戶名稱在本地?cái)?shù)據(jù)庫中查找用戶的公鑰kpub-c，并對(duì)消息內(nèi)容進(jìn)行驗(yàn)簽運(yùn)算，如果驗(yàn)簽通過，則認(rèn)證繼續(xù)；

認(rèn)證服務(wù)器生成會(huì)話密鑰kc,tgs，該會(huì)話密鑰用于客戶端和授權(quán)服務(wù)器之間的加密通信；

認(rèn)證服務(wù)器產(chǎn)生用戶請(qǐng)求的授權(quán)服務(wù)器的票據(jù)許可票據(jù)tgt，該票據(jù)包括用戶名稱、授權(quán)服務(wù)器名稱、用戶ip、隨機(jī)數(shù)、有效生存期限以及會(huì)話密鑰kc,tgs等，并用授權(quán)服務(wù)器的密鑰ktgs進(jìn)行加密(對(duì)稱)生成tickettgs，以保證tickettgs只有授權(quán)服務(wù)器才能解密；

用用戶的公鑰加密另外一份包含kc,tgs的信息ekpub-c(kc,tgs，times，nounce1，realmtgs，idtgs)；

認(rèn)證服務(wù)器再對(duì)整個(gè)消息用自己的私鑰簽名生成skprv-as，并返回應(yīng)答報(bào)文，該應(yīng)答報(bào)文被用戶接收到后，用戶先用預(yù)先保存的認(rèn)證服務(wù)器公鑰驗(yàn)證簽名，驗(yàn)簽通過后，再用自己的私鑰解密得到kc,tgs等后續(xù)流程需要用到的信息。改進(jìn)后的as_req和as_rep(as_rep是認(rèn)證響應(yīng))流程完成。

用于hadoop集群的身份認(rèn)證方法將原來簡(jiǎn)單基于口令的軟件認(rèn)證模式改造成基于硬件和口令結(jié)合的雙因子認(rèn)證模式，從而降低了hadoop集群認(rèn)證易遭受弱口令攻擊的風(fēng)險(xiǎn)。本發(fā)明取代kerberos的默認(rèn)機(jī)制，避免在密鑰管理中心保存用戶的口令，以提高系統(tǒng)安全性。本發(fā)明的身份認(rèn)證機(jī)制能夠有效的降低系統(tǒng)遭受弱口令攻擊的風(fēng)險(xiǎn)，而且不會(huì)造成系統(tǒng)的復(fù)雜度大大增加，可用性明顯降低。

由于采用了上述技術(shù)方案，與現(xiàn)有技術(shù)相比，本發(fā)明的有益效果如下：

一，本發(fā)明由于采用了基于pki的認(rèn)證模式后，無需在kdc上保存用戶的口令，減少了系統(tǒng)的風(fēng)險(xiǎn)點(diǎn)，這樣大大提高了hadoop集群身份認(rèn)證的安全性。

二，由于本發(fā)明改造的是hadoop集群身份認(rèn)證中執(zhí)行頻率非常低的as_req和as_req流程，因此對(duì)系統(tǒng)的性能幾乎沒有什么影響。

三，系統(tǒng)認(rèn)證采用雙因子模式后，可以大大降低弱口令攻擊的風(fēng)險(xiǎn)，對(duì)hadoop集群的安全性也是一個(gè)比較明顯的提升。

綜上所述，本發(fā)明為了減輕hadoop集群認(rèn)證易遭受弱口令攻擊的風(fēng)險(xiǎn)，本發(fā)明采用的措施是將原來簡(jiǎn)單基于口令的軟件認(rèn)證模式改造成基于硬件和口令結(jié)合的雙因子認(rèn)證模式。雙因子認(rèn)證(2fa)是指結(jié)合密碼以及實(shí)物(智能卡、sms手機(jī)、令牌或指紋等生物標(biāo)志)兩種條件對(duì)用戶進(jìn)行認(rèn)證的方法。在本案例中，主要是將客戶的私鑰儲(chǔ)存到智能卡設(shè)備中，并用口令進(jìn)行加密保護(hù)。需要使用私鑰進(jìn)行認(rèn)證前，客戶端程序先要求客戶輸入口令，驗(yàn)證通過后才允許客戶端調(diào)用內(nèi)置在智能卡內(nèi)部的非對(duì)稱算法完成認(rèn)證動(dòng)作。hadoop集群的認(rèn)證系統(tǒng)經(jīng)過雙因子認(rèn)證改造后，雖然無法完全杜絕弱口令攻擊，但是由于認(rèn)證過程涉及硬件設(shè)備，攻擊者雖然可以通過猜測(cè)等非正常手段獲取到口令，但是往往很難同時(shí)獲得硬件智能卡設(shè)備，因此可以大大降低系統(tǒng)遭受弱口令攻擊的風(fēng)險(xiǎn)。

以上所述的具體實(shí)施例，對(duì)本發(fā)明的解決的技術(shù)問題、技術(shù)方案和有益效果進(jìn)行了進(jìn)一步詳細(xì)說明，所應(yīng)理解的是，以上所述僅為本發(fā)明的具體實(shí)施例而已，并不用于限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所做的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。