Timeline for Is a simple random+hmac session cookie breakable?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 9, 2021 at 18:44 | comment | added | brynk |
(Forcing the use of TLSv1.2+ mitigates this somewhat, so comment is info only.) The rationale for signing a nonce with the long-lived token, is so you don't put the token itself on the wire. Without server presenting a changing aspect (eg. time or nonce), any bearer of the token is "authenticated" (replay attack). Secondly, if the adversary knows how the token is derived they can take any sid and perform some parallel search for static_secret 'til they get an input that produces a match. (This is why I say that the security rests on the static_secret, which must be high-entropy.)
|
|
| May 26, 2021 at 11:41 | vote | accept | capr | ||
| May 26, 2021 at 10:58 | comment | added | capr | I edited the question to specify the transport (https only) | |
| May 26, 2021 at 10:54 | comment | added | capr | providing the cookie is sent only through https, what is the additional security provided by the short-lived-token-to-avoid-exposing-the-long-lived-token part? is there a practical scenario that this covers? | |
| May 26, 2021 at 10:47 | comment | added | capr |
static_secret is banging on the keyboard for a full line of text, I think that should be entropy enough but good point, I'll put an assert(length of secret >= 32).
|
|
| May 26, 2021 at 10:42 | comment | added | capr | great points btw, yes, there needs to be a revocation list (so a session database, which must be hit for every cookie, just not for forged cookies), so maybe the phrase "stateless auth" is not correct, because only the cookie is authenticated statelessly in order to prevent hitting the db for forged cookies, but the session itself is authenticated statefully. | |
| May 26, 2021 at 10:36 | comment | added | capr | the only reason for using a random number for id instead of an auto-incremented id is simply to hide the information of knowing the sequence of past and future ids. if you don't care about that, you can assume it's an auto-incremented id, just to simplify the discussion. | |
| May 24, 2021 at 21:40 | history | edited | brynk | CC BY-SA 4.0 |
removed section on AWS-sig-v4
|
| May 24, 2021 at 12:42 | comment | added | brynk |
ps. I still stand by my original comment - the security in the system rests on the entropy in static_secret. Your PRNG can't add more than static_secret, so I've not considered it. (If it does then you need to address this first.) Also, in response to my observation to place a time-limit on things, you mention an estimate of a two-year expiration validity period for the cookie, which has me hooked .. so, it would be good to hear more about that as well!
|
|
| May 24, 2021 at 11:46 | comment | added | brynk | You're correct it isn't specific, and detracts from the answer .. If you could please edit your question to provide more detail on your requirement for stateless authentication then I will edit this answer to make it a lot more specific to your use-case. | |
| May 24, 2021 at 0:36 | comment | added | capr | ...as for putting an expiration time in the cookie, sure, but in my case that would be something like 2 years, so it won't help much, and also that's orthogonal to the question of how secure the cookie itself is, which is what I'm interested in with my question. | |
| May 24, 2021 at 0:30 | comment | added | capr | sorry but I don't see the point in any of this complication that aws does. is there any reason for any of that? | |
| May 23, 2021 at 4:39 | history | edited | brynk | CC BY-SA 4.0 |
added advice summary
|
| May 23, 2021 at 4:29 | history | answered | brynk | CC BY-SA 4.0 |