專利名稱：一種對客戶端進(jìn)行認(rèn)證方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及信息安全技術(shù)領(lǐng)域，特別是一種對客戶端進(jìn)行認(rèn)證方法及裝置。
背景技術(shù)：
網(wǎng)站頁面被篡改極大地?fù)p害了政府和企業(yè)用戶的利益。特別是含有政治攻擊色彩的篡改，會對政府形象造成嚴(yán)重?fù)p害，對企業(yè)造成不可估量的損失。由于網(wǎng)絡(luò)信息傳播快， 使網(wǎng)站一旦被篡改，給用戶造成的影響短時間內(nèi)很難消除。網(wǎng)站頁面分為靜態(tài)網(wǎng)頁和動態(tài)網(wǎng)頁，靜態(tài)網(wǎng)頁指的是任何時候任何用戶瀏覽網(wǎng)頁內(nèi)容都是固定不變，而動態(tài)網(wǎng)頁是根據(jù)用戶的不同，用戶的輸入呈現(xiàn)出不同的網(wǎng)頁內(nèi)容，動態(tài)網(wǎng)頁的內(nèi)容來源于后臺web數(shù)據(jù)庫。隨著CGI以及PHP、ASP、JSP等技術(shù)的興起，各種動態(tài)新聞、論壇、BBS、電子商務(wù)等動態(tài)網(wǎng)頁大量增加，現(xiàn)在的動態(tài)網(wǎng)頁應(yīng)用已經(jīng)逐步取代了靜態(tài)網(wǎng)頁應(yīng)用。對動態(tài)網(wǎng)頁的篡改，主要是黑客使用SQL注入等攻擊手段，利用數(shù)據(jù)庫服務(wù)器的漏洞，非法篡改提升操作數(shù)據(jù)庫的權(quán)限，從而達(dá)到從數(shù)據(jù)庫竊取信息或修改數(shù)據(jù)庫內(nèi)容。為了避免SQL攻擊，數(shù)據(jù)庫系統(tǒng)(DBMS)提供了用戶身份識別機(jī)制和數(shù)據(jù)庫系統(tǒng)訪問權(quán)限的認(rèn)證所謂身份識別是指只有經(jīng)過數(shù)據(jù)庫授權(quán)和驗證的用戶才是合法的用戶，目前的身份識別方法包括2種方法DDBMS提供認(rèn)證用戶可以通過提交正確的用戶名、密碼，由DBMS提供驗證來訪問數(shù)據(jù)庫。2)操作系統(tǒng)提供認(rèn)證用戶可以通過提交正確的用戶名、密碼，由OS提供驗證來訪問數(shù)據(jù)庫。當(dāng)用戶連接數(shù)據(jù)庫系統(tǒng)時，可以采用上述兩種方式之一或兩種方式同時對待連接的客戶端進(jìn)行認(rèn)證，以達(dá)到保證數(shù)據(jù)庫系統(tǒng)安全的目的。所謂數(shù)據(jù)庫訪問權(quán)限，是指用戶可以執(zhí)行的數(shù)據(jù)庫操作范圍。DBMS使用用戶權(quán)限表控制用戶的操作權(quán)限。在用戶授權(quán)表中規(guī)定了每個用戶能訪問的數(shù)據(jù)庫名、表名、字段名、讀寫權(quán)限和管理權(quán)限。而SQL攻擊本質(zhì)是巧妙的構(gòu)造SQL語句，其在數(shù)據(jù)中混合SQL指令，實現(xiàn)迂回攻擊，或通過不斷地嗅探和猜測，從而非法地操作數(shù)據(jù)庫數(shù)據(jù)。SQL攻擊的危害包括探知數(shù)據(jù)庫結(jié)構(gòu)、獲取管理員的密碼、更改用戶權(quán)限、創(chuàng)建新用戶、控制操作系統(tǒng)、破壞硬盤數(shù)據(jù)等。可見，通過上述用戶身份的識別方法和數(shù)據(jù)庫系統(tǒng)的訪問權(quán)限控制方法并不能有效的防止SQL注入的迂回和嗅探攻擊。

發(fā)明內(nèi)容
本發(fā)明實施例一方面提供一種對客戶端身份進(jìn)行認(rèn)證的方法和裝置，另一方面提供一種對客戶端訪問權(quán)限進(jìn)行認(rèn)證的方法和裝置，以有效的防止SQL注入的迂回和嗅探攻擊ο本發(fā)明實施例提供了一種對客戶端身份進(jìn)行認(rèn)證的方法，包括第一驗證模塊接收來自客戶端的包含第一用戶名和第一驗證密碼的驗證請求；所述第一驗證模塊對所述第一用戶名及所述第一驗證密碼進(jìn)行第一次驗證，獲得第一驗證結(jié)果；當(dāng)所述第一驗證結(jié)果表明所述第一次驗證通過時，所述第一驗證模塊接收來自所述客戶端的第二驗證密碼；所述第一驗證模塊將所述第一用戶名和所述第二驗證密碼發(fā)送給第二驗證模塊；所述第一驗證模塊接收來自所述第二驗證模塊的第二驗證結(jié)果，所述第二驗證結(jié)果是所述第二驗證模塊對所述第一用戶名和所述第二驗證密碼進(jìn)行第二次驗證后獲得的；所述第一驗證模塊將所述第二驗證結(jié)果發(fā)送給所述客戶端。其中，第一驗證模塊對所述第一用戶名及第一驗證密碼進(jìn)行第一次驗證的步驟包括第一驗證模塊接收到登錄請求后，生成隨機(jī)數(shù)，將所述隨機(jī)數(shù)發(fā)送給所述客戶端；所述客戶端用自身的公鑰pkl對所述隨機(jī)數(shù)進(jìn)行加密，生成加密后的隨機(jī)數(shù)，將所述加密后的隨機(jī)數(shù)和第一驗證密碼發(fā)送給第一驗證模塊；所述第一驗證模塊使用所述第一驗證密碼獲得所述客戶端的私鑰，應(yīng)用所述客戶端的私鑰對所述加密后的隨機(jī)數(shù)進(jìn)行解密，獲得解密后的隨機(jī)數(shù)；所述第一驗證模塊比較所述生成的隨機(jī)數(shù)與所述解密后的隨機(jī)數(shù)是否相同，若相同，則第一次驗證通過。其中，第一驗證模塊將接收到的所述第一用戶名和第二驗證密碼發(fā)送給第二驗證模塊的步驟包括所述客戶端用自身的公鑰對第二驗證密碼進(jìn)行加密，生成加密后的第二驗證密碼，將所述第一用戶名和加密后的第二驗證密碼發(fā)送至第一驗證模塊；所述第一驗證模塊使用第一平臺密鑰對所述加密后的第二驗證密碼pw’進(jìn)行簽名，生成簽名后的第二驗證密碼，將所述第一用戶名、加密后的第二驗證密碼和簽名后的第二驗證密碼發(fā)送給第二驗證模塊。其中，對所述第二驗證密碼進(jìn)行第二次驗證的步驟包括第二驗證模塊使用第一平臺證書驗證簽名后的第二驗證密碼，若驗證通過，則應(yīng)用從所述第一驗證模塊獲取的所述用戶端的私鑰解密加密后的第二驗證密碼，得到所述客戶端的第一用戶名和第二驗證密碼；第二驗證模塊向數(shù)據(jù)庫系統(tǒng)請求第一用戶名對應(yīng)的已加密第三驗證密碼；所述數(shù)據(jù)庫系統(tǒng)在本地查找已記錄的與所述第一用戶名對應(yīng)的已加密第三驗證密碼，將所述已加密第三驗證密碼發(fā)送至第二驗證模塊；所述第二驗證模塊應(yīng)用所述客戶端的對稱密鑰對所述已加密第三驗證密碼進(jìn)行解密，獲得第三驗證密碼；
判斷所述第二驗證密碼與第三驗證密碼是否相同，若相同則生成認(rèn)證通過的認(rèn)證結(jié)果，否則生成認(rèn)證未通過的認(rèn)證結(jié)果。其中，所述第一驗證模塊接收來自所述第二驗證模塊的第二驗證結(jié)果，將所述第二驗證結(jié)果發(fā)送給所述客戶端的步驟包括第二驗證模塊應(yīng)用第二平臺密鑰對認(rèn)證結(jié)果進(jìn)行簽名，得到簽名后的認(rèn)證結(jié)果， 將所述簽名后的認(rèn)證結(jié)果發(fā)送給第一驗證模塊；所述第一驗證模塊接收到所述簽名后的認(rèn)證結(jié)果后，使用第二平臺密鑰的證書對簽名后的認(rèn)證結(jié)果進(jìn)行驗證，驗證通過后將認(rèn)證結(jié)果發(fā)送給客戶端。其中，所述第一驗證模塊與第二驗證模塊位于相同或不同的物理實體上。本發(fā)明實施例還提供了一種對客戶端身份進(jìn)行認(rèn)證的裝置，包括第一驗證模塊， 其中，所述第一驗證模塊具體包括驗證請求接收模塊，用于接收來自客戶端的包含第一用戶名和第一驗證密碼的驗證請求；第一次驗證模塊，用于對所述第一用戶名及所述第一驗證密碼進(jìn)行第一次驗證， 獲得第一驗證結(jié)果；第二驗證密碼接收模塊，用于當(dāng)所述第一驗證結(jié)果表明所述第一次驗證通過時， 接收來自所述客戶端的第二驗證密碼；發(fā)送模塊，用于將所述第一用戶名和所述第二驗證密碼發(fā)送給第二驗證模塊；驗證結(jié)果發(fā)送模塊，用于接收來自所述第二驗證模塊的第二驗證結(jié)果，將所述第二驗證結(jié)果發(fā)送給所述客戶端；其中，所述第二驗證結(jié)果是所述第二驗證模塊對所述第一用戶名和所述第二驗證密碼進(jìn)行第二次驗證后的結(jié)果。其中，所述第一次驗證模塊包括隨機(jī)數(shù)生成子模塊，用于第一驗證模塊接收到登錄請求后，生成隨機(jī)數(shù)，將所述隨機(jī)數(shù)發(fā)送給所述客戶端；隨機(jī)數(shù)接收子模塊，用于接收來自客戶端的加密后的隨機(jī)數(shù)和第一驗證密碼，其中，所述加密后的隨機(jī)數(shù)是客戶端用自身的公鑰對所述隨機(jī)數(shù)進(jìn)行加密后生成的；解密子模塊，用于使用所述第一驗證密碼獲得所述客戶端的私鑰，應(yīng)用所述客戶端的私鑰對所述加密后的隨機(jī)數(shù)r’進(jìn)行解密，獲得解密后的隨機(jī)數(shù)；判斷子模塊，用于比較所述生成的隨機(jī)數(shù)與所述解密后的隨機(jī)數(shù)是否相同，若相同，則第一次驗證通過。其中，所述發(fā)送模塊包括第二驗證密碼接收子模塊，用于接收加密后的第二驗證密碼，其中，所述加密后的第二驗證密碼是由客戶端用自身的公鑰對第二驗證密碼進(jìn)行加密后生成的；簽名子模塊，用于使用第一平臺密鑰對所述加密后的第二驗證密碼進(jìn)行簽名，生成簽名后的第二驗證密碼，將所述第一用戶名、加密后的第二驗證密碼和簽名后的第二驗證密碼發(fā)送給第二驗證模塊。其中，所述驗證結(jié)果發(fā)送模塊包括第二驗證結(jié)果接收子模塊，用于接收簽名后的認(rèn)證結(jié)果，其中，所述簽名后的認(rèn)證結(jié)果是第二驗證模塊應(yīng)用第二平臺密鑰對認(rèn)證結(jié)果進(jìn)行簽名后得到的；
第二驗證結(jié)果發(fā)送子模塊，用于接收到所述簽名后的認(rèn)證結(jié)果后，使用第二平臺密鑰的證書對所述簽名后的認(rèn)證結(jié)果進(jìn)行驗證，驗證通過后將認(rèn)證結(jié)果發(fā)送給客戶端。本發(fā)明實施例還提供了一種對客戶端訪問權(quán)限進(jìn)行認(rèn)證的方法，包括設(shè)置授權(quán)表，所述授權(quán)表中包括用戶信息、已加密的授權(quán)書及授權(quán)人簽名的對應(yīng)關(guān)系，所述方法還包括接收到來自客戶端的數(shù)據(jù)庫系統(tǒng)操作請求，從所述請求中獲取所述客戶端的用戶 fn息；如果所獲取的用戶信息與本地已記錄的授權(quán)表的用戶信息匹配，則根據(jù)所述對應(yīng)關(guān)系獲取授權(quán)人簽名，并驗證所述授權(quán)人簽名；如果簽名驗證成功，則根據(jù)所述對應(yīng)關(guān)系獲取已加密的授權(quán)書，對已加密授權(quán)書進(jìn)行解密，獲得授權(quán)書；判斷所述操作請求對應(yīng)的權(quán)限是否在所述授權(quán)書所規(guī)定的權(quán)限范圍內(nèi)，若是，則通過訪問權(quán)限認(rèn)證。其中，所述授權(quán)人簽名通過數(shù)據(jù)庫管理員的公鑰進(jìn)行驗證。其中，在簽名驗證成功后，加載所述客戶端私鑰，應(yīng)用所述客戶端的私鑰對已加密授權(quán)書進(jìn)行解密。其中，在簽名驗證成功后，加載所述客戶端私鑰前，還包括驗證來自客戶端的私鑰口令，若驗證通過，再加載所述客戶端的私鑰。其中，所述客戶端信息包括用戶名和主機(jī)名。本發(fā)明實施例還提供了一種對客戶端訪問權(quán)限進(jìn)行認(rèn)證的裝置，包括設(shè)置單元，用于設(shè)置授權(quán)表，所述授權(quán)表中包括用戶信息、已加密的授權(quán)書及授權(quán)人簽名的對應(yīng)關(guān)系；客戶端信息獲取單元，用于接收到來自客戶端的數(shù)據(jù)庫系統(tǒng)操作請求，從所述請求中獲取所述客戶端的用戶信息；驗證單元，用于如果所獲取的用戶信息與本地已記錄的授權(quán)表的用戶信息匹配， 則根據(jù)所述對應(yīng)關(guān)系獲取授權(quán)人簽名，并驗證所述授權(quán)人簽名；解密單元，用于如果簽名驗證成功，則根據(jù)所述對應(yīng)關(guān)系獲取已加密的授權(quán)書，對已加密授權(quán)書進(jìn)行解密，獲得授權(quán)書；權(quán)限判斷單元，用于判斷所述操作請求對應(yīng)的權(quán)限是否在所述授權(quán)書所規(guī)定的權(quán)限范圍內(nèi)，若是，則通過訪問權(quán)限認(rèn)證。其中，所述授權(quán)人簽名通過數(shù)據(jù)庫管理員的公鑰進(jìn)行驗證。其中，所述裝置還包括加載單元，用于在簽名驗證成功后，加載所述客戶端私鑰， 應(yīng)用所述客戶端的私鑰對已加密授權(quán)書進(jìn)行解密。其中，所述裝置還包括客戶端私鑰驗證單元，用于在簽名驗證成功后，加載所述客戶端私鑰前，驗證來自客戶端的私鑰口令，若驗證通過，再加載所述用戶端的私鑰。其中，所述客戶端信息包括用戶名和主機(jī)名?？梢姡瑧?yīng)用本發(fā)明實施例提供的一種對客戶端身份進(jìn)行認(rèn)證的方法和裝置，避免了被類似SQL攻擊從而繞過用戶身份驗證的可能性；再有，由于驗證密碼只出現(xiàn)在驗證模塊TCM中，避免了由于存放在her表中被猜中、被嗅探的可能。


為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。圖1是根據(jù)本發(fā)明實施例一的對客戶端身份進(jìn)行認(rèn)證的方法流程圖；圖2是根據(jù)本發(fā)明實施例一的第一次驗證的處理流程圖；圖3是根據(jù)本發(fā)明實施例一的第二次驗證的處理流程圖；圖4是根據(jù)本發(fā)明實施例二的對客戶端身份進(jìn)行認(rèn)證的方法流程圖；圖5是根據(jù)本發(fā)明實施例一的對客戶端身份進(jìn)行認(rèn)證的裝置結(jié)構(gòu)示意圖；圖6是根據(jù)本發(fā)明實施例三的對客戶端訪問權(quán)限進(jìn)行認(rèn)證的方法流程圖；圖7是根據(jù)本發(fā)明實施例的對客戶端進(jìn)行授權(quán)的流程圖；圖8是根據(jù)本發(fā)明實施例的驗證客戶端訪問權(quán)限的流程圖；圖9是根據(jù)本發(fā)明實施例三的對客戶端訪問權(quán)限進(jìn)行認(rèn)證的裝置結(jié)構(gòu)示意圖。
具體實施例方式下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。基于本發(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護(hù)的范圍。本發(fā)明實施例在全面分析了動態(tài)網(wǎng)頁被篡改的原因和SQL注入攻擊web數(shù)據(jù)庫技術(shù)后，針對Web數(shù)據(jù)庫最易被攻擊的數(shù)據(jù)庫用戶登錄時的身份驗證過程，提出了一種基于兩級認(rèn)證機(jī)制的對客戶端身份進(jìn)行認(rèn)證的方法，以使連接至web數(shù)據(jù)庫的客戶端是可信任的。參見圖1，其是根據(jù)本發(fā)明實施例一的對客戶端身份進(jìn)行認(rèn)證的方法流程圖，本實施例包括步驟101，第一驗證模塊接收來自客戶端的包含第一用戶名和第一驗證密碼skpw 的驗證請求；步驟102，第一驗證模塊對所述第一用戶名及所述第一驗證密碼skpw進(jìn)行第一次驗證，獲得第一驗證結(jié)果；步驟103，當(dāng)所述第一驗證結(jié)果表明所述第一次驗證通過時，所述第一驗證模塊接收來自所述客戶端的第二驗證密碼；步驟104，所述第一驗證模塊將所述第一用戶名和所述第二驗證密碼pw發(fā)送給第二驗證模塊；步驟105，所述第一驗證模塊接收來自所述第二驗證模塊的第二驗證結(jié)果，所述第二驗證結(jié)果是所述第二驗證模塊對所述第一用戶名和所述第二驗證密碼PW進(jìn)行第二次驗證后獲得的；步驟106，所述第一驗證模塊將所述第二驗證結(jié)果發(fā)送給所述客戶端。
需要說明的是，所述第一驗證模塊和第二驗證模塊可以在一個物理實體上，也可以在不同的物理實體上，例如第一驗證模塊位于web服務(wù)器上，第二驗證模塊位于數(shù)據(jù)庫服務(wù)器上。應(yīng)用本發(fā)明實施例提供的對客戶端身份進(jìn)行認(rèn)證的方法，避免了被類似SQL攻擊從而繞過用戶身份驗證的可能性；再有，由于驗證密碼只出現(xiàn)在驗證模塊中，避免了由于存放在her表中被猜中、被嗅探的可能；此外，防止了被釣魚，建立了從客戶端到web端的網(wǎng)絡(luò)信任鏈。下面結(jié)合具體實例，對圖1中的各步驟再做詳細(xì)說明。上述具體實例的應(yīng)用環(huán)境如下對待登錄的客戶端A經(jīng)過web服務(wù)器和數(shù)據(jù)庫服務(wù)器兩次驗證，以防止SQL注入的迂回和嗅探攻擊。基于該應(yīng)用實例，具體實現(xiàn)過程如下首先，客戶端A進(jìn)行注冊。具體的，假設(shè)客戶端A需要注冊服務(wù)器帳號，因而需要設(shè)置用戶名、登錄密碼(pw) 和用戶密鑰口令(Skpw)，服務(wù)器端收到客戶端A的注冊請求后，分別在第一可信平臺模塊 (TCMl)和第二可信平臺模塊(TCM2)中創(chuàng)建客戶端A的密鑰。其中，服務(wù)器端包括兩個服務(wù)器，一個是頁面服務(wù)器(Webkrver)，另一個是數(shù)據(jù)庫服務(wù)器(DB Server)，且TCMl位于頁面服務(wù)器上，TCM2位于數(shù)據(jù)庫服務(wù)器上。這里，數(shù)據(jù)庫服務(wù)器使用客戶端A的密鑰將客戶端設(shè)置的登錄密碼Pw加密后存入到用戶(User)表中，然后將TCMl中客戶端A的公鑰返回給客戶端A，并存入該用戶端的操作系統(tǒng)(OS)密鑰池中。TCMl中客戶端A的私鑰遷移到 TCM2 中。需要說明的是，上述TCM1、TCM2分別相當(dāng)于圖1所示實施例中的第一驗證模塊、第二驗證模塊；上述用戶密鑰口令Skpw相當(dāng)于圖1所示實施例中的第一驗證密碼；上述登錄密碼pw相當(dāng)于圖1所示實施例中的第二驗證密碼。也就是說，本具體實例中，由TCM1、TCM2 作為第一驗證模塊、第二驗證模塊的一種具體實現(xiàn)方式，在實際應(yīng)用中，還可以應(yīng)用其他任何可信任平臺或模塊作為第一驗證模塊和第二驗證模塊的一種具體實施例而已，在本發(fā)明實施例中，并不限定第一驗證模塊和第二驗證模塊具體采用哪種可信任平臺或模塊。其次，對客戶端A進(jìn)行第一次驗證。該第一次驗證的過程就是圖1所示實施例中的步驟101 102，具體實現(xiàn)過程如圖 2所示。參見圖2，其是根據(jù)本發(fā)明實施例一的第一次驗證的處理流程圖，具體包括步驟201，客戶端A接收用戶輸入的第一用戶名(usename)和用戶密鑰口令skpw， 向TCMl發(fā)起登錄請求；步驟202，TCMl接收到登錄請求后，生成隨機(jī)數(shù)r，將所述隨機(jī)數(shù)r發(fā)送給所述客戶端A;步驟203，客戶端A用自身的公鑰pkl對隨機(jī)數(shù)r進(jìn)行加密，生成加密后的隨機(jī)數(shù) r’，將所述加密后的隨機(jī)數(shù)r’和用戶密鑰口令skpw發(fā)送給TCMl ；步驟204，TCMl使用所述用戶密鑰口令skpw獲得所述用戶端的私鑰SK1，應(yīng)用所述SKl對所述加密后的隨機(jī)數(shù)r’進(jìn)行解密，獲得解密后的隨機(jī)數(shù)r”;比較所述生成的隨機(jī)數(shù)r與所述解密后的隨機(jī)數(shù)r”是否相同，若相同，則第一次驗證通過；若不同，則給客戶端 A返回第一次驗證失敗的信息。
至此，完成了第一次驗證。在第一次驗證通過后表明web服務(wù)器上的TCMl確認(rèn)了登錄的客戶端A ；同時客戶端A ；至此，建立了客戶端A、web服務(wù)器、web應(yīng)用程序和TCMl之間的信任。再次，對客戶端A進(jìn)行第二次驗證。該第二次驗證的過程就是圖1所示實施例中的步驟103 106，具體實現(xiàn)過程如圖 3所示。參見圖3，其是根據(jù)本發(fā)明實施例一的第二次驗證的處理流程圖，具體包括步驟301，客戶端A接收用戶輸入的第一用戶名(usename)和登錄密碼pw ；這里，也可以讓用戶僅輸入登錄密碼pw，而客戶端A從自身的保存記錄中獲取第一用戶名，即不需要用戶再次輸入第一用戶名。步驟302，客戶端A用自身的公鑰Pkl對登錄密碼pw進(jìn)行加密，生成加密后的登錄密碼PW’，將所述第一用戶名和加密后的登錄密碼PW’發(fā)送至TCMl ；步驟303，TCMl使用第一平臺密鑰PEKl對所述加密后的登錄密碼pw’進(jìn)行簽名， 生成簽名后的登錄密碼pw”，將所述第一用戶名、加密后的登錄密碼pw’和簽名后的登錄密碼Pw ”發(fā)送給TCM2 ；上述步驟302-303是圖1中步驟104的一種具體實現(xiàn)方式，即實現(xiàn)了第一驗證模塊將接收到的第一用戶名和登錄密碼PW發(fā)送給第二驗證模塊。步驟304，TCM2使用第一平臺證書驗證簽名后的登錄密碼pw”，若驗證通過，則應(yīng)用從TCMl獲取的所述客戶端A的私鑰解密加密后的登錄密碼pw’，得到所述客戶端A的第一用戶名和登錄密碼pw。步驟305，TCM2向數(shù)據(jù)庫系統(tǒng)例如數(shù)據(jù)庫中的用戶表(user表)中請求第一用戶名對應(yīng)的已加密第三驗證密碼C’ ；數(shù)據(jù)庫系統(tǒng)在本地查找已記錄的與所述第一用戶名對應(yīng)的已加密第三驗證密碼C’，將所述已加密第三驗證密碼C’發(fā)送至TCM2 ；其中，所述已加密第三驗證密碼C’是第二驗證模塊應(yīng)用所述客戶端的對稱密鑰對第三驗證密碼c加密生成的；步驟306，TCM2應(yīng)用所述客戶端A的對稱密碼對所述加密后的第三驗證密碼C’進(jìn)行解密，獲得第三驗證密碼c ；之后，TCM2判斷所述登錄密碼pw與第三驗證密碼c是否相同，若相同則生成認(rèn)證通過的認(rèn)證結(jié)果，否則生成認(rèn)證未通過的認(rèn)證結(jié)果。至此，完成了對客戶端A的第二次驗證。步驟307，TCM2應(yīng)用第二平臺密鑰PEK2對認(rèn)證結(jié)果result進(jìn)行簽名，得到簽名后的認(rèn)證結(jié)果result’，將所述簽名后的認(rèn)證結(jié)果result’發(fā)送給TCMl ；步驟308，TCMl使用第二平臺密鑰PEK2的證書對簽名后的認(rèn)證結(jié)果result’進(jìn)行驗證，驗證通過后將認(rèn)證結(jié)果result發(fā)送給用戶端A。至此，TCM2通過所述TCMl將認(rèn)證結(jié)果通知給客戶端A。需要說明的是，上述第一平臺為TCMl所在的平臺，上述第二平臺為TCM2所在的平臺。需要說明的是，上述第一次驗證也可以稱之為I級認(rèn)證，即由TCMl對用戶密鑰口令Skpw進(jìn)行了 I級認(rèn)證；上述第二次驗證也可以稱之為II級認(rèn)證，即由TCM2對登錄密碼 Pw進(jìn)行了 II級認(rèn)證。
可見，兩次強(qiáng)制身份驗證(或稱為II級身份認(rèn)證)避免了被類似SQL攻擊從而繞過用戶身份驗證的可能性；再有，由于驗證密碼只出現(xiàn)在TCM中，避免了由于存放在her表中被猜中、被嗅探的可能；此外，防止了被釣魚，建立了從客戶端A到web端的網(wǎng)絡(luò)信任鏈。參見圖4，其是根據(jù)本發(fā)明實施例二的對客戶端身份進(jìn)行認(rèn)證的方法流程圖，具體包括步驟401，第二驗證模塊在第一次驗證通過后，接收來自第一驗證模塊的第一用戶名和第二驗證密碼；其中，所述第一次驗證是由第一驗證模塊對來自客戶端的第一用戶名和第一驗證模塊進(jìn)行的驗證；步驟402，第二驗證模塊對所述第一用戶名和第二驗證密碼pw進(jìn)行第二次驗證， 獲得第二驗證結(jié)果，將所述第二驗證結(jié)果通過所述第一驗證模塊通知給所述客戶端。需要說明的是，上述第一次驗證的過程與圖2所述內(nèi)容相同，第二次驗證的過程與圖3所述內(nèi)容相同，這里不再詳細(xì)描述。本發(fā)明實施例還提供了一種對客戶端身份進(jìn)行認(rèn)證的裝置，參見圖5，具體包括 第一驗證模塊，其中，所述第一驗證模塊具體包括驗證請求接收模塊501，用于接收來自客戶端的包含第一用戶名和第一驗證密碼 Skpw的驗證請求；第一次驗證模塊502，用于對所述第一用戶名及所述第一驗證密碼skpw進(jìn)行第一次驗證，獲得第一驗證結(jié)果；第二驗證密碼接收模塊503，用于當(dāng)所述第一驗證結(jié)果表明所述第一次驗證通過時，接收來自所述客戶端的第二驗證密碼；發(fā)送模塊504，用于將所述第一用戶名和所述第二驗證密碼pw發(fā)送給第二驗證模塊；驗證結(jié)果發(fā)送模塊505，用于接收來自所述第二驗證模塊的第二驗證結(jié)果，將所述第二驗證結(jié)果發(fā)送給所述客戶端；其中，所述第二驗證結(jié)果是所述第二驗證模塊對所述第一用戶名和所述第二驗證密碼PW進(jìn)行第二次驗證后得到的。上述第一次驗證模塊502可以具體包括隨機(jī)數(shù)生成子模塊，用于第一驗證模塊接收到登錄請求后，生成隨機(jī)數(shù)r，將所述隨機(jī)數(shù)r發(fā)送給所述客戶端；隨機(jī)數(shù)接收子模塊，用于接收來自客戶端的已加密的隨機(jī)數(shù)r’和第一驗證密碼 skpw，其中，所述已加密的隨機(jī)數(shù)r’是客戶端用自身的公鑰Pkl對隨機(jī)數(shù)r進(jìn)行加密后生成的；解密子模塊，用于使用所述第一驗證密碼skpw獲得所述用戶端的私鑰SK1，應(yīng)用所述SKl對所述已加密的隨機(jī)數(shù)r’進(jìn)行解密，獲得解密后的隨機(jī)數(shù)r” ；判斷子模塊，用于比較所述生成的隨機(jī)數(shù)!·與所述解密后的隨機(jī)數(shù)r”是否相同， 若相同，則第一次驗證通過。上述發(fā)送模塊504可以具體包括第二驗證密碼接收子模塊，用于接收加密后的第二驗證密碼pw’，其中，所述加密后的第二驗證密碼PW’是由客戶端用自身的公鑰Pkl對第二驗證密碼PW進(jìn)行加密后生成的；
簽名子模塊，用于使用第一平臺密鑰PEKl對所述加密后的第二驗證密碼pw’進(jìn)行簽名，生成簽名后的第二驗證密碼pw”，將所述第一用戶名、加密后的第二驗證密碼pw’和簽名后的第二驗證密碼pw”發(fā)送給第二驗證模塊。上述驗證結(jié)果發(fā)送模塊505可以具體包括第二驗證結(jié)果接收子模塊，用于接收簽名后的認(rèn)證結(jié)果result’，其中，所述簽名后的認(rèn)證結(jié)果result’是第二驗證模塊應(yīng)用第二平臺密鑰PEK2對認(rèn)證結(jié)果result進(jìn)行簽名后得到的；第二驗證結(jié)果發(fā)送子模塊，用于接收到所述簽名后的認(rèn)證結(jié)果result’后，使用第二平臺密鑰PEK2的證書對簽名后的認(rèn)證結(jié)果result’進(jìn)行驗證，驗證通過后將認(rèn)證結(jié)果 result發(fā)送給客戶端。應(yīng)用本發(fā)明實施例提供的對客戶端身份進(jìn)行認(rèn)證的裝置，避免了被類似SQL攻擊從而繞過用戶身份驗證的可能性；再有，由于驗證密碼只出現(xiàn)在驗證模塊中，避免了由于存放在her表中被猜中、被嗅探的可能；此外，防止了被釣魚，建立了從客戶端到web端的網(wǎng)絡(luò)信任鏈。本發(fā)明實施例在全面分析了動態(tài)網(wǎng)頁被篡改的原因和SQL注入攻擊web數(shù)據(jù)庫技術(shù)后，針對Web數(shù)據(jù)庫最易被攻擊的數(shù)據(jù)庫用戶登錄時的身份驗證過程，還提出了一種對客戶端訪問權(quán)限進(jìn)行認(rèn)證的方法，以使連接至web數(shù)據(jù)庫的客戶端是可信任的。參見圖6，其是根據(jù)本發(fā)明實施例三的對客戶端訪問權(quán)限進(jìn)行認(rèn)證的方法流程圖， 該流程具體包括步驟601，設(shè)置授權(quán)表，所述授權(quán)表中包括用戶信息、已加密的授權(quán)書C’及授權(quán)人簽名C”的對應(yīng)關(guān)系，所述方法還包括步驟602，接收到來自客戶端的數(shù)據(jù)庫系統(tǒng)操作請求，從所述請求中獲取所述客戶端的用戶信息；步驟603，如果所獲取的用戶信息與本地已記錄的授權(quán)表的用戶信息匹配，則根據(jù)所述對應(yīng)關(guān)系獲取授權(quán)人簽名C”，并驗證所述授權(quán)人簽名C” ；步驟604，如果簽名驗證成功，則根據(jù)所述對應(yīng)關(guān)系獲取已加密的授權(quán)書C’，對已加密授權(quán)書C’進(jìn)行解密，獲得授權(quán)書C ；步驟605，判斷所述操作請求對應(yīng)的權(quán)限是否在所述授權(quán)書所規(guī)定的權(quán)限范圍內(nèi)， 若是，則通過訪問權(quán)限認(rèn)證，否則，未通過訪問權(quán)限認(rèn)證。需要說明的是，上述授權(quán)人簽名C”通過數(shù)據(jù)庫管理員的公鑰進(jìn)行驗證。需要說明的是，在簽名驗證成功后，加載所述客戶端私鑰，應(yīng)用所述客戶端的私鑰對已加密授權(quán)書C’進(jìn)行解密。需要說明的是，在簽名驗證成功后，加載所述客戶端私鑰前，還包括驗證來自客戶端的私鑰口令UP，若驗證通過，再加載所述客戶端的私鑰。需要說明的是，所述用戶信息包括用戶名和主機(jī)名。需要說明的是，對于圖6所示的實施例三，既可以在圖1所示的實施例一之后執(zhí)行，也可以不依賴于實施例一的存在單獨執(zhí)行，本發(fā)明中并不對圖6所示實施例三的實時時機(jī)做限定。下面結(jié)合具體實例，對圖6所示流程再做詳細(xì)說明。
假設(shè)在數(shù)據(jù)庫服務(wù)器上裝有一個可信任安全模塊TCM3，存放數(shù)據(jù)庫管理員和每個用戶的公鑰(pk’ )和私鑰(sk’)。每個用戶擁有自己的私鑰口令UP。數(shù)據(jù)庫管理員擁有私鑰口令A(yù)P。設(shè)置授權(quán)書(C)，其用來描述客戶端執(zhí)行數(shù)據(jù)庫/表的操作權(quán)限。該授權(quán)書(C)是訪問控制的判斷依據(jù)，具體可以包括內(nèi)容a)授權(quán)人b)授權(quán)時間c)有效期d)數(shù)據(jù)庫名e)表名f)字段名g)數(shù)據(jù)表操作權(quán)限允許用戶對某個數(shù)據(jù)庫已有表進(jìn)行讀取、插入、更新、刪除操作，取值集合為{ ‘select，、，insert，、，update，、’ delete，}。h)數(shù)據(jù)庫/表管理權(quán)限允許用戶對數(shù)據(jù)庫或表進(jìn)行管理，取值集合為{‘a(chǎn)lter’ 、，index，、， create，、， drop， }。設(shè)置授權(quán)表Auth_Table，授權(quán)表是數(shù)據(jù)庫系統(tǒng)中的系統(tǒng)表，每條記錄表示一條授權(quán)規(guī)則，授權(quán)表的結(jié)構(gòu)及內(nèi)容可以如表1所示
權(quán)利要求
1.一種對客戶端身份進(jìn)行認(rèn)證的方法，其特征在于，包括第一驗證模塊接收來自客戶端的包含第一用戶名和第一驗證密碼的驗證請求； 所述第一驗證模塊對所述第一用戶名及所述第一驗證密碼進(jìn)行第一次驗證，獲得第一驗證結(jié)果；當(dāng)所述第一驗證結(jié)果表明所述第一次驗證通過時，所述第一驗證模塊接收來自所述客戶端的第二驗證密碼；所述第一驗證模塊將所述第一用戶名和所述第二驗證密碼發(fā)送給第二驗證模塊； 所述第一驗證模塊接收來自所述第二驗證模塊的第二驗證結(jié)果，所述第二驗證結(jié)果是所述第二驗證模塊對所述第一用戶名和所述第二驗證密碼進(jìn)行第二次驗證后獲得的； 所述第一驗證模塊將所述第二驗證結(jié)果發(fā)送給所述客戶端。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，第一驗證模塊對所述第一用戶名及第一驗證密碼進(jìn)行第一次驗證的步驟包括第一驗證模塊接收到登錄請求后，生成隨機(jī)數(shù)，將所述隨機(jī)數(shù)發(fā)送給所述客戶端； 所述客戶端用自身的公鑰Pkl對所述隨機(jī)數(shù)進(jìn)行加密，生成加密后的隨機(jī)數(shù)，將所述加密后的隨機(jī)數(shù)和第一驗證密碼發(fā)送給第一驗證模塊；所述第一驗證模塊使用所述第一驗證密碼獲得所述客戶端的私鑰，應(yīng)用所述客戶端的私鑰對所述加密后的隨機(jī)數(shù)進(jìn)行解密，獲得解密后的隨機(jī)數(shù)；所述第一驗證模塊比較所述生成的隨機(jī)數(shù)與所述解密后的隨機(jī)數(shù)是否相同，若相同， 則第一次驗證通過。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，第一驗證模塊將接收到的所述第一用戶名和第二驗證密碼發(fā)送給第二驗證模塊的步驟包括所述客戶端用自身的公鑰對第二驗證密碼進(jìn)行加密，生成加密后的第二驗證密碼，將所述第一用戶名和加密后的第二驗證密碼發(fā)送至第一驗證模塊；所述第一驗證模塊使用第一平臺密鑰對所述加密后的第二驗證密碼pw’進(jìn)行簽名，生成簽名后的第二驗證密碼，將所述第一用戶名、加密后的第二驗證密碼和簽名后的第二驗證密碼發(fā)送給第二驗證模塊。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，對所述第二驗證密碼進(jìn)行第二次驗證的步驟包括第二驗證模塊使用第一平臺證書驗證簽名后的第二驗證密碼，若驗證通過，則應(yīng)用從所述第一驗證模塊獲取的所述用戶端的私鑰解密加密后的第二驗證密碼，得到所述客戶端的第一用戶名和第二驗證密碼；第二驗證模塊向數(shù)據(jù)庫系統(tǒng)請求第一用戶名對應(yīng)的已加密第三驗證密碼； 所述數(shù)據(jù)庫系統(tǒng)在本地查找已記錄的與所述第一用戶名對應(yīng)的已加密第三驗證密碼， 將所述已加密第三驗證密碼發(fā)送至第二驗證模塊；所述第二驗證模塊應(yīng)用所述客戶端的對稱密鑰對所述已加密第三驗證密碼進(jìn)行解密， 獲得第三驗證密碼；判斷所述第二驗證密碼與第三驗證密碼是否相同，若相同則生成認(rèn)證通過的認(rèn)證結(jié)果，否則生成認(rèn)證未通過的認(rèn)證結(jié)果。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于，所述第一驗證模塊接收來自所述第二驗證模塊的第二驗證結(jié)果，將所述第二驗證結(jié)果發(fā)送給所述客戶端的步驟包括第二驗證模塊應(yīng)用第二平臺密鑰對認(rèn)證結(jié)果進(jìn)行簽名，得到簽名后的認(rèn)證結(jié)果，將所述簽名后的認(rèn)證結(jié)果發(fā)送給第一驗證模塊；所述第一驗證模塊接收到所述簽名后的認(rèn)證結(jié)果后，使用第二平臺密鑰的證書對簽名后的認(rèn)證結(jié)果進(jìn)行驗證，驗證通過后將認(rèn)證結(jié)果發(fā)送給客戶端。
6.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述第一驗證模塊與第二驗證模塊位于相同或不同的物理實體上。
7.一種對客戶端身份進(jìn)行認(rèn)證的裝置，其特征在于，包括第一驗證模塊，其中，所述第一驗證模塊具體包括驗證請求接收模塊，用于接收來自客戶端的包含第一用戶名和第一驗證密碼的驗證請求；第一次驗證模塊，用于對所述第一用戶名及所述第一驗證密碼進(jìn)行第一次驗證，獲得第一驗證結(jié)果；第二驗證密碼接收模塊，用于當(dāng)所述第一驗證結(jié)果表明所述第一次驗證通過時，接收來自所述客戶端的第二驗證密碼；發(fā)送模塊，用于將所述第一用戶名和所述第二驗證密碼發(fā)送給第二驗證模塊； 驗證結(jié)果發(fā)送模塊，用于接收來自所述第二驗證模塊的第二驗證結(jié)果，將所述第二驗證結(jié)果發(fā)送給所述客戶端；其中，所述第二驗證結(jié)果是所述第二驗證模塊對所述第一用戶名和所述第二驗證密碼進(jìn)行第二次驗證后的結(jié)果。
8.根據(jù)權(quán)利要求7所述的裝置，其特征在于，所述第一次驗證模塊包括隨機(jī)數(shù)生成子模塊，用于第一驗證模塊接收到登錄請求后，生成隨機(jī)數(shù)，將所述隨機(jī)數(shù)發(fā)送給所述客戶端；隨機(jī)數(shù)接收子模塊，用于接收來自客戶端的加密后的隨機(jī)數(shù)和第一驗證密碼，其中，所述加密后的隨機(jī)數(shù)是客戶端用自身的公鑰對所述隨機(jī)數(shù)進(jìn)行加密后生成的；解密子模塊，用于使用所述第一驗證密碼獲得所述客戶端的私鑰，應(yīng)用所述客戶端的私鑰對所述加密后的隨機(jī)數(shù)r’進(jìn)行解密，獲得解密后的隨機(jī)數(shù)；判斷子模塊，用于比較所述生成的隨機(jī)數(shù)與所述解密后的隨機(jī)數(shù)是否相同，若相同，則第一次驗證通過。
9.根據(jù)權(quán)利要求7所述的裝置，其特征在于，所述發(fā)送模塊包括第二驗證密碼接收子模塊，用于接收加密后的第二驗證密碼，其中，所述加密后的第二驗證密碼是由客戶端用自身的公鑰對第二驗證密碼進(jìn)行加密后生成的；簽名子模塊，用于使用第一平臺密鑰對所述加密后的第二驗證密碼進(jìn)行簽名，生成簽名后的第二驗證密碼，將所述第一用戶名、加密后的第二驗證密碼和簽名后的第二驗證密碼發(fā)送給第二驗證模塊。
10.根據(jù)權(quán)利要求7所述的方法，其特征在于，所述驗證結(jié)果發(fā)送模塊包括第二驗證結(jié)果接收子模塊，用于接收簽名后的認(rèn)證結(jié)果，其中，所述簽名后的認(rèn)證結(jié)果是第二驗證模塊應(yīng)用第二平臺密鑰對認(rèn)證結(jié)果進(jìn)行簽名后得到的；第二驗證結(jié)果發(fā)送子模塊，用于接收到所述簽名后的認(rèn)證結(jié)果后，使用第二平臺密鑰的證書對所述簽名后的認(rèn)證結(jié)果進(jìn)行驗證，驗證通過后將認(rèn)證結(jié)果發(fā)送給客戶端。
11.一種對客戶端訪問權(quán)限進(jìn)行認(rèn)證的方法，其特征在于，包括設(shè)置授權(quán)表，所述授權(quán)表中包括用戶信息、已加密的授權(quán)書及授權(quán)人簽名的對應(yīng)關(guān)系，所述方法還包括接收到來自客戶端的數(shù)據(jù)庫系統(tǒng)操作請求，從所述請求中獲取所述客戶端的用戶信息；如果所獲取的用戶信息與本地已記錄的授權(quán)表的用戶信息匹配，則根據(jù)所述對應(yīng)關(guān)系獲取授權(quán)人簽名，并驗證所述授權(quán)人簽名；如果簽名驗證成功，則根據(jù)所述對應(yīng)關(guān)系獲取已加密的授權(quán)書，對已加密授權(quán)書進(jìn)行解密，獲得授權(quán)書；判斷所述操作請求對應(yīng)的權(quán)限是否在所述授權(quán)書所規(guī)定的權(quán)限范圍內(nèi)，若是，則通過訪問權(quán)限認(rèn)證。
12.根據(jù)權(quán)利要求11所述的方法，其特征在于，所述授權(quán)人簽名通過數(shù)據(jù)庫管理員的公鑰進(jìn)行驗證。
13.根據(jù)權(quán)利要求11所述的方法，其特征在于，在簽名驗證成功后，加載所述客戶端私鑰，應(yīng)用所述客戶端的私鑰對已加密授權(quán)書進(jìn)行解密。
14.根據(jù)權(quán)利要求13所述的方法，其特征在于，在簽名驗證成功后，加載所述客戶端私鑰前,還包括驗證來自客戶端的私鑰口令，若驗證通過，再加載所述客戶端的私鑰。
15.根據(jù)權(quán)利要求11所述的方法，其特征在于，所述客戶端信息包括用戶名和主機(jī)名。
16.一種對客戶端訪問權(quán)限進(jìn)行認(rèn)證的裝置，其特征在于，包括設(shè)置單元，用于設(shè)置授權(quán)表，所述授權(quán)表中包括用戶信息、已加密的授權(quán)書及授權(quán)人簽名的對應(yīng)關(guān)系；客戶端信息獲取單元，用于接收到來自客戶端的數(shù)據(jù)庫系統(tǒng)操作請求，從所述請求中獲取所述客戶端的用戶信息；驗證單元，用于如果所獲取的用戶信息與本地已記錄的授權(quán)表的用戶信息匹配，則根據(jù)所述對應(yīng)關(guān)系獲取授權(quán)人簽名，并驗證所述授權(quán)人簽名；解密單元，用于如果簽名驗證成功，則根據(jù)所述對應(yīng)關(guān)系獲取已加密的授權(quán)書，對已加密授權(quán)書進(jìn)行解密，獲得授權(quán)書；權(quán)限判斷單元，用于判斷所述操作請求對應(yīng)的權(quán)限是否在所述授權(quán)書所規(guī)定的權(quán)限范圍內(nèi)，若是，則通過訪問權(quán)限認(rèn)證。
17.根據(jù)權(quán)利要求16所述的裝置，其特征在于，所述授權(quán)人簽名通過數(shù)據(jù)庫管理員的公鑰進(jìn)行驗證。
18.根據(jù)權(quán)利要求16所述的裝置，其特征在于，所述裝置還包括加載單元，用于在簽名驗證成功后，加載所述客戶端私鑰，應(yīng)用所述客戶端的私鑰對已加密授權(quán)書進(jìn)行解密。
19.根據(jù)權(quán)利要求18所述的裝置，其特征在于，所述裝置還包括客戶端私鑰驗證單元，用于在簽名驗證成功后，加載所述客戶端私鑰前，驗證來自客戶端的私鑰口令，若驗證通過，再加載所述用戶端的私鑰。
20.根據(jù)權(quán)利要求16所述的裝置，其特征在于，所述客戶端信息包括用戶名和主機(jī)名。
全文摘要
本發(fā)明公開了一種對客戶端進(jìn)行認(rèn)證方法及裝置，通過兩次驗證完成對客戶端的認(rèn)證，避免了被類似SQL攻擊從而繞過用戶身份驗證的可能性；再有，由于驗證密碼只出現(xiàn)在驗證模塊中，避免了由于存放在用戶表中被猜中、被嗅探的可能。
文檔編號H04L29/06GK102202040SQ201010135348
公開日2011年9月28日 申請日期2010年3月26日 優(yōu)先權(quán)日2010年3月26日
發(fā)明者劉春梅, 郭軼尊 申請人:聯(lián)想(北京)有限公司