|
|
|
13-2 帳戶密碼 的運作程序
13-2-1 帳號/密碼：認證程序 認證使用者身份最簡單的方法，當推眾人皆知的『帳號/密碼』（Account/Password）系統。當使用者輸入帳號名稱之後，系統會要求使用者再輸入密碼，以確定使用者身份。但話說回來，僅就密碼去認證使用者身份，恐怕不是十分安全的做法；譬如，銀行系統，客戶除了輸入密碼來確認身份之外，還要有『提款卡』才允許從提款機領錢。因此，許多系統不僅要求客戶輸入密碼之外，還需要如 IC 卡的東西來確認身份。但無論如何，輸入密碼是最基本的確認途徑；然而，若將密碼僅作為系統判斷客戶身份的工具，那未免又太小看密碼的功能了。對一般系統而言，為了簡化客戶端進入系統的方便性，通常僅要求使用者輸入密碼便完成認證的工作，但當密碼輸入之後，可能會衍生許多後續的問題，以下分別介紹這些後續問題。 13-2-2 帳號/密碼：共享密鑰 我們可以回想一下，使用者可以在任何一部電腦上，以輸入帳號與密碼的方式登入系統，而該部電腦可能就在私有網路內，也可能位於全球任何角落。基本上，登入的電腦不應該受地理位置的限制，而且密碼也不應該以明文方式傳送，因為明文方式傳送的密碼，一旦被攻擊者攔截到之後，便可輕易入侵系統。相對地，系統也有保存一份使用者的『帳號/密碼』資料，以作為使用者登入系統的密碼比對；相同的道理，儲存在系統之內的密碼也絕不可以明文方式儲存，否則一旦入侵者進入系統盜取密碼檔案，整個系統的安全性必將陷入崩潰。如此說來，處理密碼需具備下列三個條件：
由前面兩個條件，如何達成密碼的確認，說起來的確是一件有趣的問題，第三個條件更為懸疑，我們按部就班的介紹如何克服這些問題。一開始簡單的構想是，密碼經過加密後再傳送給系統；系統也將密碼加密後再儲存於密碼檔案裡。既然負責將客戶端輸入的密碼加密的是客戶端所登入的工作站，因此，工作站與系統之間必須存在某一個協定，來處理有關客戶與系統之間的身份確認的工作，此協定便稱為『認證協定』（Authentication Protocol）。由此可見，從事於身份認證的主要成員包含使用者、工作站與主機系統等三個。如圖 13-1 所示，使用者於工作站輸入帳號與密碼之後，工作站就輸入的帳號與密碼，和系統主機之間以某一種『認證協定』來確定使用者的身份。
圖 13-1 身份認證的運作 既然密碼不可以明文傳送與儲存，意味著工作站與主機之間必須協議出一種方法來將密碼隱藏起來。最簡單的方法是將密碼加密成為一個亂無章法的一串亂碼，或是經由雜湊演算法計算出一個雜湊值；但無論經由何種演算法來隱藏密碼還是有被破解的危機。譬如，攻擊者可以由工作站與系統之間攔截多個加密後的密碼，從中找出加密鑰匙，如此便可以找出使用者的密碼。因此，為了增加密碼的隱藏性，通常會加入某一數值與密碼混合加密（或雜湊演算），該數值一般稱為『鹽』（Salt），這種處理技巧通稱為『醃製法』（Salt Value）。經由醃製法處理過的密碼則稱為『共享密鑰』（Shared Secret），其處理過程如下：
並非所有認證協定都是透過醃製法製造共享密鑰，許多系統還是直接將密碼經過演算法計算出來而已，譬如，Unix/Linux、Window 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 每一使用者的主密鑰 |
翻轉工作室：粘添壽
資訊與網路安全技術
翻轉電子書系列：
|
