為什麼光是SHA-256就不适合密碼儲存
檔案檢查和伺服器端的密碼儲存會解決不同的問題 。 密碼儲存也必須讓每一個下線猜測都非常昂贵 。
Hashing 不加密: 沒有相应的解密操作 。 不過在數據庫泄露後, 攻擊者可以隨機猜測並與失竊的記錄比對,
SHA的速度成了一個不利因素
SHA-256對完整性檢查和很多加密應用程式很有用。 它的速度不適合密碼儲存 。 加入鹽到 SHA256(salt + password) 估計的價錢還不夠高 食盐和計算成本有不同用途。
不要發明憑證格式或普通散列的環路 。 使用維持的密碼搜尋文庫 。
選擇一個专用的密碼搜尋功能
OWASP 更喜歡新系統的Argon2id, 在不可用時會以scrypt為替代。 PBKDF2 提供特定遵守要求 。 Bcrypt 仍然與遺傳系統相關,但有局限性,包括輸入长度。
使用函式庫功能建立與驗證, 產生鹽和參數儲存 。 從目標伺服器目前的指導和測量中選擇成本參數 。 也無法讓拒絕服務無足輕重。 限制網絡费率仍有必要。
明白鹽和胡椒吧
鹽是隨機的,是每個記錄的獨特性;它不需要秘密。 也將算法認證與驗證參數儲存在文庫的編碼記錄中。
胡椒是密碼數據庫外的可選密件。 可能會幫助一些違背規定的情況, 它既不能取代鹽,也不能取代适当的散動功能。
驗證成功後更新紀錄
在成功登入時, 請先檢查舊紀錄, 如果參數已过时, 則重新刷新已提交的密碼 。 您無法從已有的散列中收回原始密碼來移動整個數據庫 。 不活动帳號需要另外重新設定或移動政策 。 重覆不能解除之前的漏水。
在部署前, 檢查錯誤的密碼、 遺傳移、 長度限制與載入 。 永遠不要登入測試密碼或送去分析