How Pseudo Multifactor Logon, Browser Add-ins Hinder Security

發行項
08/18/2016

安全性監控密碼與信用卡 - 第二篇

Jesper M. Johansson

歡迎閱讀我三篇一系列文章的第二篇，本系列探討的是 IT 產業在安全性問題上如何混淆消費者，而不是幫助消費者。在 2008 年 7 月號的《TechNet Magazine》，我討論到無用和錯誤的安全性建議，以及令人困惑的登入工作流程 (如果您還沒讀第一篇，可以在

technet.microsoft.com/magazine/cc626076 上找到)。我提出論點指出，甚為普遍卻不當的安全性建議，以及不良的登入工作流程，如何混淆消費者以及阻礙他們保護個人資訊。

在本期內容中，我將繼續探討更多採自消費者安全性世界的實例。本系列的最後一篇將在下一期的《TechNet Magazine》發表，當中將包括安全性專家世界的「召集令」。

虛擬多重要素登入程序

聯邦金融機構檢查委員會 (Federal Financial Institutions Examination Council，FFIEC) 在 2005 年 10 月發佈了它的「在網際銀行的環境內進行驗證」指導方針 (請參閱 www.ffiec.gov/press/pr101205.htm)。履行的期限只有 14 個月，而美國金融機構馬上爭先恐後地想要知道如何達成這些新指標。

大多數的機構都無法在這段期限內完成。當中許多最後達成指標要求的機構都是為了遵守而遵守。換句話說，機構所採取的措施並沒有讓客戶更加安全 (它們不過是「安全性迷思」的作法)。這些無用的解決方案當中一些最有趣的例子，當屬實際上不是多重要素而試圖建立多重要素驗證的作法。

譬如說，試想一下使用者在打密碼時測量打字韻律的技術。這種方案用在網站上會呈現一個登入對話方塊，看起來就跟舊式登入對話方塊一模一樣。不過，這個對話方塊現在是個 Adobe Flash 物件。

Flash 物件會記錄使用者的打字韻律，包括特性，例如按住按鍵的時間，以及按下不同按鍵之間花多久的時間等。這項資料會隨著密碼一同提交到網站，並在該處與存放的值相比較。只要打字韻律的資料符合存放資料的特定變化，而且密碼也相符的話，就會接受登入。這大致上的構想是允許網站不用在用戶端上安裝協力廠商硬體，便可使用虛擬生物測量驗證方法。

我將把這稱為虛擬多重要素驗證。它並不是真正的多重要素驗證，真正的多重要素驗證會測量下列兩個或以上的標準要素：

使用者持有的東西 (例如智慧卡)
使用者知道的東西 (例如密碼)
使用者的身分 (例如指紋)

虛擬多重要素驗證在驗證程序中實際上並不包括多重要素，而是只針對單一要素 — 密碼 — 讀取多重參數，接著再使用那些額外的參數來推論使用者的身分。

虛擬多重要素驗證所採用的技術受許多缺點之苦。這些缺點加總起來，讓這項技術在解決它自稱能解決的安全性問題方面相當沒有效率。

瀏覽器增益集的問題

虛擬多重要素驗證系統是仰賴瀏覽器增益集來提供它們所需的精密用戶端處理功能。想當然爾，所有軟體都有錯誤，而當中有些錯誤會導致漏洞。當軟體無法更新，而且使用者不確定更新到底有沒有安裝時，這些漏洞就會演變成真正的問題。

軟體既難更新，又不提供使用者充裕的資訊確定安裝的版本是不是最新的，其實都要怪瀏覽器增益集。這使得使用者必須向網際網路公開一小部分在其他情況下可能不需要的軟體。

在有些情況下，要保持增益集的最新狀態，必須經常造訪增益集網站以取得更新。想也知道，大部分使用者不太可能會這麼做。單純為了提供安全性功能而要求使用者向網際網路公開額外且不相關的軟體，這樣的系統都應該慎重加以考量。

驗證者絕不能變

「您的身分」要素有個特徵 (甚至可能是缺點)，這個特徵並不會影響其他兩個要素。雖然您可以變更密碼 (您所知的東西) 並製造新的安全性權杖 (您所有的東西)，但是您可以使用的生物測量驗證者其實相當有限。例如，一般來說，您終生只能取得十個指紋。而且如果您在意外當中失去其中一個手指頭，通常無法加以取代。

現在試想一下這要怎麼應用於虛擬多重要素登入範例。作為另一個要素的一部分而收集的測量資料，要替換或修改並不容易。當然，當密碼變更時，使用者輸入密碼的方式也會跟著改變，但是他在鍵盤上按下按鍵的方式並不會變，而這正是這套方法的基礎。若是這些測量資料遭到入侵，就有可能可以合成它們。攻擊者至少都可以擷取這些測量資料，並重複執行。

降級為較不安全的密碼

使用長密碼，並經常更換密碼是個不錯的主意。另外，如我在這一系列的第一篇中提到的，把密碼記錄下來也是恰當的作法 (與一些建議恰恰相反) — 當然是以安全的方式記錄。不過，這些作法跟您用手輸入密碼並沒有關係。要輸入長密碼是比較困難，但是記錄起來的密碼，因為您能進行複製和剪貼，所以要來得實用得多。追蹤上百個或以上的密碼，最佳的辦法之一就是使用軟體公用程式，例如 Password Safe (網址是 sourceforge.net/projects/passwordsafe)。有了這樣的工具，您就可以產生完全隨機的密碼，以加密的方式儲存它們，然後把它們直接貼到登入對話方塊中。事實上，透過這樣的工具，您甚至不用知道密碼是什麼。

但是難處在於：除非使用者輸入密碼，否則您無法測量打字韻律。而且如果您必須將密碼輸入一個物件來測量打字韻律的話，這種管理密碼的方法便會開始瓦解。要正確輸入含 15 個完全隨機字元的密碼，並不是件易事。也因此使用者在面臨這樣的系統時，一般會選擇簡化他們的密碼。但是，含 15 個完全隨機字元的密碼本身跟搭配虛擬多重要素驗證系統的短密碼比起來，要安全許多。

實際上，單獨實作虛擬多重要素驗證會強迫使用者使用較不安全的密碼。不幸的是，您待會兒就會看到，順應採用適當密碼管理方法的使用者，基本上等於是貶損了虛擬多重要素驗證系統所提供的任何價值。

略過虛擬多重要素登入

即使網站真的實作虛擬多重要素驗證，它還是必須支援一種方法來略過虛擬多重要素系統。首先，能要求它所有使用者安裝「第四方」技術以便存取網站的網站寥寥無幾。有部分使用者 (比方說，一些《TechNet Magazine》的作者) 肯定不會安裝這類的軟體。

其次，打字韻律可能基於很多理由而發生變更，因此網站也必須順應這樣的變動。例如，像使用者的手扭到了，使她的打字韻律暫時有所改變。如果網站分析她的韻律，然後認為她是別人試圖冒用使用者憑證登入的話，她要怎麼存取網站呢？如果傷害是永久的，使用者可重設已儲存的韻律值。但如果只是暫時受傷，使用者可能不想重設已儲存的值，因為她認為她的打字韻律不久後大概就能恢復之前的樣子了。

最後，並非所有使用者都有能力使用虛擬多重要素驗證系統。舉例來說，透過語音辨識介面與電腦互動的殘障人士可能無法填寫對話方塊，要視電腦是否允許以程式的方式輸入而定。在這種情況下，法律可能會要求採用替代的系統來配合殘障使用者。

配合所有這些案例最簡單且最直接的方式，是同時支援以標準密碼為基礎的驗證。

受侵密碼的問題

虛擬多重要素驗證系統旨在解決與以密碼為主的驗證相關的各種問題。然而，這些系統無法徹底一一處理密碼可能受侵的各種方式。仰賴以密碼為主的驗證的系統可能受到入侵的方法有五大種，所謂「受到入侵」是指攻擊者已獲取並使用其他使用者的密碼：

密碼猜測
按鍵輸入記錄器
網路釣魚攻擊
詢問使用者
入侵儲存密碼或密碼雜湊的任何系統

密碼猜測在罪犯間已不再是特別常見的攻擊方法，而且它與按鍵輸入記錄器和網路釣魚相形之下已大為失色。虛擬多重要素驗證也不能完全緩和密碼猜測。傳統的密碼猜測方法不太可能用來破解虛擬多重要素驗證系統，畢竟攻擊者除了必須猜測密碼之外，還得猜測打字韻律。雖然理論上合成打字韻律是可行的，但這麼做幾乎是沒有必要，因為實際的資料通常透過網路釣魚攻擊或按鍵輸入記錄器就可以擷取得到。此外，若是系統也提供標準僅輸入密碼的登入介面，攻擊者也能使用該系統來猜測密碼。

另外，使用強式密碼其實就足以抵擋密碼猜測攻擊。如果我們可以教導使用者使用更強式的密碼，也許再加上工具的協助，那麼虛擬多重要素驗證就沒有存在的意義了 (相反地，一般與虛擬多重要素系統搭配使用的較簡單的密碼，反而讓密碼猜測更有機可乘)。因此，如果舒緩密碼猜測真有價值可言的話，也只有在實作不支援僅需密碼的登入才有附加價值。而我在前文有指出，這幾乎是不可能的。換句話說，如果使用者在有虛擬多重要素驗證系統時使用較脆弱的密碼，密碼猜測可能會再次變成有效的攻擊，虛擬多重要素驗證反而不會提高安全性，而是降低安全性。這方面的疑問需要進行更深入的研究。

虛擬多重要素驗證也無法解決按鍵輸入記錄器的問題。我不知道當今普遍使用的按鍵輸入記錄器有哪個可擷取打字韻律，但這並不表示它就不存在。按鍵輸入記錄器是位於鍵盤和電腦 (或是擷取按鍵輸入的軟體) 之間的硬體。無論如何，記錄器都可以完整存取虛擬多重要素驗證方案所使用的全部資料。

事實上，因為驗證方案是在使用者模式中執行，而按鍵輸入記錄器遠遠位於其下，它甚至可以存取更多資料。鍵盤與用於擷取密碼的 Web 物件之間若無信任的路徑，要預防這類的入侵簡直是不可能的。如果虛擬多重要素驗證方案變得夠普及的話，建立這樣的按鍵輸入記錄器就大有人在。

同樣地，虛擬多重要素驗證也無法擊敗網路釣魚攻擊。與其使用假的登入畫面，攻擊者可以改用 Flash 物件來擷取密碼，以及打字韻律。

沒錯，如果攻擊者唯一採取的手段是提供使用者密碼，那麼虛擬多重要素驗證在這些案例下是有幫助的。例如，要向使用者取得密碼，最簡單的方法是詢問使用者。誇張的是，經過證明這竟然是最有效的手段，無論是當面詢問、透過電話，或是透過網路釣魚的訊息都一樣。

不用說，比起來，要向使用者取得他的打字韻律，較不切實際得多。同樣地，如果公司的密碼資料庫遭到入侵，攻擊者很可能只能存取密碼。但再次強調，要舒緩這些攻擊，也要系統不提供任何僅需標準密碼的驗證才行得通。

我也應該指明，如果密碼資料庫本身事實上已遭入侵，表示攻擊者入侵系統的程度可能遠比光用單一或甚至許多一般使用者帳戶密碼入侵系統要來得深層。因此，試圖舒緩持有密碼資料庫的攻擊者可能採取的行動，其實沒什麼效用。

一些好處

老實說，還是有幾個虛擬多重要素驗證可以幫忙解決的問題 (假設系統沒有提供任何僅需標準密碼登入選項的話)。比方說，它可用來防止密碼共用。不過，對於多名使用者可合法共用帳戶的系統來說，例如綜合銀行帳戶，這可能是個缺點。

此外，如果使用者的打字韻律不符，建構適當的互動式登入對話方塊 (而不是網站登入) 還是可以強制她完成額外的驗證步驟。這可提供額外的安全性，在高度機密的環境中防止帳戶受侵。

以視覺指標誤導使用者

最能混淆使用者視聽的方法之一，就是提供錯誤的安全性建議。最常見的大概要算在網頁上顯示鎖的圖像，如 [圖 1] 所示。這個網頁甚至還在鎖上顯示「保全」字樣。

[圖 1] 誤用鎖圖示的範例，這是令人擔憂的趨勢 (按一下以放大影像)

您肯定都知道，光在網頁上放個鎖圖像和「保全」字樣，並不表示網頁就是安全的。但這種做法已經普遍到令人不安的地步，連最具名聲且最受歡迎的網站也在此列。結果使得許多使用者都被訓練成在網頁的內文尋找這些視覺安全線索，而不是查看這些線索具備真正意含的地方：也就是位址列 (W3C Web 安全性內容 Wiki 有記載這個問題，相關資訊可自 w3.org/2006/WSC/wiki/PadlockIconMisuse 取得)。

不幸的是，這類的誤用範例不勝枚舉。相關研究指出，即使憑證很明顯，使用者還是無法識別出惡意網站 (請參閱 www.usablesecurity.org/papers/jackson.pdf)。重點在於，即使沒有真品可比對，也要具備輕鬆分辨真假的能力。這需要一點技巧，但網頁上誤導的安全性視覺指標，妨礙了這項技巧的發展，因為使用者都受到錯誤資訊的吸引了。

[圖 2] 顯示了這個問題特別惱人的變形。在本例中，顯示資訊的網頁實際上並不安全。如果您看一下位址列，會看到「http」代表通訊協定。這個網站使用的是相當常見的最佳化作法 — 它並沒有加密包含登入表單的網頁，而只加密表單提交。只要您認為「安全」就是「加密」的話，那麼就如同網頁所指出，登入就是安全的。然而 — 而且這點非常重要 — 使用者在憑證送出之前，完全沒有辦法確認它們送達的目的地！網站要等到表單提交之後，才會向使用者顯示驗證網站的認證。這就跟玩信任遊戲一樣，您先往後倒，然後假定您背後的人會接住您。如果等到表單提交，可能早已傷痕累累了。

[圖 2] 不安全網頁上的安全性視覺指標 (按一下以放大影像)

安全通訊端層 (SSL) 是在 HTTPS 中提供安全性的通訊協定，它有兩大重要目的。第一，它會向使用者驗證伺服器。第二，它會提供一個簡單的機制來交涉工作階段加密金鑰，用於用戶端和伺服器之間。

雖然只有實際的表單提交會進行加密，但第一個也是最重要的目標並未就此達成。採用這種最佳化的網站，只是使用 SSL 作為交涉金鑰的一種方法。諷刺的是，它們其實只要採用標準金鑰交涉通訊協定就可以達成同樣的目的，藉此避免 SSL 的成本和額外負荷。

[圖 2] 中所示的網站並不罕見。許多網站都只針對表單提交，而不是表單本身提供 SSL 保護。不過，這個特定的網站示範了更令人困擾的特徵。如果您在位址列中輸入 https://www.<site>.com (請留意安全的 https 指標)，該網站會將您重新導向到非 SSL 版本的網站！即便您嘗試在傳送憑證到網站之前先審查認證，網站還是會拒絕顯示認證。

雖然並非所有的網站都這麼壞，但有很多都是如此。而且在美國有兩大信用卡發行商更是不在話下。事實上，我所用的三大信用卡公司當中，只有美國運通在登入表單上有提供認證。美國運通甚至還將 HTTP 要求重新導向到 HTTPS，真是太厲害了！

關於無意義的安全性視覺指標，以及登入表單上缺乏認證，最後值得一提的是，您可能不清楚網站為什麼要這麼做。理由很簡單，是經濟方面的考量。呈現認證需要加密網頁，而加密網頁會產生額外的處理負荷，額外的處理負荷表示需要有更多的電腦來處理相同的負載，而更多電腦要花更多的錢。不幸的是，當必須在保護客戶隱私與增加利潤之間作抉擇時，許多組織都選擇增加利潤。

要開還是不開

我最近收到了一封健保公司寄來的電子郵件讓我有點吃驚。過去 10 年來有用過電腦的人都知道，他們不應該打開來路不明的電子郵件附件。所以想想看當我收到如 [圖 3] 所示的訊息時有多驚訝。

[圖 3] 包含「安全附件」的電子郵件訊息 (按一下以放大影像)

很顯然地，我在健保公司的網站上提出一個問題 (可疑的信件抵達時，我早已忘得一乾二淨)，而這正是這家公司回應的方式。剛開始我以為這是高明的網路釣魚陰謀，直到我發現這是合法的信件時，才開始毛骨悚然。

最先的指示是按兩下附件，開始解密訊息。大部分的安全性社群和 IT 系統管理員，在過去 10 年來一直努力教導大眾不要按兩下開啟附件。然後有這麼一家公司 (順帶一提，我的健保提供者並不是唯一使用這套方法的公司) 進來說，為了我的安全，我必須按一下附件。這要使用者作何反應？他因此學到或忘卻了什麼行為？

隨後，我使用 Microsoft® Office Outlook® 2007 中的預覽功能來查看訊息。如您在 [圖 4] 中所見，Outlook 認為這封郵件可能有害，並警告我不要打開它！

[圖 4] Outlook 2007 認為安全文件有害 (按一下以放大影像)

健保公司違反了世界上最受歡迎的電子郵件用戶端所使用的最基本安全性檢查，實在很諷刺，也很可悲。想到這家公司連在 Outlook 中測試它的新安全性方案都懶了，我不得不質疑它還會做什麼來保護我的私密資訊。或者，更直言不諱些，這家公司不知道為了避免因未充分保護客戶隱私而遭到控告，還實作了哪些其他解決方案？這跟金融機構執行的安全性迷思沒什麼兩樣。在本例中，我認為避免被控是此解決方案的主要目標 — 而不是真正保護客戶。

我想要看看附件到底是什麼。結果是 ActiveX® 控制項物件。為了查看附件，我必須在 Internet Explorer® 中開啟它，然後安裝該物件。我看到了 [圖 5] 中所示的擔保畫面。如您所見，設計人員大費周章地讓訊息看起來像一般的信封，上面甚至還有個戳記，宣稱信封是受信任的。

[圖 5] 顯示一個含「信任」戳記的信封的安全文件 (按一下以放大影像)

這種技術令人擔憂的理由有很多。首先，它在使用者身上強化了一種非常不當的行為：開啟來路不明的附件。其次，在實際的郵件中，它提供了非常不良的指引，將系統設定成永遠不提示就開啟附件。第三，電腦上顯示的衝突訊息中，電子郵件說它是可信任的，而 Outlook 則不這麼認為，使得郵件看起來非常可疑。最後，實際的附件包含了無意義的安全性視覺指標，來說服使用者它實際上是可信任的。如果使用者學會信任這類的郵件，假以時日，使用者很快就會信任具備類似外觀的惡意郵件。

提供安全通訊

沒錯，這項技術聲稱要解決的問題，確實是非常重要。以信任的方式與客戶溝通並不容易。但這個特定的解決方案其實過度工程化了。它很可能混淆客戶，因而可能產生反效果：使得客戶的系統變得危機四伏。

較為妥善工程化的網站現在則採用「訊息中心」。在這種設計下，當公司需要與客戶溝通時，它會傳送一封電子郵件表明用意：「您在訊息中心有封郵件，請前往我們的網站，登入後按一下 [訊息中心] 連結來查看訊息。」若公司使用安全多用途網際網路郵件延伸 (S/MIME) 來簽署所有面向客戶的電子郵件訊息，讓使用者可以驗證來源的話更好。如果訊息在電子郵件內不包括任何「請按一下此連結」的項目的話，又多加一分。使用者應該用手輸入公司的 URL，以確保她是要前往預期的網站。

有了訊息中心和經過簽署的訊息，公司便可以打造信任的管道與客戶溝通。客戶在訊息工作流程期間看到的一切都會經過驗證，而且公司也不會提倡不良的安全性作法。

攸關隱私

到目前為止，我利用了本系列的前兩篇來說明安全性專家其實是在幫使用者倒忙。維護安全性是我們的責任，但許多決策和實作的解決方案都讓使用者不知所措，教導他們做出不當的決策，並給他們一種錯誤的安全感。我們不應該以這些相衝突的想法，讓使用者無所適從。

我之前有提到，對於主流使用者來說，安全性只不過是保護密碼和信用卡號碼。他們希望技術除了可行之外，也值得信任。可惜，他們必須做決定，而確定他們所做的是明智的決策，正是我們的責任。

在本系列的最後一篇，我將探討一些供消費者使用的最重要的技術，如何令人大失所望。我也會公佈我的召集令。所以，敬請期待 2008 年 9 月期的《安全性監控》專欄。

Jesper M. Johansson 是負責安全性軟體的軟體架構設計人員，也是《TechNet Magazine》的特約編輯之一。他擁有管理資訊系統 (MIS) 的博士學位，研究安全性長達 20 多年，是 Microsoft 在企業安全性領域的最有價值專家 (MVP)。其最新著述為《Windows Server 2008 Security Resource Kit》。

共用方式為

目錄

其他資源