4.3 對驗證機制漏洞進行防范

電子通信已經(jīng)成為所有行業(yè)的基本部分，包括醫(yī)療保健、電信、制藥、零售、金融等，幾乎所有這些行業(yè)都在全世界部署了它們自己的特制軟件系統(tǒng)和解決方案，從而把它們的客戶和業(yè)務伙伴連接在一起。

銀行、保險、資產管理和股票市場等領域的金融機構必須滿足非常嚴格的安全需求，必須保護它們的應用程序處理的所有電子數(shù)據(jù)。它們必須設計和實現(xiàn)能夠滿足這些嚴格的安全需求的軟件解決方案和應用程序。換句話說，系統(tǒng)需要確保很高的安全合法性。

正如在FFIEC（Federal Financial Institutions Examination Council）致金融機構的信函（FIL-103-2005,2005年10月12日）“Authentication in an Internet Banking Environment” 中指出的：“在網(wǎng)上銀行環(huán)境中，未經(jīng)授權的或未正確識別的用戶可能會進行欺詐、泄露客戶信息、損壞數(shù)據(jù)或造成不可能實施的合約，從而給金融機構造成經(jīng)濟損失和名譽損失。” 這封信函強調了網(wǎng)絡驗證機制的重要性：“風險評估應該根據(jù)與網(wǎng)上客戶可用的各種產品和服務相關的風險決定有效的驗證戰(zhàn)略。”因此，必須建立健壯的驗證管理過程來實現(xiàn)驗證和授權，這是成功實現(xiàn)安全的軟件解決方案的關鍵因素。

4.3.1 設置安全可靠的證書

要解決身份驗證問題，需要有配套的公鑰基本設施來核實用戶的真實身份。這些設施用來創(chuàng)建、管理、發(fā)布、收回數(shù)字證書。而數(shù)字證書正是你需要為站點使用HTTPS協(xié)議付費的事項。但是，什么是數(shù)字證書？數(shù)字證書又是如何保證信息更加安全的呢？

從更高的層次來講，數(shù)字證書是將機器上的公鑰和身份信息綁在一起的數(shù)字簽名。數(shù)字簽名擔保某份公鑰屬于某個特定的組織和機構。

證書將域名（身份信息）和特定公鑰關聯(lián)起來，這就避免了竊聽者將自己的服務器偽裝成用戶將要連接的服務器并進行攻擊的行為。

要受到一般瀏覽器的信任，證書本身還應當受到CA的信任。CA公司對認證會進行人工核查，確定申請主體滿足以下兩個條件。

一是在公共記錄中存在著這個人/這家公司。

二是需要簽名的證書上標明的域名的確由申請主體實際控制。

當CA查證得出申請人屬實，并且的確擁有這個域名的結果時，便會為證書頒發(fā)簽證，蓋上“已核準”的戳記，表明網(wǎng)站的公鑰屬于這個網(wǎng)站，而且可以信任。

你的瀏覽器中會內置一系列受信任的CA列表。如果服務器返回的是未經(jīng)過受信任CA簽證的證書，瀏覽器會彈出大大的警告，如圖4-20所示，這就在系統(tǒng)中多了一層安全措施，不然，任何人都可以四處簽售偽造的證書。

這樣一來，即使攻擊者將自己的公鑰拿出來生成這份密鑰，聲稱自己的偽造服務器就是“xxxx.com”，瀏覽器也會因為檢查到“未經(jīng)受信任CA簽名的證書”而彈出提示。

以下是一些關于證書的其他事項。

（1）增強式認證。

在常規(guī)的X.509證書之外，增強式認證證書提供了更強力的認證。

要授予增強式認證證書，CA會對域名持有者做更加深入的查驗（通常需要提供護照和水電費賬單等信息）。

這種類型的證書，瀏覽器中大鎖圖標的顯示位置背景也會變成綠色。

（2）在同一臺服務器上運行的多個網(wǎng)站。

在HTTP協(xié)議連接開始之前進行的TLS協(xié)議握手流程，很有可能存在著多個網(wǎng)站存放在同一個服務器，使用相同IP地址的情況。

虛擬主機的Web路由是由Web服務器分發(fā)，但是TCP握手的過程，是發(fā)生在連接之前。整個系統(tǒng)的單張證書會被發(fā)送到服務器的所有請求之中，這種流程會在共享主機的環(huán)境中發(fā)生問題。

如果你正在使用Web主機上提供的服務，他們會在你使用HTTPS協(xié)議之前要求使用獨立的IP地址，不然主體提供商就需要每次在服務器上有新站點時，取得新證書（并且向CA重新申請認證）。

4.3.2 對密碼重置和忘記密碼功能進行控制

執(zhí)行安全的驗證機制，不僅僅要同時滿足幾個關鍵安全目標，許多時候也需要犧牲其他目標，如易用性、成本、功能。

1．防止濫用密碼修改的基本要求

（1）加一個簡單圖片驗證碼，基本確保是人在操作，而不是機器。

（2）只能從已經(jīng)通過驗證的會話中訪問該功能。

（3）不要以任何方式直接提供用戶名，也不要使用隱藏表單字段或者Cookies提供用戶名。

（4）為了防止攻擊者通過會話劫持漏洞、跨站點腳本，或者是忘記關閉的頁面獲得未授權訪問，應該要求用戶重新輸入現(xiàn)有密碼。

（5）為了防止輸入錯誤，新密碼要輸入兩次，順便校驗兩次密碼是否一致。

（6）如果是重要的系統(tǒng)，多次使用失敗的使用密碼修改功能，很有可能被攻擊。

2．防止濫用“密碼找回”的基本要求

密碼找回可能是現(xiàn)在最容易出現(xiàn)漏洞的地方。

（1）加一個簡單圖片驗證碼，基本確保是人在操作，而不是機器。

（2）當用戶遺忘密碼時，需要重要的系統(tǒng)，最好是通過非常規(guī)的方式完成密碼找回，如給呼叫中心打電話，通過發(fā)送傳統(tǒng)郵件提供最新的驗證信息，或者自動凍結一段時間。

（3）短信、郵件等方式都有可能造成漏洞，但是這個是現(xiàn)代互聯(lián)網(wǎng)經(jīng)濟的基石。如果手機丟失了，要及時綁定新手機。

（4）不要使用任何的密碼“暗示”，攻擊者可以利用明顯的暗示發(fā)動攻擊。

（5）不要以任何方式直接提供用戶名，也不要使用隱藏表單字段或者Cookies提供用戶名。

（6）找回密碼的問題最好有足夠的隨機性，確保攻擊者無法輕易猜測出來。

（7）最終，用戶通過重重考驗，完成了密碼找回，一般是給用戶發(fā)送一封重新激活URL的電子郵件。即使到了這一步，也不要透露用戶以前的密碼等信息。如果是生成一個新密碼通過短信發(fā)給用戶，也要確保這組新密碼足夠隨機，避免讓攻擊者猜測到。

4.3.3 對密碼設置強度進行控制

關于如何設置高強度密碼，可從以下幾個方面著手。

（1）從內容上看，應該是自己能夠記得但他人難以聯(lián)想到的信息。用同學或者同事的個人信息會比用自己的安全；同時，可選擇較為隱私的紀念日或者詞匯進行組合。

（2）形式上，應該至少包括以下字符類別中的三組：大寫字母、小寫字母、數(shù)字、非數(shù)字符號（如&_等）。同時，可以進行一些簡單的記憶變化，如i變成！、字母o變成數(shù)字0、11變成2ge1（兩個一）。

（3）為了便于記憶，密碼應該盡量是有意義的內容，但需插入其他字符或者諧音，如“just for you”可以設置為“juST4_U”。同時可以在長度上進行拉伸，如“shezhimima”可以變成“s_he_zhi_mimA”（相隔一定間隙插入符號，并且將特定位置的字母大寫），又如“mypassword”可以變成“M。Y。P。A。S。S。W。O。R。D-1”。或者可使用數(shù)學運算符號來設置密碼，如“5＊5+5=30? Yes! ”。

（4）此外可以對自己的密碼進行安全級別區(qū)分，銀行、郵箱的密碼級別最高，社交網(wǎng)站等相對較低，論壇登錄等則更低。不同級別的密碼千萬不要設置成一樣。對于級別高的密碼不僅僅要設置得相對復雜，更要注意定時修改。

普通網(wǎng)民面臨的互聯(lián)網(wǎng)安全風險越來越嚴重，在目前大多數(shù)場景還是只能依靠小小的密碼保護我們的情況下，這根唯一的稻草，需要我們用心對待。

jquery實現(xiàn)密碼強度的智能判斷特效是一款非常實用的jquery特效，基本上每個有會員模塊的網(wǎng)站都可用上，可以提示會員注冊時輸入的密碼強度，其主要用到了keyup事件。

jquery核心代碼如下：

function checkPassword(pwdinput) {
        var maths, smalls, bigs, corps, cat, num;
        var str = $(pwdinput).val()
        var len = str.length;
        var cat = /.{16}/g
        if (len == 0) return 1;
        if (len > 16) { $(pwdinput).val(str.match(cat)[0]); }
        cat = /.＊[\u4e00-\u9fa5]+.＊$/
        if (cat.test(str)) {
            return -1;
        }
        cat = /\d/;
        var maths = cat.test(str);
        cat = /[a-z]/;
        var smalls = cat.test(str);
        cat = /[A-Z]/;
        var bigs = cat.test(str);
        var corps = corpses(pwdinput);
        var num = maths + smalls + bigs + corps;
        if (len < 6) { return 1; }
        if (len >= 6 && len <= 8) {
            if (num == 1) return 1;
            if (num == 2 || num == 3) return 2;
            if (num == 4) return 3;
        }
        if (len > 8 && len <= 11) {
            if (num == 1) return 2;
            if (num == 2) return 3;
            if (num == 3) return 4;
            if (num == 4) return 5;
        }
        if (len > 11) {
            if (num == 1) return 3;
            if (num == 2) return 4;
            if (num > 2) return 5;
        }
    }
    function corpses(pwdinput) {
        var cat = /./g
        var str = $(pwdinput).val();
        var sz = str.match(cat)
        for (var i = 0; i < sz.length; i++) {
            cat = /\d/;
            maths_01 = cat.test(sz[i]);
            cat = /[a-z]/;
            smalls_01 = cat.test(sz[i]);
            cat = /[A-Z]/;
            bigs_01 = cat.test(sz[i]);
            if (! maths_01 && ! smalls_01 && ! bigs_01) { return true; }
        }
        return false;
    }

效果如圖4-21所示。

4.3.4 采用多重安全機制實現(xiàn)多因素驗證

盡管多因素身份驗證和多層身份驗證是有優(yōu)勢的，但是大多數(shù)解決方案使用相同的底層網(wǎng)絡安全機制實現(xiàn)它們，這會造成問題，在安全需求嚴格的環(huán)境中尤其如此。例如，大多數(shù)基于Web的銀行系統(tǒng)使用SSL/TLS或HTTPS協(xié)議（Secure HyperText Transfer Protocol）作為底層網(wǎng)絡安全機制實現(xiàn)基本的兩因素身份驗證。

為了成功地登錄這種系統(tǒng)，最終用戶通常需要以下驗證因素。

（1）提交正確的密碼（所需的身份驗證信息是用戶應該知道的某種信息）。這是第一個身份驗證因素。

（2）提交用戶的ATM卡號的最后四位（所需的身份驗證信息是用戶擁有的某種東西）。這是兩因素身份驗證的第二個因素，系統(tǒng)假設只有用戶能夠看到自己的ATM卡。

在這些情況下，兩因素身份驗證能夠提高系統(tǒng)的安全性。要想入侵系統(tǒng)，黑客不但必須猜出用戶的密碼，還必須獲得ATM卡的號碼。這聽起來安全多了。但是要注意一點：對于兩因素身份驗證的兩個因素，系統(tǒng)使用相同的底層安全機制（SSL/TLS/HTTPS）實現(xiàn)網(wǎng)絡身份驗證。這會帶來幾個問題：如果黑客攻破了底層安全機制本身，會怎么樣？如果黑客在安全機制中發(fā)現(xiàn)了一個漏洞，讓他可以破解身份驗證，而不需要了解用戶的身份驗證信息，會怎么樣？如果有人利用安全機制的某些未知的限制破解了它，會怎么樣？因為兩因素身份驗證的兩個因素使用相同的底層安全機制實現(xiàn)網(wǎng)絡身份驗證，雙重身份驗證的優(yōu)勢完全被抵消了。這會帶來風險，對于需要非常安全的解決方案的系統(tǒng)，這可能是很嚴重的問題。

為了解決這個問題，這里推薦一種方法。實現(xiàn)多因素身份驗證的系統(tǒng)應該對不同的因素使用不同的底層安全機制，這會顯著降低風險。例如，如果兩因素身份驗證的第一個因素使用Kerberos作為底層網(wǎng)絡安全機制，第二個因素使用LIPKEY（一種使用SPKM的Low Infrastructure Public Key Mechanism, RFC 2847）或NTLM（NT LAN Manager，一種Microsoft身份驗證協(xié)議）作為底層網(wǎng)絡安全機制，那么黑客必須破解兩種完全不同的安全機制，這加大了入侵的難度，降低了風險。這種方法通過降低風險增強了系統(tǒng)的總體安全性。對于實現(xiàn)多層身份驗證的系統(tǒng)，也是如此。

可以使用GSS-API實現(xiàn)多因素身份驗證，從而實現(xiàn)使用多種安全機制的多因素身份驗證。這種技術組合可以降低使用相同底層安全機制實現(xiàn)多因素身份驗證解決方案的風險。通過使用GSS-API，系統(tǒng)可以對多因素身份驗證的不同因素使用不同的底層安全機制。只需在GSS-API握手過程中指定適當?shù)呐c機制相關的對象標識符（OID），就可以顯式地聲明應用程序對于身份驗證使用的底層安全機制。例如，在實現(xiàn)兩因素身份驗證的系統(tǒng)中，對于第一個身份驗證因素，開發(fā)人員可以向GSS-API傳遞一個特定的安全機制OID（如Kerberos）；身份驗證成功之后，再用另一個安全機制OID（如LIPKEY）發(fā)起用于第二個身份驗證因素的GSS-API身份驗證握手。因為Kerberos機制（基于純粹的對稱密鑰技術）和LIPKEY機制（基于對稱和非對稱密鑰技術）很不一樣，黑客很難同時破解這兩種機制。因此，這種系統(tǒng)降低了使用單一安全機制實現(xiàn)兩因素身份驗證的風險。

圖4-22說明了如何使用GSS-API框架為兩因素身份驗證顯式地指定兩種不同的安全機制，從而為UNIX系統(tǒng)提供更安全的身份驗證。要想入侵這樣的系統(tǒng)，黑客必須破解兩種完全不同的安全機制而不是一種，因此提高了安全性。