OWASP
認證
密碼維度
單因素認證、雙因素認證、多因素認證（密碼、手機動態口令、數字證書、指紋等各種憑證）。
密碼強度
長度：普通應用6位以上；重要應用8位以上，考慮雙因素；
復雜度：密碼區分大小寫；密碼為大寫字母、小寫字母、數字、特殊符號中兩種以上的組合；不要有（語義上）連續性的字符，比如123、abc；避免出現重復字符，比如 111；不要使用用戶的公開數據，或與個人隱私相關的數據作為密碼，比如 QQ 號、身份證、手機號、生日、昵稱、英文名、公司名等。
密碼保存
密碼必須以不可逆的加密算法，或單項散列函數算法，加密后存儲在數據庫中。目前業界比較普遍的做法：在用戶注冊時就已經將密碼哈希（MD5、SHA-1，不可逆，不沖突）后保存在數據庫中，登錄時驗證密碼僅僅是驗證用戶提交的密碼哈希值是否與保存在數據庫中的密碼哈希值一致，即服務器不會保存密碼原文。
破解 MD5 后密碼的方法——彩虹表：收集盡可能多的明文密碼和對應的 MD5 值，然后通過 MD5 值反查到該 MD5值對應的密碼原文。防御方法：加鹽，即 MD5(Username+Password+Salt)，其中 Salt 為一個固定的隨機字符串，應該保存在服務器端的配置文件中，妥善保管。
SessionID（會話編號）
當登錄認證成功后，服務器分配一個唯一憑證 —— SessionID 作為后續訪問的認證媒介。會話（Session）中會保存用戶的狀態和其他相關信息，當用戶的瀏覽器發起一次訪問請求時，將該用戶持有的 SessionID 上傳給服務器。常見做法是將 SessionID 加密后保存在 Cookie 中，因為 Cookie 會隨着 HTTP 請求頭發送，且受到瀏覽器同源策略的保護。生成的 SessionID 要足夠隨機，比較成熟的開發框架都會提供 Cookie 管理、Session 管理的函數，要善用這些函數和功能。
風險
一旦有效的 SessionID 泄露，則在其有效期內攻擊者能夠以對應用戶的身份訪問站點。泄露方式：Cookie 泄露（SessionID 保存在 Cookie 中的情況），Referer 的 URL 中泄露（URL 攜帶 SessionID 的情況）。
Session Fixation 攻擊
SessionID 沒有及時更替、銷毀，導致舊的 SessionID 仍然有效，一旦激活便可以正常使用。防御方法：在用戶登錄完成后要重新設置 SessionID；用戶更換訪問設備的時候要求重新登錄；使用 Cookie 代替 SessionID 的作用。
Session 保持攻擊
Session 是有生命周期的，當用戶長時間未活動，或用戶點擊退出后，服務器將銷毀 Session。① 如果只依賴 Session 的生命周期來控制認證的有效期，Session 保持攻擊可以通過腳本持續刷新頁面（發送訪問請求）來保持 Session 的活性。② 如果 SessionID 保存在 Cookie 中，依賴 Cookie 的定時失效機制來控制認證的有效期，那 Session 保存攻擊可以手動地修改 Cookie 的失效時間，甚至將 Cookie 設置為永久有效的 Third-party Cookie，以此延長 Session 的活性（Cookie 是可以完全由客戶端控制的）。防御方法：用戶登錄一定時間后強制銷毀 Session；當用戶的客戶端（IP、UserAgent、device）發生變化的時候要求重新登錄； 每個用戶只允許擁有一個 Session。
SSO（Single Sign On，單點登錄）
統一認證，缺點是風險集中，單點一旦被攻破，影響范圍涉及所有用單點登錄的系統，降低這種風險的辦法是在一些敏感的系統里再單獨實現一些額外的認證機制（比如網上支付平台，在付款前要求用戶輸入支付密碼，或通過手機短信驗證用戶身份）。
目前業內最為開放和流行的單點登錄系統是 OpenID —— 一個開放的單點登錄框架，使用 URI 作為用戶在互聯網上的身份標識。每個用戶將擁有一個唯一的 URI。在用戶登錄網站時，只需提交他的 OpenID（URI）以及 OpenID 的提供者，網站就會將用戶重定向到 OpenID 的提供者進行認證，認證完成后重定向回網站。
例如用戶 Ricky 在 OpenID 服務的提供者 openidprovider.com 擁有一個 URI，ricky.openidprovider.com；此時他准備訪問某網站的一個頁面（www.xxx.com/yyy.html），在xxx網站的登錄界面會提示請用 OpenID 登錄；於是 Ricky 輸入他的 OpenID（URI），即 ricky.openidprovider.com，然后點擊登錄；頁面將跳轉到 openidprovider.com 站點，進入認證階段；當認證成功后頁面自動跳轉到 www.xxx.com/yyy.html，如果認證失敗則不會跳轉。
授權
Web 應用中，根據訪問客體的不同，常見的訪問控制可分為 基於 URL 的訪問控制（常用），基於方法（method）的訪問控制（基於 Java 的 Web 應用中） 和 基於數據的訪問控制。
垂直權限管理
定義角色，建立角色與權限的對應關系——基於角色的訪問控制（Role-Based Access Control，RBAC）。用戶→角色→權限。例如 Spring Security 中的權限管理（功能強大，但缺乏一個管理界面可供用戶靈活配置，每次調整權限都要重新修改配置文件或代碼）；PHP 框架 Zend Framework 中使用 Zend ACL 做權限管理。使用 RBAC 模型管理權限時應當使用 “最小權限原則”，“默認拒絕”。
水平權限管理
水平權限問題出現在 RBAC 模型中的同一種角色的權限控制上，系統只驗證了能訪問數據的角色，但沒有反過來再對用戶與數據的權限關系做細分。此時需要基於數據的訪問控制。
OAuth
OAuth 是一個在不提供用戶名和密碼的情況下，授權第三方應用訪問 Web 資源的安全協議。三個角色：用戶（User）、服務提供方（Server）、資源持有者（Resource Owner）。現在的版本是 OAuth2.0。
沒必要自己完全實現一個 OAuth 協議，使用第三方實現的 OAuth 庫是個不錯的選擇：
ActionScript/Flash，C/C++，clojure，.NET，Erlang，Java，JavaScript，Perl，PHP，Python，Qt，Ruby，Scala 都有。