當使用屬性（httpOnly和secure = true）在服務器上設置Cookiee時，是否意味着它只能在服務器和客戶端之間的通信期間保護，而不是在此之後保護？ 換句話說，如果這個值最初是在plainText中 - 它也會在plainText中存儲在客戶端（在用https旅行之後） - 使它不安全/易受攻擊？通過https的plainText密碼保存在客戶端時是否保持安全。
1）密碼需要始終加密befors發送（即使使用https）？
2）httpCookiee（with secure = true）在哪裏存儲？這個存儲訪問是受保護的嗎？
你可能不想存儲密碼。
你需要的是存儲一些「用戶已經被認證」的標誌。
畢竟，你應該瞭解「摘要訪問認證」。存儲散列數據總是加上。
這個答案太短了，主要是因爲這裏有太多的可能性 - 以及太多的開放性問題。
處理返回用戶：
您可以管理（服務器端）會話數據庫。在cookie中只存儲會話ID。當用戶認證自己時，你的服務器端數據庫存儲他的狀態：「登錄」。當他註銷時，您將更改數據庫狀態：「註銷」。
處理返回用戶與「存儲密碼」沒有任何關係。例如，您可以通過外部授權服務來驗證用戶身份，例如open-id，twitter，facebook等，您只能通過某個會話ID或類似名稱來存儲他的狀態。
瀏覽器通常可以存儲用戶名/密碼，但是這一切時間應該是的用戶責任。當用戶只想記住他的密碼時，不應該以任何方式保存。
爲什麼要將您的應用程序和安全機制複雜化並將加密密碼存儲在cookie中 - 從任何角度來看哪些不是正確的解決方案？
簡單的流程：
感謝您的回覆。其實我希望在用戶返回我的網站時使用cookiee（所以他不需要登錄）。在發送之前使用散列是否更好（例如，使用rijndaelmanaged類）是否更好？ – 2012-07-22 18:25:26
看到我編輯的答案。 – jm666 2012-07-22 22:56:40
所以，對於我的印象中，它甚至沒有成爲一個SID，它甚至可以GUID或其他任何東西（除了真正的密碼），只要cookiee不會過期的用戶可以登錄 – 2012-07-23 07:08:00
1）我這麼認爲。因爲即使使用安全標誌，cookie也會以純文本形式存儲在瀏覽器緩存中。
2）這取決於瀏覽器和操作系統。對於Mac中的Safari，您可以在〜/ Library/Cookies/Cookies中找到它。plist你可以看到帶有安全標誌的cookie，但是用純文本。它可以被保護，只有所有者才能看到，但它永遠不會是好主意，一旦安全標誌被設置爲true，任何地方都有明文口令在您的計算機
謝謝，我瞭解除了部分之外的所有內容「......它可能受到保護，因此只有所有者才能看到......」。它如何受到保護？ – 2012-07-22 19:14:11
我的意思是cookie目錄基本上不能被計算機的任何其他用戶查看。更具體地說，用戶A和用戶B共享一個PC，並且每個用戶都有不同的登錄用戶，則用戶A不能看到用戶B的cookie目錄。但是，如果PC被盜或黑客攻擊或任何事情發生，密碼將以純文本形式存儲，並且可能很容易泄露。 – mask8 2012-07-23 12:44:29
，該cookie將被存儲在客戶端，甚至瀏覽器後加密關閉了。正如你所說這是不安全/脆弱的。
RESP。 1） 在使用Javascript發送密碼之前，可以對密碼進行加密，但由於https正在爲您進行加密，所以沒什麼意義。
RESP。 2） Cookie存儲在瀏覽器文件夾中。任何人都可以打開文件夾並使用文本編輯器查看cookie。
瀏覽器將處理密碼你。只需使用<輸入類型=「密碼」>並使用SSL就足夠安全。 而且，不惜一切代價避免在cookie中存儲密碼。
爲什麼在cookie中存儲加密passwoed是如此之多？ – 2012-07-22 18:39:06
該cookie很容易被欺騙。任何人都可以通過數據包嗅探器來獲取它，因爲每個請求都會向服務器發送cookie。 – 2012-07-23 01:17:27
或者如果黑客有權訪問客戶機，他可以用文本編輯器打開cookie。 一旦你有了cookie，通過字典攻擊，暴力破解或破解加密算法來解密它，只是時間問題。如果是SHA128或MD5，則不應超過2個月。 – 2012-07-23 01:25:48
人們總是可以使用Firebug/Chrome Dev查看cookies。 Tools /'document.cookie'和** no ** cookies沒有加密，所以請使用類似SID的東西。 HTTPS實現SSL（/ TLS？），因此利用RSA加密 – 2012-07-22 14:06:31
當**你想，以確保客戶的安全，你不需要總是隻加密密碼，** – 2012-07-22 14:10:16