基於每秒 100 次嘗試的 Web 伺服器最低密碼安全性
這篇有見地的文章提出密碼不需要非常安全： http ://www.baekdal.com/tips/password-security-usability ?
這裡有一個特定的行，我覺得很麻煩：
實際數量有所不同，但大多數 Web 應用程序每秒無法處理超過 100 個登錄請求。
大多數 Web 應用程序只需要能夠防止每秒 100 次嘗試是真的嗎？當您處理可能被多個入侵者攻擊的分佈式系統時，這似乎是一個非常低的數字。
編輯 對我的問題的更多說明：根據大多數 Web 伺服器目前的平均性能，在蠻力攻擊期間可能的最大登錄嘗試次數是多少？我問的不是離線密碼攻擊，有人可以真正發起登錄嘗試。
換個角度來看，假設您需要一個不能使用 tar-pitting 或臨時帳戶禁用的系統（以防止黑客通過登錄嘗試進行 DoS），基於 Web 的系統上每秒實際登錄嘗試的次數非常有用。
但大多數 Web 應用程序每秒無法處理超過 100 個登錄請求。
**這意味著：**那篇文章的作者提出了一個未經證實（但並非完全不合理）的說法，即每秒發送超過 100 個登錄將是針對“大多數”Web 應用程序的有效拒絕服務攻擊。
對於每次登錄，典型的 web 應用程序都必須對密碼進行雜湊處理，並將其與數據庫中的雜湊表示進行比較。如果 webapp 使用良好的散列函式，這確實會使用相當多的 CPU。因此，這種說法可能並非完全不合理，但根據我的經驗，大多數 web 應用程序只使用簡單的雜湊，如 MD5、SHA1 或 SHA256，這不是 CPU 密集型的。
那篇文章的大錯誤就在這裡：
注意：以下範例基於每秒 100 個密碼請求。
在接下來的段落中，作者根據每秒 100 次嘗試的最大攻擊率對密碼強度提出了建議。對於線上攻擊來說，這可能是一個合理的數字，攻擊者連接到實時 Web 應用程序。
但是對於離線攻擊，攻擊者首先通過 fx 一個 SQL 注入攻擊下載了整個數據庫，這是完全錯誤的。例如，這裡是SHA1 的 NVIDIA CUDA 實現，它可以在小型伺服器集群上每秒執行 4700 萬次雜湊。
Web 應用程序只需要能夠防止每秒 100 次嘗試？
對不起，但不，你誤解了這部分。現在你從 webapp 所有者的角度來看待它，試圖防止線上暴力密碼猜測攻擊。你應該在這之前很久就採取行動。
- 如果個別帳戶有一定次數的失敗登錄嘗試（3、5、10、25 都可以是合理的數字），則應暫時禁用該帳戶。（或者更好的是，不要禁用帳戶，而是減慢登錄嘗試，也就是緩速/速率限制。）
- 如果您在系統範圍內每秒獲得數百次失敗的登錄嘗試，那麼您的日誌記錄/監控框架（Nagios 等）應該會向您發出警報，以便您了解攻擊。
**最後，**您可能想閱讀文章附帶的常見問題解答，它使作者的意思更加清晰。他在談論最終使用者如何生成相當安全且仍然容易記住的密碼——而不是關於密碼的伺服器端處理。
更新，問題編輯後：
根據大多數 Web 伺服器目前的平均性能，在蠻力攻擊期間可能的最大登錄嘗試次數是多少？
對於像 SHA1 這樣的簡單雜湊，我會說一個四核伺服器，假設有良好的程式技術，可以處理非常粗略的每秒 10,000 個請求。這將完全取決於所使用的 webapp 框架和程式，因為 HTTP 連接處理成本將支配 SHA1 計算速度。如果我們在 Prefork 模式下使用帶有 fx PHP 的 Apache，那麼這個數字會非常好，每台伺服器每秒可能有 2,000 個請求。
假設您需要一個不能使用 tar-pitting 或臨時帳戶禁用的系統
然後改變需求——那已經無法修復了。
在基於 Web 的系統上每秒實際登錄嘗試的次數非常有用。
同樣，您應該有警報，它會在暴力攻擊變得如此大規模之前很久就通知您。