資訊與網路安全技術第 十三章 用戶認證系統  上一頁      下一頁

 

13-2 帳戶密碼 的運作程序

內容:

  • 13-2-1 帳號/密碼:認證程序

  • 13-2-2 帳號/密碼:共享密鑰

  • 13-2-3 帳號/密碼:認證協定

13-2-1 帳號/密碼:認證程序

認證使用者身份最簡單的方法,當推眾人皆知的『帳號/密碼』(Account/Password系統。當使用者輸入帳號名稱之後,系統會要求使用者再輸入密碼,以確定使用者身份。但話說回來,僅就密碼去認證使用者身份,恐怕不是十分安全的做法;譬如,銀行系統,客戶除了輸入密碼來確認身份之外,還要有『提款卡』才允許從提款機領錢。因此,許多系統不僅要求客戶輸入密碼之外,還需要如 IC 卡的東西來確認身份。但無論如何,輸入密碼是最基本的確認途徑;然而,若將密碼僅作為系統判斷客戶身份的工具,那未免又太小看密碼的功能了。對一般系統而言,為了簡化客戶端進入系統的方便性,通常僅要求使用者輸入密碼便完成認證的工作,但當密碼輸入之後,可能會衍生許多後續的問題,以下分別介紹這些後續問題。

13-2-2 帳號/密碼:共享密鑰

我們可以回想一下,使用者可以在任何一部電腦上,以輸入帳號與密碼的方式登入系統,而該部電腦可能就在私有網路內,也可能位於全球任何角落。基本上,登入的電腦不應該受地理位置的限制,而且密碼也不應該以明文方式傳送,因為明文方式傳送的密碼,一旦被攻擊者攔截到之後,便可輕易入侵系統。相對地,系統也有保存一份使用者的『帳號/密碼』資料,以作為使用者登入系統的密碼比對;相同的道理,儲存在系統之內的密碼也絕不可以明文方式儲存,否則一旦入侵者進入系統盜取密碼檔案,整個系統的安全性必將陷入崩潰。如此說來,處理密碼需具備下列三個條件:

  • 密碼不可以明文方式傳輸;

  • 密碼也不可以明文方式儲存;

  • 加密(或雜湊演算)後的密碼也不可以在網路上傳輸。

       由前面兩個條件,如何達成密碼的確認,說起來的確是一件有趣的問題,第三個條件更為懸疑,我們按部就班的介紹如何克服這些問題。一開始簡單的構想是,密碼經過加密後再傳送給系統;系統也將密碼加密後再儲存於密碼檔案裡。既然負責將客戶端輸入的密碼加密的是客戶端所登入的工作站,因此,工作站與系統之間必須存在某一個協定,來處理有關客戶與系統之間的身份確認的工作,此協定便稱為『認證協定』(Authentication Protocol。由此可見,從事於身份認證的主要成員包含使用者、工作站與主機系統等三個。如圖 13-1 所示,使用者於工作站輸入帳號與密碼之後,工作站就輸入的帳號與密碼,和系統主機之間以某一種『認證協定』來確定使用者的身份。

13-1 身份認證的運作

既然密碼不可以明文傳送與儲存,意味著工作站與主機之間必須協議出一種方法來將密碼隱藏起來。最簡單的方法是將密碼加密成為一個亂無章法的一串亂碼,或是經由雜湊演算法計算出一個雜湊值;但無論經由何種演算法來隱藏密碼還是有被破解的危機。譬如,攻擊者可以由工作站與系統之間攔截多個加密後的密碼,從中找出加密鑰匙,如此便可以找出使用者的密碼。因此,為了增加密碼的隱藏性,通常會加入某一數值與密碼混合加密(或雜湊演算),該數值一般稱為『鹽』(Salt,這種處理技巧通稱為『醃製法』(Salt Value。經由醃製法處理過的密碼則稱為『共享密鑰』(Shared Secret,其處理過程如下:

  • 密碼(PasswordP

  • 個人的參數值(鹽)Smm = 1, 2, …, n

  • 演算法:f(),可能是加密演算法(DES)或雜湊演算法(MD5RC4)。

  • 個人的共享密鑰:KT = f(P, Sm)

       並非所有認證協定都是透過醃製法製造共享密鑰,許多系統還是直接將密碼經過演算法計算出來而已,譬如,Unix/LinuxWindow Server等系統。但新的協定為了增加密碼的安全性,已大多加入醃製法功能。基本上,我們希望每一個使用者所加入的『鹽』不要一樣,因此,在系統裡必須儲存每一個使用者的『鹽』。

有了上述醃製法的概念之後,系統管理員除了針對每一個使用者建立帳號之外,也必須針對每一個帳戶選擇一個亂數作為『鹽』,並允許使用者輸入或更改密碼來建立共享密鑰。建立後的密碼檔案格式就如圖 13-2 所示,檔案內每一個帳戶的紀錄包含:帳戶名稱、鹽、以及共享密鑰(有些系統沒有鹽的欄位)。

13-2  建立共享密鑰

13-2-3 帳號/密碼:認證協定

我們用一個簡單的運作程序,來說明雙方確認密碼的方法。如圖 13-3 所示,使用者在工作站上輸入帳號之後(訊號 (1)),工作站便將帳號名稱傳送給系統主機(訊號 (2));系統主機收到帳號名稱之後,便由密碼檔案裡搜尋出該帳號的『鹽』,並回傳給工作站(訊號 (3));此時,工作站便要求使用者輸入密碼(訊號 (4));再利用所收到的鹽與密碼,一起經由某一種演算法計算出雜湊值,再將此雜湊值回傳給系統主機(訊號 (5)),系統比對所收到的雜湊值是否與密碼檔案所儲存的相同,如果相同的話,則可以確定對方的身份無誤。

13-3 簡單的密碼確認程序

13-3 做法是將加密後的密碼(f(密碼, )),直接在網路上傳輸,所以攻擊者只要攔截到該訊息(訊號 (5)),便可以直接登入系統,完全不需要去考慮密碼是經由何種演算法計算而得。為了安全,必須合乎先前所介紹的第三個條件:『加密後的密碼也不可以在網路上傳輸』。如此說來,驗證密碼必須另尋它法才行;簡單的構想是利用秘密鑰匙演算法,只要能證實雙方所擁有的鑰匙是相同的,便能證實對方的身份。因此,我們可將加密後的密碼當作雙方共享的秘密鑰匙,如果能證實雙方所持有的鑰匙是相同的,便能確認對方的密碼無誤。

驗證雙方所持有的鑰匙是否相同的基本方法是『盤問/回應』(Challenge/ Response) 認證協定,如圖 13-4 所示。圖 13-4 與圖 13-3 兩者之間的運作程序非常類似;在圖 13-4 中,系統主機收到工作站所傳送過來的帳號之後,除了傳送『鹽』的亂數之外,也附加了一個亂數 R1,其作為盤問的訊息(訊號 (3))。接下來,工作站收到 R1與『鹽』之後,即時要求使用者輸入密碼(訊號 (4)),並計算出共享密鑰(KT),再利用 KT R1加密之後回傳給系統主機(訊號 (5));系統主機同樣利用密碼檔案裡所儲存的共享密鑰向 R1加密,如果兩者加密後的訊息相同的話,便可以認證對方的加密鑰匙是相同的,也可以確認密碼無誤。

13-4 盤問與回應的密碼確認

由此可見,我們係利用加密後的密碼作為雙方共享秘密,因此,將它稱之為『共享密鑰』(Shared Secret。但也不一定要使用加密技巧來實現『盤問與回應』協定。我們主要目的是要驗證雙方所持有的鑰匙是否相同,並不是要針對亂數 R1做隱密性傳輸;因此,可以採用加密演算法(如 DES)或訊息確認方法(如 HMAC)。由此說來,加密後的密碼也不一定拿來作鑰匙使用,只能夠說是工作站與系統之間的共享秘密(Shared Secret而已;我們為了突顯它的重要性,因此,將它翻譯成『共享密鑰』。

在一套應用系統之下,通常會有多個帳戶(或稱使用者),每一個帳戶與系統之間都有一把共享密鑰(13-5);系統為了安全地保管這些共享鑰匙,一般都儲存於密碼檔案裡。然而,針對使用者而言,個人共享密鑰是與系統溝通的最主要途徑,因此又將它稱為個人的『主密鑰』(Master Secret

13-5 每一使用者的主密鑰

翻轉工作室:粘添壽

 

資訊與網路安全技術

 

 

翻轉電子書系列: