用多步的密匙交換方式來進行非常安全的會話初始化和使用者名稱密碼登陸 (轉)

worldblog發表於2007-12-15
用多步的密匙交換方式來進行非常安全的會話初始化和使用者名稱密碼登陸 (轉)[@more@]

用多步的密匙

一般的驗證是需要傳遞名和密碼的。
但是怎樣才能保證傳遞的過程中密碼不被洩露??
可能會有人說,對密碼進行不就完了?
但是實際上,除了密碼不被洩露外,還需要保證沒有擷取欺騙等問題。

RSA等非對稱加密,可以另第三方無法得到客戶的密碼。
但是第三方則可以直接傳送加密過的資料,達到欺騙的目的。

下面是我設計的一個解決方案,(絕對原創,但是原理簡單,不保證有人之前已經用這個了。)

現在用三重DES:

第一步:
客戶端,使用者輸入
clientUsername,clientPass
客戶端,往伺服器端傳送clientUsername

第二步:
伺服器,接收到clientUsername後,
查詢databaseUsername
如果沒有找到 -> Exception -> 設計一個方案告訴客戶找不到使用者名稱,終止

第三步:
伺服器,得到databasePassword,
生成一個字串serverStr1,serverStr2,並且儲存起來
(其實放在session中還是其他地方,隨便,但是不要放到客戶端去,例如不要使用ViewState)

用databasePassword作為Key,對serverStr1進行加密,
得到serverStr1Encrypted=TDES(serverStr1,databasePassword)

用serverStr1作為Key,對serverStr2進行加密,
得到serverStr2Encrypted=TDES(serverStr2,serverStr1)

把serverStr1Encrypted,serverStr2Encrypted傳到客戶端

第四步:
客戶端,得到serverStr1Encrypted,serverStr2Encrypted
用clientPassword作為Key,對serverStr1Encrypted進行,
得到clientStr1=~TDES(serverStr1Encrypted,clientPassword)
用clientStr1作為Key,對serverStr2Encrypted進行截密,
得到clientStr2=~TDES(serverStr1Encrypted,clientPassword)
如果其中一次解迷發生錯誤,-> Exception -> 那麼告訴客戶密碼不對,終止

如果密碼是對應的話,那麼serverStr1和clientStr1是對應的。serverStr2和clientStr2對應。
這個過程目的就是使用password作為Key,然後在兩者間安全地交換密匙str2

使用clientStr2作為Key,對clientPassword進行加密,
得到clientPasswordEncrypted=TDES(clientPassword,clientStr2)

第五步:
把clientPasswordEncrypted送到伺服器端

第六步:
伺服器,得到clientPasswordEncrypted
根據會話狀態,
測試:
clientPasswordEncrypted==TDES(databasePassword,serverStr2);
如果其中一次解迷發生錯誤,-> Exception -> 那麼告訴客戶密碼不對,終止

如果相等?LoginAs(databaseUsername);


這個方法也不是100%安全。首先是DES本身的問題。這個則不作為討論範圍。
然後最突出的問題在第五步。

如果在clientPasswordEncrypted傳送過程中,被第三方終止了,
然後第三方冒認客戶,把clientPasswordEncrypted傳過去,就可以達到欺騙的目的。

為了防止這個,需要在第六步,需要在會話方面進行進可能多的會話驗證。
例如判斷IP等方法。(物理因素往往比數字因數好)

然後更多的方法是進行密匙交換,(當中的DESKey當然是隨機的,只對會話其效果的)
第三步,
伺服器另外建立serverDESKey,作為讓客戶進行資訊加密之用
傳給客戶的則是serverDESKeyEncrypted=TDES(serverDESKey,serverStr1)
第四步,
客戶端另外建立clientDESKey,作為讓伺服器進行資訊加密之用
clientDESKeyEncrypted=TDES(clientDESKey,clientStr1)
然後在第五步和clientPasswordEncrypted同時交給伺服器。

那麼即使發生欺騙,
第三方沒有辦法得到兩個DESKey,
沒有辦法傳送合法的請求,也沒有辦法把得到資訊進行解密。

這個過程。核心仍然是會話初始密匙clientStr1=serverStr1


 


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-993804/,如需轉載,請註明出處,否則將追究法律責任。

相關文章