揭祕Web認證

我目前正在研究我正在開發的網站的用戶認證協議。我想創建一個身份驗證cookie，以便用戶可以保持登錄頁面之間。揭祕Web認證

這是我的第一擊：

cookie = user_id|expiry_date|HMAC(user_id|expiry_date, k)

凡ķ是HMAC(user_id|expiry_date, sk)和SK是一個256位的密鑰只知道服務器。 HMAC是SHA-256哈希。請注意，'|'是一個分隔符，而不僅僅是連接。

這看起來像這樣在PHP：

$key = hash_hmac('sha256', $user_id . '|' . $expiry_time, SECRET_KEY); 
$digest = hash_hmac('sha256', $user_id . '|' . $expiry_time, $key); 
$cookie = $user_id . '|' . $expiry_time . '|' . $digest;

我可以看到它的脆弱，因爲在陳述安全cookie協議重放攻擊，但應該是音量攻擊性和加密拼接。

問題：我在這裏是否有正確的線條，或者是否存在我錯過的大規模漏洞？有沒有一種方法可以防禦重放攻擊，它可以與動態分配的IP地址配合使用，並且不會使用會話？

NOTES

最新的材料我已閱讀：
該做什麼和客戶機認證的注意事項在Web 又名福等人的。
（https://pdos.csail.mit.edu/papers/webauth:sec10.pdf）

安全cookie協議 又名Liu等人。
（http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf）
，其擴展了先前的方法

硬化無狀態會話曲奇
（http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/）
，其還擴展對以前的方法。

由於主題非常複雜，我只是在尋找安全專家的解答並且具有創建和破壞身份驗證方案的實際經驗。

來源

2010-10-22 Joony

這是一個很好的問題，我想知道你是否會考慮開始賞金來恢復問題並讓它受到更多的關注。也許甚至可以通過電子郵件將問題鏈接發送給各種安全專家。 – 2013-02-11 14:02:20

您可能會從http://security.stackexchange.com/獲得更多答案。 – Edu 2013-02-11 14:16:51

好主意。 http://security.stackexchange.com/questions/30707/demystifying-web-authentication-stateless-session-cookies – Joony 2013-02-11 14:27:52

這一般很好，我在多個應用程序中做了類似的事情。它不會比會話ID更容易受到重播攻擊。您可以通過使用SSL保護令牌免於泄漏重播，與會話ID相同。

小建議：

將在大幹快上更改密碼（也許密碼生成櫃檯，甚至只是隨機鹽）更新了用戶數據的領域，包括標記，即場和簽署部分。然後，當用戶更改密碼時，他們也會使任何其他被盜取的令牌無效。如果沒有這個，你只能限制在合理的時間內允許令牌在到期前居住多久。（a）你可以有不同類型的令牌用於不同的目的（例如一個用於授權，一個用於XSRF保護），（b）你可以爲不同目的使用不同類型的令牌使用新版本更新機制，而不必使所有舊令牌失效。
確保user_id永遠不會被重新使用，以防止使用令牌訪問具有相同ID的不同資源。
管段分隔假定|永遠不會出現在任何字段值中。這可能適用於您（可能）處理的數字值，但您可能在某些時候需要更多參與的格式，例如URL編碼的名稱/值對。
雙HMAC似乎並不能真正幫到你。根據當前的理解，針對HMAC-SHA256的強力和密碼分析已經難以置信。

來源

2013-02-11 19:17:08 bobince

除非您的交易/秒將稅收你的硬件，我只能通過在cookie中的散列（即離開了USER_ID和EXPIRY_DATE - 無感給壞人任何比你瞭解更多信息絕對不得不）。
考慮到以前的動態IP地址（我沒有具體的細節，唉），您可以對下一個動態IP地址應該是什麼做出一些假設。僅對動態IP地址的不變部分進行散列將有助於驗證用戶，即使他們的IP地址發生更改。考慮到各種IP地址分配方案，這可能會也可能不會。
你可以得到有關係統和散列的信息，在Linux中，你可以使用uname -a（但也有類似的功能可用於其他操作系統）。足夠的系統信息，並且您可能完全跳過使用（部分）IP地址。這項技術將需要一些實驗。僅使用通常由瀏覽器提供的系統信息將使其更容易。
你需要考慮你的cookies應該保持多久。如果您可以與需要每天進行一次身份驗證的人一起生活，那麼您的系統身份驗證編碼會比每月僅允許一次身份驗證（以此類推）更容易。

來源

2013-02-15 19:48:45

這個系統的重點是不在服務器上存儲狀態。如果可能的話，隨機會話ID總是比這個系統更可取。 – ayke 2015-01-28 20:39:36

-1

我會認爲這個協議非常弱！

您的會話cookie不是高熵的隨機源。
服務器必須在每個頁面上執行非對稱加密以驗證用戶。
ANY用戶的安全性只依賴於服務器密鑰sk的安全性。

服務器密鑰SK是這裏最脆弱的部分。如果任何人都可以猜出它或竊取它，他可以作爲特定用戶登錄。

因此，如果爲每個會話和用戶生成sk，那爲什麼是hmac？我想你會使用TLS，如果沒有，請考慮你的協議因爲重播攻擊和一般的竊聽而破壞！

如果爲每個用戶生成sk，但不是爲每個會話生成，則它與256位密碼類似。

如果sk對於所有用戶都是相同的，那麼某人只需要破解256位，他就可以以任何他想要的用戶身份登錄。他只需猜測身份證和過期日期。

看一看digest-authentication。這是rfc2617指定的每個請求認證。對每個請求發送的使用隨機數的償還攻擊都是安全的。使用散列法進行竊聽是安全的。它被集成在HTTP中。

來源

2013-02-18 12:00:39 cIph3r

1）完全不相關。 2）不涉及不對稱密碼學，只有兩個或四個哈希。 3）這就是密碼學的重點，使得系統依賴於密鑰的安全性而不是協議的安全性。「有人只需要破解256位」是荒謬的。這大概是2^256次嘗試。祝你好運。 – ayke 2015-01-28 20:36:43

揭祕Web認證

回答

相關問題