# 身份驗證備忘單
> 原文：[Authentication Cheat Sheet](https://www.owasp.org/index.php/Authentication_Cheat_Sheet)
> 來源：[身份驗證備忘單](http://cheatsheets.hackdig.com/?3.htm)
## 介紹
身份驗證是一種驗證一個人或實體聲明的身份是否正確的過程。身份驗證通常是由用戶提交用戶名或者ID、一個或多個只有給定用戶才知道的私人信息來完成。
會話管理是一個服務器維護與某個實體的交互狀態的過程。服務器需要記住如何在一個事務中響應后續請求。會話由服務器維護，服務器使用一個可以在客戶端與服務端傳遞的會話標示符來做這個工作。每個用戶都應該有一個獨一無二的會話，并且這個會話非常難以預測（以防被攻擊者猜解）。
## 身份認證主要指導方案
### 用戶ID
確保你的用戶名/用戶ID是不區分大小寫的。許多網站使用email地址作為用戶名，email地址正好就是不區分大小寫的。如果你不注意這個問題，可能會導致嚴重的混亂：smith和Smith竟然是不同的用戶。
### 適當的密碼強度控制
使用密碼認證時，密碼的強度是一個重要的關注點。一個健壯的密碼策略使通過手動/自動猜測密碼變得非常難。以下特征定義了一個健壯的密碼：
#### 密碼長度
更長的密碼能讓字符有更多組合，從而使得攻擊者更難猜到。
應用程序應該強制檢測最小密碼長度。
密碼少于10個字符的被視為弱密碼 ([1]).
限制最小密碼長度可能導致一些用戶難以記住自己的密碼，應用程序應該引導用戶使用口令句（句子或單詞的組合）密碼，口令句密碼比典型的密碼要長，但是更便于記憶。
最大密碼長度不應設置的過低，因為它會妨礙用戶創建口令句密碼。典型口令句密碼的最大長度是128個字符。
口令句密碼如果只包含小寫拉丁字符，少于20個字符就是弱密碼
每個字符都應計算在內！！！
確保用戶輸入的所有字符都包含在密碼內。我們發現有些系統會把用戶的密碼截斷。（例如：用戶輸入了20位密碼，系統截斷為15個字符）
這通常是因為設置所有密碼輸入框的長度為相同的最大長度導致的。這是特別重要的，尤其是你的最大密碼長度是20~30個字符的時候。
#### 密碼復雜度
應用程序應該包含密碼復雜性檢查規則，防止（用戶）使用容易被猜到的密碼。密碼機制應該允許用戶使用所有可輸入的字符作為其密碼的一部分，甚至空格也包括在內。密碼應該區分大小寫來增加密碼的復雜度。我們偶爾會在一些舊系統（例如大型機）上發現不區分大小寫的密碼。
密碼修改機制應該根據應用程序和它的用戶群至少引入一個最低標準的復雜度。例如：
密碼應該滿足下面列出規則的3~4條
* 至少一個大寫字符（A-Z）
* 至少一個小寫字符（a-z）
* 至少一個數字（0-9）
* 至少一個特殊字符（標點符號）——別忘了把空格也當成特殊字符
* 至少10個字符
* 最多128個字符
* 相同字符不要連續重復超過兩次（如：111）
應用程序需要更復雜的密碼策略，開發者需要清楚的了解這些策略是什么。
* 密碼策略需要明確的在修改密碼頁面顯示。
* 一定要列出你允許的所有的特殊字符。
推薦：
* 理想情況下，應用程序應將用戶輸入的密碼的復雜度（滿足了幾條密碼復雜度要求）顯示給用戶。
* 在實際應用中，如果用戶的密碼不滿足密碼復雜度要求或者確認密碼與密碼不同，提交按鈕應該是灰色的。這會讓用戶更容易理解并遵守你的密碼復雜度要求。
不管UI的表現是怎樣的，當一個用戶提交他們的修改密碼請求時：
* 如果新密碼不符合密碼復雜度要求，錯誤提示應描述其每條不符合的復雜度規則，而不是僅僅提示第一條不符合的規則。
修改密碼應該簡單，不要把它搞的像在黑暗中打獵一樣。
### 實現安全的密碼恢復機制
應用程序通常都有一個找回密碼的機制，幫助忘記密碼的人重新獲得賬號的控制權限。請查看《忘記密碼備忘單 獲取更多這方面的信息。
### 使用安全的方式存儲密碼
使用正確的加密技術是應用程序存儲密碼的關鍵。請查看密碼存儲備忘單查看更多這方面的信息。
### 密碼只應使用TLS傳輸
詳情請看： 傳輸層保護備忘單
登陸頁面及之后的身份認證頁面數據都必須完全（包括頁面上的所有元素）通過TLS傳輸。最初的登陸頁面（通常被稱為login landing page）必須配以TLS。如果登陸頁面沒有使用TLS，攻擊者就可以修改登陸表單，將用戶的身份憑證發送到任意一個網絡區域。如果登陸頁面之后的身份認證頁面沒有使用TLS，攻擊者就可以查看未加密的會話ID，威脅用戶的會話安全。
### 敏感操作需要重新認證
為了降低CSRF和會話劫持攻擊的危害，在用戶做修改密碼或郵箱修改敏感信息操作，修改貨品寄送地址等敏感交易操作時，需要用戶重新驗證身份。沒有這個對策，一個攻擊者可以通過CSRF或XSS攻擊，在無需知道用戶當前身份憑證的情況下，來執行敏感交易。另外，攻擊者可能通過臨時物理接觸用戶的瀏覽器或者竊取他們的會話ID來劫持用戶的會話。
### 多因素認證（MFA）
多因素認證（MFA）是指使用多個身份認證因素來登入系統或執行流程:
* 一些是你知道的（賬號信息或密碼）
* 一些是你擁有的（令牌或手機）
* 一些是你的特性（如生物特性）
類似OTP等使用硬件令牌實現的認證方案也是防范CSRF和客戶端惡意軟件攻擊的好辦法。市面上有很多MFA硬件可以集成到你的應用程序中。獲取更多信息請查看： [2]。
### SSL客戶端身份認證
SSL客戶端身份認證又稱雙向SSL身份認證。瀏覽器和服務器在TLS握手過程中，發送各自的SSL證書來表明身份。正如你可以通過詢問CA這個證書是否有效來驗證服務器的真實性，服務器同樣可以通過接受客戶端發送的證書來驗證用戶（詢問第三方CA或者自己的CA）。服務器為用戶提供一個獨有的簽名證書，特定用戶安裝證書后，可以用它來用訪問網站，沒有這個證書的用戶則無法訪問。
建議在下面的情況下使用此技術：
* 當用戶只從一臺電腦或瀏覽器訪問者這個網站時，這是可以接受的（甚至是首選）方案。
* 當用戶不會被“在瀏覽器上安裝SSL證書的繁瑣步驟”嚇到或者有專門的IT支持人員幫助他做這個事情的時候。
* 網站需要更加的安全的認證步驟的時候。
* 當網站是一個公司或組織的內網站點時，這也是一個很好的選擇。
對一個大量用戶和公共網站來說，這通常不是一個好主意。例如：對于Fackbook，這個方案是不適用的。同時，這個技術可以讓用戶不用輸入密碼來訪問網站（從而防止鍵盤記錄器竊取密碼信息）。不過使用密碼和SSL客戶端身份認證結合的認證方式依舊是個保護用戶安全的好主意。
查看更多信息，請訪問： [3] 或 [4]
### 身份認證和錯誤信息
在身份認證功能的開發中，不正確的錯誤信息提示可能會讓攻擊者能夠使用用戶ID和密碼進行枚舉。一個應用程序應該盡可能的以通用的方式返回HTTP或HTML響應。
#### 身份認證響應
無論用戶的用戶ID還是密碼輸入錯誤，應用程序都應該返回一個通用的錯誤提示信息。對于一個存在的賬號，應用程序不應該給予任何能夠標示賬號存在狀態的提示（如提示：當前賬號存在，但密碼錯誤）。
#### 不正確的響應示例
"用戶foo登陸：密碼錯誤
"登陸失敗：用戶ID錯誤"
"登陸失敗：賬號被禁用"
"登陸失敗：用戶未激活"
#### 正確的響應示例
"登陸失敗，用戶ID或密碼錯誤"
正確的響應不會標示出用戶ID或者密碼是否準確，從而保證攻擊者不能猜到有效的用戶ID。
#### 錯誤碼與URL
應用程序可能會根據嘗試進行身份認證的不同行為，返回不同的HTTP錯誤碼。當有匹配的認證結果時，返回200狀態碼；當沒有匹配的結果時，返回403錯誤碼。盡管給用戶顯示了一個通用的錯誤頁面，HTTP狀態碼的不同導致攻擊者可以用來判斷賬號有效還是無效。
### 防止暴力破解攻擊
如果攻擊者能夠猜測密碼，并且賬號不會因為多次失敗的身份認證嘗試而被禁用，那么攻擊者就有機會使用暴力破解技術盜取用戶的賬戶。自動暴力破解/密碼嘗試攻擊只是WEB應用常見的安全挑戰之一。當一個賬號的失敗登陸嘗試次數超過閾值，密碼鎖定機制應該生效。密碼鎖定機制也是有邏輯弱點的，攻擊者會在已知的賬號上進行大量的身份認證嘗試，進而鎖定所有的用戶賬號。鑒于密碼鎖定系統的目的是防止受到暴力破解攻擊，一個明智的策略是鎖定賬號一段時間（如20分鐘），這能顯著降低攻擊者的破解速度同時讓合法用戶能夠自動解鎖（防止被惡意鎖定）。
同時，多因素身份認證是一個防止暴力破解攻擊的非常強大的工具，因為認證憑證是一個動態變量。當使用多因素身份認證時，賬號鎖定機制可能就不必要了。
## 使用無需密碼的身份認證協議
雖然通過用戶名/密碼組合和使用多因素身份認證通常比較安全，但是仍然有些不適用的案例。一個例子是第三方應用程序想通過手機設備、另外一個站點、桌面或其他方式連接到web應用程序。這種情況下，讓第三方應用程序存儲用戶名/密碼是極不安全的。這會使易受攻擊的面擴大，超出你的控制。在這種情況下（或類似的案例），有一些身份認證協議可以保護你，避免你的用戶數據暴露在攻擊者面前。
### OAuth
開放授權(OAuth)是一種允許應用程序在不需要密碼或第三方身份認證提供商的情況下，驗證用戶的身份。它使用服務器生成的token，提供授權流程，從而讓客戶端（如手機應用程序）能夠告知服務器，當前是哪個用戶在使用這個服務。
建議使用和實現OAuth 2.0，因為第一個版本（OAuth1.0）容易遭到會話固定攻擊（session fixation）。
OAuth 2.0目前已經被Facebook, Google, Twitter和Microsoft等公司實現和使用。
### OpenId
OpenId是一個基于HTTP協議的使用身份提供者來識別用戶的工具。這是一個非常簡單的協議，允許服務提供者發起單點登錄（SSO）。這個協議允許用戶在多個網站重用一個OpenId身份提供者給予的身份。只需要提供給OpenId身份提供者密碼，而不需要提供其他任何網站的密碼。
因為這種方式非常簡單并能有效的保護密碼，OpenId得到廣泛的應用。一些知名的身份認證提供者Stack Exchange, Google, Facebook和Yahoo!都支持OpenId。
對于非企業環境，只要身份認證提供者可信，OpenId就是安全的而正確的選擇。
### SAML
安全斷言標記語言（SAML）通常被看做OpenId的競爭對手。推薦使用SAML2.0版本，因為這個版本功能全面并提供了很強的安全性。就像OpenId一樣，SAML也使用身份認證提供者角色，與之不同的是，SAML是基于XML并提供了更多的靈活性。SAML是依賴瀏覽器跳轉來發送XML數據的。不同于OpenId（譯者覺得此處原文可能錯誤，原文是Unlike SAML），SAML不僅能從服務提供者那里開始，而且能從身份認證提供者那里開始。用戶不用做任何事情，就能在不同的站點切換，并保證身份認證依舊有效，這讓身份認證過程變得簡單而透明。
OpenId占據大多數消費級市場，SAML通常是企業應用的首選。這是因為幾乎沒有被認可的企業級OpenId身份認證提供者（意味著他們檢查用戶身份的標準達不到企業身份認證的高標準）。SAML常常被用在內網環境，有時候甚至使用一個內網服務器作為身份認證提供者。
在過去的幾年里，應用程序如SAP ERP和SharePoint（使用ADFS2.0的SharePoint）決定使用SAML2.0來做身份認證。當web服務和web應用程序需要企業間聯合時，將其作為SSO實現的首選方案。
## 會話管理通用指南
會話管理與身份驗證直接相關。目前會話管理通用指南已經移到會話管理備忘單。
## 密碼管理工具
密碼管理工具可以是應用程序、瀏覽器插件或網絡服務，他們自動化的管理大量不同的憑證，包含記住密碼、自動填充、在不同的網站生成隨機的密碼等功能。web應用程序在這些情況下能幫助密碼管理工具更好的工作：
* 用戶名和密碼使用標準的HTML輸入框。
* 不在HTML表單區域禁用復制和粘貼。
* 允許非常長的密碼。
* 不使用多級登陸方案（用戶名在第一頁，密碼在第二頁）。
* 不使用嚴重依賴腳本（javascript等）進行身份驗證的方案。
## 作者與主編
Eoin Keary eoinkeary[at]owasp.org
