簽名會話cookie。一個好主意？

爲了提高性能，我試圖消除一個普通的「會話cookie」，但是加密了cookie本身的所有信息。簽名會話cookie。一個好主意？

一個很簡單的例子：

userid= 12345 
time=now() 
signature = hmac('SHA1',userid + ":" + time, secret); 

cookie = userid + ':' + time + ':' + signature;

的時間將用於最大expirytime，所以餅乾不會靠永遠。

現在對於一個大問題：這是一個壞主意嗎？

我最好用AES256代替嗎？在我的情況下，數據不是保密的，但在任何情況下都不能改變。

編輯

一些好的批評和意見後，我想補充一點：

的「祕密」將是唯一的每個用戶和不可預測的（隨機字符串+用戶名？）
Cookie將自動失效（這是基於時間值+一定的秒數完成的）。
如果用戶更改密碼（或者甚至註銷？），祕密應該改變。

最後一點：我試圖想出減少數據庫負載的解決方案。這只是我正在調查的解決方案之一，但它是我最喜歡的。主要原因是我不必研究更適合這種數據的其他存儲機制（memcache，nosql），它使Web應用程序更加「無狀態」。

來源

2010-07-13 Evert

你的平臺是什麼？ – 2010-07-13 19:30:30

嗨米粉餅乾，這是PHP，但我離開它，以避免特定於平臺的討論。目前我們在多個web服務器上使用PHP，並使用Master-Master mysql設置。會話cookie被緩存在memcached中。我們的瓶頸主要是附加和刪除Cookie。複製還附加到輔助數據中心，並且會話相關查詢是流量的一大塊。 – Evert 2010-07-13 19:49:44

Evert，如果您用問題中概述的方法成功實施了整個客戶端會話，我會感興趣。您的實施細節是什麼使您的系統儘可能安全？謝謝:) – 2011-07-11 08:42:25

一個簽名令牌是什麼，你要發出一個令牌，然後，返回時，能夠確認您發佈的令牌的好方法，而無需任何數據存儲在服務器端。這對於以下功能很有用：

限時帳號登錄;
password-resetting;
抗XSRF形式;
限時提交表格（反垃圾郵件）。

它本身並不是會話cookie的替代品，但是如果它可以消除任何會話存儲的需要，那可能是件好事，即使性能差異不會很大。

HMAC是生成簽名令牌的一種合理方式。這不會是最快的;如果您知道並且可以避免擴展攻擊，則可以使用簡單的哈希來逃脫。我會讓你決定這是否值得你冒險。

我假設您使用的任何語言的hmac()已被設置爲使用合適的服務器端密鑰，沒有它，您不能擁有安全的簽名令牌。如果您要將您的整個身份驗證系統建立在此基礎之上，則此祕密必須牢固且受到良好保護。如果你必須改變它，每個人都會被註銷。

用於登錄，您可能需要額外的因素添加到標識，密碼生成編號密碼重置的目的。如果你喜歡，你可以在數據庫中重新使用哈希密碼的鹽。這個想法是，當用戶更改密碼時，它應該使任何已發出的令牌失效（除了瀏覽器上的cookie執行密碼更改，它將被重新發布的cookie取代）。否則，發現其帳戶的用戶已被盜用不能鎖定其他方。

來源

2010-07-13 18:54:33 bobince

添加世代號很有意義。謝謝！ – Evert 2010-07-13 18:58:35

讀到這個似乎是個好主意;將Cookie標記爲安全，設置到期時間，將其綁定到您網站的一個區域（例如，沒有用戶帳戶更改命令）。還將用戶代理字符串和IP地址散列到祕密中，以便cookie不會被盜用。請注意小於4k的cookie最大大小限制。有很多gotacha我認爲它更聰明地尋找更快的serverside會話impl（riak，memcached），而不是冒着這個安全漏洞。 – simbo1905 2014-04-28 05:57:38

是什麼讓你認爲這將提高性能與安全會話ID並從會話的服務器端組件檢索用戶標識和時間信息？

如果有東西必須是防篡改的，不要把它放在幼兒的手中。如同，即使使用防撬鎖，也不要將其交給客戶。

忽視意識形態問題，這看起來很不錯。你沒有隨機數。你應該補充一點。只是隨着用戶標識和時間一起存儲的一些隨機垃圾，以防止重播或預測。

來源

2010-07-13 18:35:15 Borealid

目前我們的會話存儲在主 - 主數據庫中，由一系列Web服務器使用。儘管它是一個簡單的BTREE，但我們希望減少佔位面積。修剪會讓io穿過屋頂。 – Evert 2010-07-13 18:55:03

@Evert這些表正確索引？你不應該看到「通過屋頂」的I/O。 – doug65536 2015-10-05 09:37:26

@DougGale：你正在回答很多很多年前的問題。 – Evert 2015-10-05 14:39:17

你不應該重新發明輪子。遠程開發平臺附帶的會話處理程序更安全，並且更容易實現。 Cookie應始終是非常大的隨機數字，鏈接到服務器端數據。包含用戶標識和時間戳的cookie不會幫助強化會話免受攻擊。

與每個會話使用加密隨機數相比，此提議的會話處理程序更容易受到攻擊。攻擊場景如下。

很可能您在所有會話中對您的HMAC計算使用了相同的祕密。因此，這個祕密可能是攻擊者用自己的帳戶登錄時所強制的暴力行爲。通過查看他的會話ID，他可以獲得除祕密以外的所有內容。然後攻擊者可以暴力破解這個祕密，直到hmac值可以被複制。利用這個祕密，他可以重建一個管理cookie並改變他的user_id=1，這可能會授予他管理權限。

來源

2010-07-13 18:48:46 rook

該代碼只是僞代碼，我打算添加一個祕密，所以我現在做了。我非常瞭解我的平臺的會話系統是如何工作的，這只是我正在處理數百萬次會話，而且我需要認真思考。我很欣賞答案，但我是一名坐着的程序員。爲什麼你認爲重新計算祕密是微不足道的。 Amazon AWS和OAuth大量使用它。 – Evert 2010-07-13 18:53:05

@Evert這是微不足道的祕密，祕密然後你需要攻擊者蠻橫這個價值。密碼隨機數**更安全**。 – rook 2010-07-13 19:00:27

沒有試圖聽起來防守，我只是試圖澄清我的情況。如果祕密將基於用戶的ID和/或密碼以及隨機字符串，這難道不會使它變得相當困難嗎？你是說沒有辦法可以做到這一點嗎？ – Evert 2010-07-13 19:04:20

是的，這是一個壞主意。

對於初學者來說，這並不安全。通過這種方案，攻擊者可以生成自己的cookie並冒充任何用戶。

會話標識符應當從一個大的（128位）空間由密碼隨機數生成器來選擇。

他們應該被保密，所以攻擊者無法竊取他們冒充的身份驗證的用戶。任何執行需要授權的操作的請求都應該是防篡改的。也就是說，整個請求必須具有某種完整性保護，例如HMAC，以便其內容不能被更改。對於Web應用程序，這些要求將不可避免地導致HTTPS。

你有哪些性能問題？我從來沒有見過一個Web應用程序，適當的安全性創造了任何類型的熱點。

如果該頻道沒有隱私和完整性，那麼您將面臨中間人攻擊。例如，沒有隱私，Alice將她的密碼發送給Bob。 Eve可以窺探它，並可以稍後以Alice身份登錄。或者，部分完整性，Alice將她簽名的cookie附加到購買請求併發送給Bob。 Eve截獲請求並修改送貨地址。 Bob驗證cookie上的MAC，但無法檢測到地址已被更改。

我沒有任何數字，但在我看來，中間人攻擊的機會在不斷增加。我注意到餐廳使用他們提供給客戶的Wi-Fi網絡進行信用卡處理。如果他們的流量不是通過HTTPS，圖書館和工作場所的人們往往容易被嗅探。

來源

2010-07-13 18:55:33 erickson

+1我完全同意。 – rook 2010-07-13 18:58:46

嗨埃裏克森，黑客如何生成一個沒有hmac隨機數/ cookie的cookie？ – Evert 2010-07-13 18:59:19

@Evert我回答了這個問題。 – rook 2010-07-13 19:03:13

我知道這個問題現在已經很老了，但我認爲用更新的答案更新答案可能是個好主意。對於像我這樣可能偶然發現的人來說。

在努力提高性能，我想試圖消除純「會話cookie」，但在 cookie自身的加密所有的信息。

現在對於一個大問題：這是一個壞主意嗎？

簡短的回答是：不，這不是一個壞主意，事實上這是一個很好的主意，並已成爲行業標準。

長的答案是：這取決於您的實施。會話很棒，速度很快，很簡單，而且很安全。然而，作爲一個無國籍的系統運行良好，部署需要多一點參與，可能超出小型項目的範圍。

實現基於令牌（餅乾）的認證系統現在是非常普遍，工作得非常好，爲stateless系統/ API的。這使得使用單個賬戶對許多不同的應用程序進行身份驗證成爲可能。即。使用Facebook/Google登錄{無關聯網站}。

像這樣實施oAuth系統本身就是一個大問題。所以我會留下一些文檔oAuth2 Docs。我也建議看看Json Web Tokens (JWT)。

額外

最後要注意：我試圖拿出解決方案來降低數據庫負載。這只是我正在調查的解決方案之一

Redis對於卸載數據庫查詢很有效。 Redis是一款內存簡單的存儲系統。非常快速的〜臨時存儲可以幫助減少數據庫命中。

來源

2017-06-01 14:52:46

簽名會話cookie。一個好主意？

回答

相關問題