密碼，鹽和認證

如果我有一個隨機的，16字符長的字母數字鹽（不同情況下），每個用戶生成和存儲，我是否也需要一個網站鹽？密碼，鹽和認證

換句話說，這是好嗎？

sha1($user_salt . $password)

我應該這樣做嗎？

sha1($user_salt . $password . $site_salt)

此外，

目前，我有一個加密的Cookie，看起來一個會話中的DB。在這個會話中，有一個user_id和一個user_token。然後我使用user_id查詢數據庫 - 如果數據庫=== user_token中的user_id + hash的sha1，則允許用戶通過。

我對每個頁面加載的user_id做第二次查詢，以便如果我刪除，禁止或更改用戶的密碼，該操作立即生效。

這就是我在這裏看到的網站和問題。你怎麼看？我錯過了什麼？

我需要添加角色檢查，但可能會添加另一個查詢（僅用於身份驗證的第三個查詢）。有小費嗎？

來源

2010-11-11 RS7

不，你不需要一個站點範圍內的鹽。鹽被用來使彩虹桌無用。如果你真的想要使用網站廣泛的鹽可以使用，但我不認爲這是必要的。

我想如果你的數據庫遭到破壞，並且有人意識到你的密碼已經用鹽進行散列處理，他們就會進入下一個安全性較低的站點（除非你正在運行一個值得入侵的站點 - 你不是：P）

來源

2010-11-11 01:07:43 alex

利用「網站範圍內」鹽可能是有用的。這意味着您的數據庫不僅要受到妥協，而且爲了真正理解您的密碼方案，您的源代碼也必須妥善處理。

我稱之爲「鹽」和「胡椒」的方法。每個用戶儲存的鹽，辣椒是整個站點的價值。

鹽
一個獨特的每人鹽的目的是使彩虹表無效。 salt通常存儲在數據庫中，並附加或附加到密碼中。有人意識到這一點仍然可以爲每個用戶運行基於字典的攻擊，但關於鹽的好處是他們不能使用彩虹表來處理這種常見的字典術語。

辣椒
「辣椒」，我把它叫做是一個潛在的未知字符串添加到每個這就意味着蠻力字典攻擊以鹽考慮密碼的目的將因缺乏辣椒的只是普通的思念。這也意味着每個角色的強力檢查需要「發現」更長的密碼，這可能需要更長的時間。一旦胡椒被發現，這些好處就消失了。

來源

2010-11-11 02:06:36 M2tM

-1

這聽起來像你試圖重新創建DIGEST-MD5或SCRAM。這兩種方法都允許您存儲站點唯一的非密碼字符串，並與另一方進行質詢/響應，以驗證他們是否具有密碼字符串，而不必在線路上發送密碼字符串。

來源

2010-11-11 02:14:05

sha1($user_salt . $password)

這是很常見的，但它是不好的。

一個典型的最終用戶密碼是~8個字符長，並且大部分保持爲7位ASCII字符集。所以一個典型的密碼大約是64位的隨機數據或更少。現代parallel brute-force attacks可以通過簡單地嘗試所有可能的密碼來擊敗此。改爲使用SHA256或SHA512不會實質性地改變結果，因爲最終用戶密碼是限制因素。

從這裏堆棧溢出我的閱讀，似乎是關於密碼存儲思想的2所學校：

你應該使用computationally expensive approach like BCrypt or scrypt。這樣暴力攻擊就變得不可行。這可以起作用，但用戶登錄時需要從服務器獲得更多的CPU電源。請參見excellent article for an overview of the rationale。
思想的第二個學校，雖然BCrypt和scrypt肯定工作，他們是不受歡迎的多用戶應用程序，因爲他們把太多的CPU時間 - 這使終端用戶觀望，或可能開闢了拒絕服務攻擊通過發送大量身份驗證請求。請參閱lengthy discussion here（請務必閱讀註釋）。

目前，我有一個加密的cookie，它查找數據庫中的會話。在這個會話中，有一個user_id和一個user_token。然後使用user_id查詢數據庫 - 如果數據庫=== user_token中的user_id + hash的sha1，則允許用戶通過。

您沒有提及的安全會話處理的一個要點是SSL everywhere to guard against Sidejack。用戶ID通常對安全性不利，因爲它們往往是可以猜測的（自動增加主鍵），或者最終導致URL錯誤。不用滾動自己的會話處理系統，是不是有可以使用的同行評審代碼庫？

來源

2010-11-13 05:15:44

目前，我有一個加密的 cookie，它在 DB中查找會話。在此會話中，有一個 user_id和一個user_token。然後我查詢使用USER_ID的DB - 如果的USER_ID +哈希在DB === user_token的SHA1，那麼用戶通過允許。

我做第二次查詢每個頁面加載USER_ID 所以，如果我刪除，禁止或改變密碼的用戶，動作有直接效果。

只有在情況下在談到有什麼不對這裏沒有其他人抓到：

您meantion USER_ID +哈希
你提到的SHA1你提到的cookie被加密第二個查詢（目前尚不清楚對我來說無論是查詢是什麼），也就是密碼更改敏感。

這聽起來很像您在cookie中存儲密碼或密碼散列，而不是在cookie中存儲會話標識符。我會建議反對。最大的原因是使用像這樣的密碼衍生產品很有可能將衍生產品轉換爲密碼等價物。

換句話說，所有攻擊者需要的都是密碼的散列，而不是密碼本身，以便有效地進行身份驗證。這樣做的問題是密碼的散列不會改變，除非密碼更改（不在您的控制下），而會話ID會在您修好時更改。

我的建議（如果您希望會話對密碼更改敏感）是在密碼更改時更改會話ID。

來源

2010-11-18 03:52:25 Slartibartfast

密碼，鹽和認證

回答

相關問題