當今互聯網給人們的生活帶來便利的同時，也讓網絡安全、信息安全成為當下熱議的話題。比如，數據泄露問題或者密碼泄露問題都給大眾帶來了極大的擔憂。就密碼管理而言，如今許多公司都會制定密碼管理策略，但是在制定密碼管理策略時，會有哪些常見的問題也需要引起高度關注。

雖然現在身份驗證技術已經更加成熟，但是密碼仍然是保護我們最敏感信息的主要途徑。密碼是防御潛在入侵者試圖模仿另一個用戶的第一道防線，但這樣的防護往往比較弱。用戶通常想創建易于記憶的密碼，使用出生日期或紀念日，甚至寫下來。開發人員則想盡可能少地投入密碼管理策略中。畢竟，研發新功能比密碼管理和存儲更令人興奮、更有趣。

許多密碼本身安全性非常弱，很容易猜得到，攻擊者就會有機可乘。最糟糕的是，我們信任的密碼存儲系統和其它關鍵信息的系統也面臨著許多安全挑戰。黑客會反復嘗試密碼數據庫進行盜竊，攻擊者同伙經常會破壞那些保護數據的模式。

我們探討一下公司在密碼管理策略方面做出的一些常見錯誤。讓在下面的討論中，我們將提到“在線攻擊”和“離線攻擊”。在線攻擊是對應用程序登錄頁面的攻擊，攻擊者試圖猜測用戶的密碼;離線攻擊是攻擊者獲取密碼數據庫副本，并嘗試計算存儲在其中的用戶密碼的攻擊。

您已限制用戶可以使用的字符數量或種類

• 推理：安全人員反復告訴開發人員驗證所有輸入以防止各種攻擊(例如，注入攻擊)。因此，根據某些規則來制定驗證密碼的規則必然是一個好主意，對吧?
• 攻擊：限制密碼中字符數量或種類的問題是減少了可能的密碼總數。這使得在線和離線攻擊更容易。如果我知道只允許在密碼中使用特殊字符!和@，那也就是我知道用戶密碼都沒有包含#，$，%，<和>等字符。此外，如果我知道只允許長度為8到12個字符的密碼，我也就知道所有用戶都沒有使用13個字符或更長的密碼。如果我想猜測用戶的密碼，這些規則可以讓我的工作變得更輕松。

但是SQL注入、跨站點腳本，命令注入和其它形式的注入攻擊呢?如果遵循密碼存儲最佳做法，您將在收到密碼后立即計算密碼的哈希值。然后，您將只處理哈希密碼，不必擔心注入攻擊。

• 防御：允許用戶選擇包含任意字符的密碼。指定最小密碼長度為8個字符，但在可行的情況下允許任意長度的密碼(例如，將它們限制為256個字符)。

您在使用密碼組合規則

• 推理：大多數用戶選擇容易猜到的密碼。我們可以通過讓用戶選擇包含幾種不同類型字符的密碼，以強制用戶選擇難以猜測的密碼。
• 攻擊：安全專業人員曾經認為，讓用戶選擇包含各種字符類型的密碼會增強密碼的安全性。不幸的是，研究表明這通常沒有幫助。 “Password1!”和“P @ ssw0rd”可能遵循了許多密碼組合規則，但這些密碼并不比“password”更強。密碼組合規則只會讓用戶難以記住密碼;它們不會讓攻擊者的工作變得更加困難。
• 防御：擺脫密碼組成規則。在應用程序中添加密碼復雜性檢查功能，告訴用戶他們的密碼選擇是否明顯強度偏弱。但是，不要強制用戶在其密碼中添加數字、特殊字符等。稍后，我們將討論如何使應用程序更安全，以防止安全性弱的用戶密碼。

您沒有安全地存儲密碼

• 推理：加密哈希函數是單向函數。因此，存儲哈希密碼應該可以防止攻擊者計算出它們。
• 攻擊：與前面討論過的兩個問題不同，這個問題通常只與離線攻擊有關。許多企業和組織的密碼數據庫都被盜了。當掌握了被盜密碼庫和強大的計算能力，攻擊者通常可以計算出許多用戶的密碼。

存儲密碼的常用方法是使用加密哈希函數，對密碼進行哈希處理。如果最終用戶選擇完全隨機的20+字符密碼，這種方法將是完美的。例如密碼設成：/K`x}x4%(_.C5S^7gMw)。不幸的是，人們很難記住這些密碼。如果簡單地對密碼進行哈希處理，則使用彩虹表攻擊就很容易猜到用戶選擇的典型密碼。

阻止彩虹表攻擊通常需要在對每個密碼進行散列之前添加隨機“鹽”。“鹽”可以與密碼一起存儲在清除中。不幸的是，加鹽的哈希并沒有多大幫助。 GPU非常擅長快速計算加鹽哈希值。能夠訪問大量加鹽哈希和GPU的攻擊者將能夠使用暴力破解和字典攻擊等攻擊合理且快速地猜測到密碼。

有太多不安全的密碼存儲機制，值得專門寫篇文章去探討。不過，我們先來看看您應該如何存儲密碼。

• 防御：有兩種主要機制可以防止攻擊者：一種是使哈希計算更加昂貴，另一種是向哈希添加一些不可估測的東西。

為了使哈希計算更加昂貴，請使用自適應哈希函數或單向密鑰派生函數，而不是密碼哈希函數來進行密碼存儲。加密哈希函數的一個特性是它們可以被計算出來;這個屬性導致它們不適合用于密碼存儲。攻擊者可以簡單地猜測密碼并快速散列以查看生成的哈希值是否與密碼數據庫中的任何內容匹配。

另一方面，自適應哈希函數和單向密鑰導出函數具有可配置的參數，這些參數可用于使哈希計算更加資源密集。如果使用得當，它們可以有助于充分減緩離線攻擊，以確保您有時間對正在受到攻擊的密碼數據庫做出反應。

這種方法的問題在于，每次要對用戶進行身份驗證時，都必須自己計算這些哈希值。這會給服務器帶來額外負擔，并可能使應用程序更容易受到DoS(拒絕服務)攻擊。

或者，您可以添加一些不可猜測的密碼哈希值。例如，如果要生成一個長隨機密鑰，將其添加到密碼哈希值以及唯一的隨機鹽，并且穩妥地保護密鑰，那么被盜密碼數據庫對攻擊者來說將毫無用處。攻擊者需要竊取密碼數據庫以及能夠使用離線攻擊計算出用戶密碼的密鑰。當然，這也產生了一個需要解決的非常重要的密鑰管理問題。

您完全依賴密碼

• 推理：密碼必須是驗證用戶身份的好方法。其他人都在使用它們!
• 攻擊：即使用戶執行上述所有操作，以使在線和離線攻擊更加困難，也無法阻止其它應用程序/網站執行不恰當的操作。用戶經常在許多站點上重復使用相同的密碼。攻擊者經常會在某平臺嘗試從其它平臺盜取密碼。

此外，用戶成為網絡釣魚攻擊的受害者，因為一些用戶無論密碼要求如何都會選擇安全性弱的密碼，等等。

• 防御：要求用戶使用多因素身份驗證登錄。請記住多因素身份驗證的含義：使用至少兩種不同因素進行身份驗證(典型因素是您知道的事情、擁有的物品、以及生物識別等等)。使用兩種不同的密碼(例如，密碼+安全問題的答案)不是多因素身份驗證。同時使用密碼和動態口令屬于多因素驗證的一種。此外，請記住，某些多因素身份驗證機制比其它多因素身份驗證機制更安全(例如，加密設備比基于SMS的一次性密碼更安全)。無論如何，使用某種形式的多因素身份驗證總是比僅依靠密碼更安全。

如果必須僅使用密碼進行身份驗證，用戶則還必須采取某種類型的設備身份驗證。這可能涉及設備/瀏覽器指紋識別，檢測用戶是否從不尋常的IP地址登錄，或類似的方式。

結論

如您所見，處理用戶密碼時需要考慮很多事項。我們還沒有談到密碼輪換策略、帳戶鎖定、帳戶恢復、速率限制，防止反向暴力攻擊等等。

有一個很重要的問題需要考慮：您是否可以將用戶身份驗證轉給其他人?如果你是一家金融機構，答案可能是否定的;如果您要把最新的貓咪寵物視頻給別人看，在此之前需要驗證，那這種情況下答案應該是可以的;如果您正在開發面向企業員工內部使用的應用程序，請考慮基于SAML的身份驗證或LDAP集成;如果您正在開發面向公眾的應用程序，請考慮使用社交登錄(即使用Google，Facebook等登錄)。許多社交網站已經投入大量精力來保護其身份驗證機制，并為用戶提供各種身份驗證選項。您不需要全盤重來。

在不必要的情況下實施用戶身份驗證會給企業和用戶都帶來麻煩，甚至有潛在危險。創建安全的用戶驗證機制困難且耗時。可您是真的想要處理被盜用的密碼數據庫，還是攻擊者在身份驗證機制中發現漏洞?而且用戶有更重要的事情要做，而不是記住另一個密碼!