Timeline for Is it safe to store the state parameter value in cookie?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 29 at 23:12 | comment | added | Shoe | I don't understand how encrypting it is making it more secure. If the attacker can read the request (including the cookies) via a MIM attack then he/she can do whatever they want already. Including replicating the request or even better get the session cookie once the authentication is done. | |
| Dec 26, 2018 at 22:40 | comment | added | gengkev | Hmm, I suppose that's fair, you wouldn't want the state to be the session ID unencrypted... | |
| Dec 26, 2018 at 10:51 | comment | added | Out of Band | @gengkev - I'd assume you're usually right, because usually the state isn't just opaque, it's actually random. But it doesn't have to be. You might get a state value that contains useful information, such as a concatenation of internal ids which shouldn't be leaked. | |
| Dec 24, 2018 at 16:12 | comment | added | gengkev |
If the encryption/decryption happens on the client server, all you're doing is replacing state with encrypt(state) which is no better than it was before. The decrypted state value isn't going to be useful to anyone if the client server server will only accept the encrypted one anyway.
|
|
| Oct 29, 2016 at 13:37 | history | edited | Out of Band | CC BY-SA 3.0 |
added 1257 characters in body
|
| Oct 29, 2016 at 13:29 | history | edited | Out of Band | CC BY-SA 3.0 |
added 1257 characters in body
|
| Oct 29, 2016 at 13:24 | history | edited | Out of Band | CC BY-SA 3.0 |
added 1257 characters in body
|
| Oct 29, 2016 at 13:12 | comment | added | Out of Band | It needs to be encrypted for several reasons: The first one is "on principle": One of the guiding security principles is that you layer security; so if for some reason your SSL connection is compromised (at work, we have a content-inspecting firewall which does MITM on SSL), they still can't get at the state value. The second reason is to protect the state value from the client: If you don't encrypt it, then malware on the client can steal the state value. In fact, you shouldn't just encrypt it; you should also use a MAC to see whether someone tried to tamper with the cookie contents. | |
| Oct 28, 2016 at 14:44 | comment | added | neverendingqs | I'm interested in why it needs to be encrypted. I thought SameSite + Secure is enough to make it only readable by the user-agent and the server. | |
| Oct 25, 2016 at 23:03 | history | edited | Out of Band | CC BY-SA 3.0 |
added 438 characters in body
|
| Oct 25, 2016 at 22:54 | history | edited | Out of Band | CC BY-SA 3.0 |
deleted 7 characters in body
|
| Oct 25, 2016 at 22:48 | history | edited | Out of Band | CC BY-SA 3.0 |
deleted 7 characters in body
|
| Oct 25, 2016 at 22:42 | history | edited | Out of Band | CC BY-SA 3.0 |
added 637 characters in body
|
| Oct 25, 2016 at 22:28 | history | edited | Out of Band | CC BY-SA 3.0 |
added 637 characters in body
|
| Oct 25, 2016 at 22:23 | history | edited | Out of Band | CC BY-SA 3.0 |
added 637 characters in body
|
| Oct 25, 2016 at 22:15 | history | answered | Out of Band | CC BY-SA 3.0 |