關於在cookie中保存哈希密碼的安全風險有許多討論，因爲在訪問用戶的計算機時，黑客可以使用保存的密碼登錄。如果黑客可以訪問用戶的計算機，他可以捕獲密碼，因爲瀏覽器也可以在本地保存密碼（當然是加密的）。在cookie中設置的密碼與瀏覽器保存的密碼有什麼區別？在cookie中保存散列密碼真的很危險嗎？
出於顯而易見的原因，應該發送臨時GUID而不是密碼。無論如何，我認爲限制對登錄IP的訪問可能會讓攻擊者關閉門戶以使用本地保存的GUID。當然，它會限制日誌記錄的時間長度，因爲IP通常是動態的並且會定期變化;但我認爲它值得注意的安全性。任何想法？
我想你爲什麼想要在cookie中存儲散列密碼的原因是要創建一個「記住我」的cookie。所以你需要一個祕密的cookie值，這樣別人就不會輕易猜出它。任何有權訪問此值的人都可以以該用戶身份登錄，所以它實際上是一個「額外密碼」。
有這裏涉及到兩個風險：
最重要的是暴露密碼的風險。這不僅會使您的網站處於危險之中，而且還可能導致其他網站。大多數用戶重複使用他們的密碼，密碼可能會讓入侵者訪問用戶的電子郵件帳戶和網上銀行。有權訪問散列值的人可以使用蠻力或彩虹表來發現原始密碼（彩虹表是預先計算的散列的長列表）。彩虹桌很容易獲得超過8個字符的密碼，甚至更長。您可以通過醃製密碼來避免這種情況，以便它在創建哈希之前包含超過20個字符（還記得將鹽存儲在cookie中）。使用安全哈希算法計算出的正確醃製密碼哈希應該是相當安全的。
另一個風險與用戶必須更改其原始密碼以使散列密碼字符串無效的事實相關。一旦打開該功能，用戶無法真正關閉該功能。您可以在未檢查「記住我」按鈕時刪除Cookie，但如果Cookie已被泄露，則該cookie不起作用。如果他的電腦被盜了怎麼辦？如果用戶在一臺計算機上檢查了此按鈕，則他必須訪問該計算機才能禁用此功能。
當訪問用戶的計算機時，黑客可以使用保存的密碼登錄 。如果黑客有權訪問用戶的計算機，他可以通過 捕獲密碼，因爲瀏覽器也會在本地保存密碼（當然，加密爲 ）。
不確定這裏是什麼意思。如果您要求IE記住您網站的密碼，並且某人擁有您的計算機的密碼，並且可以使用您的IE，那麼可以，他可以使用您的密碼登錄。但是這與哈希或cookie等無關。
首先，無法檢索哈希密碼。所以如果有人有你的密碼散列，他不知道你的密碼。
當您登錄到請求密碼的站點時，您提供了加密發送的密碼。標準做法是將用戶的密碼存儲爲散列，即不是密碼本身。所以你輸入密碼，接收服務器將比較散列和存儲的散列。
現在與您在cookie中發送哈希密碼的問題有關，這與會話管理有關。即以確定用戶是否已經成功登錄。
恕我直言，只使用散列密碼作爲確定用戶是否已使用普通HTTP登錄的方式並不是一個好主意。
但如果這是你所要求的，這是另一個話題。
I.e.如何最好地通過HTTP連接進行會話管理
是的，在cookie中使用哈希密碼的安全性較低。有是將它保存在瀏覽器中並通過網絡發送的區別：除非您始終使用SSL，否則攻擊者無需訪問本機即可從請求中讀取cookie。
發送一個隨機值會更安全，因爲這樣就不會與用戶的實際密碼相關聯：可以通過忘記隨機值來使會話過期，而不必讓用戶更改密碼。此外，如果攻擊者確實從cookie中獲取散列值，那麼如果發送的是真的密碼，他們可能會恢復實際的密碼。
時候，你應該要求用戶重新輸入密碼：
保存散列密碼使得效率降低。另外，您應該已經使用安全Cookie（不會通過HTTP傳輸），HttpOnly（無法通過JavaScript訪問）來防止XSS攻擊。當然，如果有人剽竊他們的機器，他們只會安裝一個鍵盤記錄器。
使散列密碼安全的唯一事情就是散列發生在服務器上。 –
我知道你的意思;但是這裏散列密碼或GUID的目的是爲了長期使用，這對於嘗試錯誤攻擊是不能改變的。 – Googlebot
** [不要使用guid作爲會話令牌]（http://stackoverflow.com/questions/7732540/unpredictable-unique-identifier/7733025#7733025）** – Brian