基本驗證（Basic Authentication）

大多數人害怕使用基本驗證，這是由于啟用基本驗證后用戶所面對的界面所引起的：

選擇該驗證方式后，密碼不經數據加密就在網絡傳送。某些想危害你的系統的安全的人員可以使用一個協議分析器（protocol analyzer）在驗證過程中截獲用戶密碼。用戶驗證的詳細資料請參閱聯機幫助。

你確信要繼續?

這個消息的確像看起來的一樣糟糕。用戶名何密碼使用64位（Base-64）編碼。即使對于黑客新手，雖然他們仍然要訪問你的網絡并使用一個TCP/IP包探測器（TCP/IP packet-sniffer）截獲網絡協議包，64位的加密卻是易于破解的。結果黑客們不大可能會攻擊你的站點，除非你這里是一個非常吸引人的目標（比如銀行）。

我所接觸過的大多數Web管理員都了解挑戰/響應驗證和基本驗證的差異，但還是互換性的對待它們。基本驗證總是向用戶顯示對話框要求用戶輸入用戶名和密碼。然后輸入的信息被發送到IIS，IIS使用該用戶名和密碼執行一個本地登錄命令（Log on locally）命令在所在計算機進行本地登錄。因為這時IIS已得到了該用戶的密碼，所以它能夠響應遠程系統的挑戰信息，這樣就消除了委托的問題。(一個實際位于Web服務器的用戶使用基本驗證，而使用挑戰/響應的用戶仍能夠通過網絡訪問Web服務器)。實際上，用戶權限“從網絡訪問該計算機（Access this computer from the network）”和“本地登錄（Log on locally）”是需要特別設置的，而且也與所使用的驗證方法有關。要設置這些權限，使用域用戶管理器（User Manager for Domains）工具，然后在策略（Policies）菜單中選擇用戶權限（User rights）。

雖然有一些缺陷，但有兩種環境還是應該使用基本驗證：

你需要驗證使用非Internet Explorer瀏覽器的用戶。例如， Netscape Navigator只理解基本驗證。如果你選擇了挑戰/響應驗證和基本驗證，對于Internet Explorer將一定會使用Windows NT挑戰/響應驗證，而對于Navigator則會選擇基本驗證。如果你的數據是敏感數據，這是一個嚴重的涉及安全的問題。
你的站點對用戶進行驗證，同時你的ASP頁訪問其它Windows NT計算機的資源。經典的方式是通過使用ActiveX數據對象（ActiveX Data Objects）的ASP頁訪問位于遠程Windows NT計算機的數據庫。為了避免委托的影響，應確保所有請求的資源位于IIS本身所在的計算機上，而如果這不現實的話，就使用基本驗證。
普通驗證場景

無論何時當使用Windows NT挑戰/響應驗證一個Internet用戶時，當IIS使用UNC （Universal Naming Convention，統一命名約定）路徑訪問位于網絡中或本地的Windows NT 資源時都要考慮委托這個因素。當然，所有的本地資源當該用戶擁有正確的NTFS級權限時就能夠訪問。

UNC 路徑

當一個ASP頁的代碼訪問的數據庫使用的是基于文件的數據源（比如Access的.MDB文件），而且位置是通過一個UNC路徑確定時，會出現一個常見的有關委托的錯誤。即使資源位于本地，使用UNC標明位置會使Windows NT認為其位于網絡中的其他某地。UNC路徑由Windows NT網絡子系統處理。Windows NT與其各組件有很大的分離，以致如果你逐漸進入網絡子系統，直到其它涉及的Windows組件，你會位于網絡之外。這導致了一個令人糊涂、但卻相當有趣的情景：使用挑戰/響應驗證的IIS計算機正在訪問使用UNC路徑的本地資源。在效果上，它從自身請求驗證，是無法完成請求的。要解決這個問題，應使用IIS計算機上的絕對路徑（例如，C:\folder\resource.ext）。

委托，不!

另外還有一個與委托失敗相仿，但實際與委托毫無關系的更為難以確定的有關安全的失敗。它發生在一個三級計算機層次(瀏覽器到Windows NT/IIS服務器到Windows NT 遠程資源)。要確定是否錯誤是委托相關的，應檢查是否事務被驗證。如果是，問題差不多確定就是委托相關的。不過，如果頁面被匿名訪問，問題可能是IIS計算機本地的匿名帳戶造成的。這很容易發生，因為IUSR_machinename帳戶是在本地創建的。IIS扮演IUSR_machinename帳戶并嘗試訪問遠程計算機上的資源。挑戰信息被傳送后，IIS使用IUSR_machinename密碼散列值對挑戰信息進行正確的加密。不過，由于遠程信息會試圖使用其本地SAM數據庫和本地域控制器驗證密碼，而由于遠程Windows NT 計算機和域控制器都沒有記錄該帳戶，因此不可能驗證這些信息。

要避免這個問題，可以嘗試下面的方法：

在遠程系統中創建一個復制的IUSR_machinename帳戶，并確保具有相同的密碼。如果在IIS服務器試圖訪問的計算機上存在一個相同的本地帳戶，它不需要一個域控制器的幫助就能驗證提交的散列值。即使這兩個帳戶是在物理上分離的帳戶，如果它們的信息匹配，驗證還是會發生。你能夠僥幸使用這個技術是因為Windows NT所使用的散列算法會對不同用戶的兩個相同密碼產生相同的密碼散列值。在UNIX中，不會有這種情況。UNIX引入了一個被稱為“salt”的值，這樣具有相同密碼的兩個用戶會產生不同的散列值。當你希望IUSR_machinename帳戶只能訪問你的站點的特定遠程資源時，最好設置一個復制的本地帳戶。如果某人能夠饒過匿名帳戶密碼，他們也只能訪問網絡中存在本地帳戶的計算機。當然，其缺點在于如果匿名用戶需要訪問多個遠程資源，你會面臨管理員的噩夢，因為所有的帳戶及其密碼必須同步保存。
設置匿名登錄帳戶為域帳戶。要作到這一點，從本地IIS計算機上刪除IUSR_machinename 帳戶，并在域控制器上創建一個新帳戶。然后進入Internet服務管理器的WWW屬性對話框，在用戶名（Username）文本框中以Domain\Username格式(例如，BigDomain\JoeUser)輸入用戶信息。管理員這是最簡單的方法，但是當帳戶信息被危及后，侵入者將在網絡中獲得巨大的訪問權限。由于一些原因，我曾經和許多擔心IUSR_machinename帳戶成為黑客攻擊目標的網絡管理員進行過討論。實際上，盜用一個匿名登錄帳戶名和密碼不會比盜用CEO的帳戶和密碼容易，所以我更喜歡這種方法。
SQL Server 具有獨一無二的能力實現與其它計算機的非驗證聯接，可以有效地饒過Windows NT安全。如果安全問題并不是大問題(小型、私有Intranet通常非常安全)，你可能希望通過TCP/IP聯接到SQL server。SQL server會監視網絡傳輸并對TCP/IP請求直接作出反應，將taking Windows NT out of the loop. SQL具有自己的安全層，所以使用該功能你仍然能夠實現一個良好的安全配置。要使用該功能，在安裝SQL時在Security對話框中選擇TCP/IP sockets。
是否需要“安全對話框”的問題!

一些Web開發人員不希望用戶在每次訪問他們的站點時都必須輸入姓名和密碼。所以到底何時用戶需要提示一個對話框輸入他（她）的姓名和密碼呢?

當使用Windows NT 挑戰/響應驗證時，Internet Explorer將自動而且不可視的發送當前用戶的登錄名、域名和散列值到Web服務器。Internet Explorer不需要請求就進行這些操作，因為發送加密的挑戰信息不會帶來任何的安全風險。在這時會發生兩件事：

如果IIS計算機發送的信息能夠被域控制器進行驗證，用戶不需要可視化的提示就能得到驗證。
如果IIS未能識別瀏覽器發送的域名，那它將不知道需要驗證的信息來自何處。這種情況對于Internet用戶比Intranet用戶更為常見，因為在家中的用戶很少位于一個域中(而且即使如果是域用戶，其域控制器可能也無法被IIS計算機訪問)。Internet Explorer將提示用戶輸入新的姓名和密碼，從效果上講，"給我一些能夠使用的信息（Give me some information that I can use）。" 如果一個在家工作的雇員試圖訪問一個設置安全的站點，他將需要輸入他的姓名(按照BigDomain\JoeUser的形式)和密碼以使IIS能夠得到正確的域信息。在驗證Internet的用戶時以這種方式明確說明域名總是必要的。
在基本驗證方式中，用戶將被提示出現一個登錄對話框。你或許可以猜測一下原因。你將要做的事可能會危及你的Windows NT帳戶和密碼。所有的瀏覽器都明確的指出：如果你輸入了信息并按下OK，你必須知道你在做什么。我個人在一個安全的集成網絡中使用基本驗證并沒有問題，但如果沒有諸如Secure Sockets Layer（安全套接字）的附加安全層我將不會在Internet上使用基本驗證。Secure Sockets Layer在使用HTTPS://而不是HTTP://的特殊配置Web服務器上被調用。用戶再次需要明確說明所提交的帶有某個域控制器的信息。

黑客與你的站點

在我更進一步的說明之前，我需要聲明不做承諾：是的，積極的年輕黑客會讀到這篇文章并得到啟發，但是，相信我，對于黑客有許多比本文更好的信息來源。確保你的站點真正安全的最佳方法是了解站點的弱點何在(沒有人能比黑客更了解站點的薄弱之處)。在一個Web站點上有幾個區域可能被黑客嘗試攻擊或瀏覽。很明顯，在他們的手邊擁有一個具有管理員權限的用戶名和密碼是最佳的方法。得到一個用戶的密碼散列值也一樣好，因為密碼散列值有時可作為“密碼等效物”使用。密碼散列值可通過加密挑戰信息而用于回答挑戰。這樣做會賦予入侵者“從網絡訪問該計算機（Access this computer from the network）”權限。要被賦予“本地登錄（Log on locally）”權限，入侵者仍然需要實際的密碼。

一些程序已經被編寫出來特別用于抽取和破解Windows NT 域控制器SAM數據庫的密碼散列值。PWDump.exe和NTCrack.exe 都是在Internet上免費的且被系統管理員和黑客使用的該類程序。PWDump.exe程序用于將SAM數據庫的用戶散列值和帳戶信息轉寫到一個文本文件中。系統管理員使用PWDump 在混合環境中（比如UNIX和Windows NT共存）同步網絡服務器間的密碼列表，避免了在不同操作系統間使用不同的密碼。黑客使用PWDump和NTCrack對一個網絡執行惡意攻擊。黑客們通常自己不會運行PWDump，因為運行該程序需要有管理員級的權限(而如果一名黑客已經擁有管理員密碼，他也不需要運行PWDump)。不具有對網絡的管理員級訪問權的黑客可以創建一個特洛伊木馬（Trojan-horse）程序并將其通過e-mail發送給一個不受懷疑的用戶。如果該用戶以管理員權限登錄后運行e-mail 中的附帶程序，該程序將悄然無聲地復制SAM數據庫后將文本文件通過e-mail傳送給黑客。(最近我收到的一封電子郵件附帶的程序說： "click here"。我可以讓你猜猜如果我點擊那里會發生什么。)

即使黑客得到了PWDump的輸出結果，他們仍然沒有任何密碼。他們使用NTCrack 對密碼散列值表實行強行攻擊。NTCrack能夠從英文字典中搜尋所有單詞，使用數字和字母大小寫進行復雜的變換，在通常的Pentium計算機中運行數小時，產生上百萬個單詞和短語的所有可能散列值。然后它將文件中的散列值與從PWDump檢索到的散列值進行匹配，確定產生該散列值的密碼。記住即使MD4散列算法理論上是不可逆的，但NTCrack是基于一個事實：人們趨向于選擇易于記憶的密碼。如果NTCrack不得不按照Windows NT14個字符(包括數字、符號和大小寫)的最大密碼長度強行攻擊所有可能的密碼散列值，搜索過程在Pentium 120計算機上將要耗費幾十億年。(我不知是否有人曾經計算過在Pentium Pro計算機上所要耗費的時間，但我想在一定的短時期內還是安全的。) 如果你希望得到有關安全要素的更多的信息，請在Internet上搜索NTCrack或PWDump的內容。我個人喜歡在我的系統中使用NTCrack以確保密碼列表是安全的以及我的用戶選擇了安全的密碼。

結束語

我希望現在你對于影響Web開發的Windows NT安全的因素有了更好的認識。本主題面向站點最常見的使用驗證和動態傳輸、數據庫驅動內容。本文討論了安全的內部基礎和委托。以后的文章將建立在對這些內容的理解之上，并提出更為特定的配置因素和問題。如果你已經對IIS為完成工作所做的一切有了較好的了解，你將會把工作完成的更好。