為什麼光是SHA-256就不适合密碼儲存

檔案檢查和伺服器端的密碼儲存會解決不同的問題 。 密碼儲存也必須讓每一個下線猜測都非常昂贵 。

3分鐘後讀取讀取; 實作需要單獨審查
在本指南中

Hashing 不加密: 沒有相应的解密操作 。 不過在數據庫泄露後, 攻擊者可以隨機猜測並與失竊的記錄比對,

SHA的速度成了一個不利因素

SHA-256對完整性檢查和很多加密應用程式很有用。 它的速度不適合密碼儲存 。 加入鹽到 SHA256(salt + password) 估計的價錢還不夠高 食盐和計算成本有不同用途。

不要發明憑證格式或普通散列的環路 。 使用維持的密碼搜尋文庫 。

選擇一個专用的密碼搜尋功能

OWASP 更喜歡新系統的Argon2id, 在不可用時會以scrypt為替代。 PBKDF2 提供特定遵守要求 。 Bcrypt 仍然與遺傳系統相關,但有局限性,包括輸入长度。

使用函式庫功能建立與驗證, 產生鹽和參數儲存 。 從目標伺服器目前的指導和測量中選擇成本參數 。 也無法讓拒絕服務無足輕重。 限制網絡费率仍有必要。

明白鹽和胡椒吧

鹽是隨機的,是每個記錄的獨特性;它不需要秘密。 也將算法認證與驗證參數儲存在文庫的編碼記錄中。

胡椒是密碼數據庫外的可選密件。 可能會幫助一些違背規定的情況, 它既不能取代鹽,也不能取代适当的散動功能。

驗證成功後更新紀錄

在成功登入時, 請先檢查舊紀錄, 如果參數已过时, 則重新刷新已提交的密碼 。 您無法從已有的散列中收回原始密碼來移動整個數據庫 。 不活动帳號需要另外重新設定或移動政策 。 重覆不能解除之前的漏水。

在部署前, 檢查錯誤的密碼、 遺傳移、 長度限制與載入 。 永遠不要登入測試密碼或送去分析