[question] What are the consequences of setting empty "encryption key"?
karelbilek opened this issue · 6 comments
Describe the problem you're having
I am using gorilla.Sessions, and I do not fully understand the documentation to NewCookieStore.
The first key in a pair is used for authentication and the second for encryption. The encryption key can be set to nil or omitted in the last pair, but the authentication key is required in all pairs.
It is recommended to use an authentication key with 32 or 64 bytes. The encryption key, if set, must be either 16, 24, or 32 bytes to select AES-128, AES-192, or AES-256 modes.
What exactly happen on empty encryption key? The cookie won't be encrypted at all, so the end users might be able to read the data? Or is the encryption key auto-generated somehow?
This is both a question and a request for better documentation :)
If you omit the encryption key, cookies are only authenticated - that is, they cannot be tampered with by the client.
Cookie values are otherwise sent in plaintext, and I would generally advise using TLS (HTTPS) to protect cookies in transit, as a stolen cookie is a real risk. Storing sensitive values in the cookie itself is not recommended in general.
Noted on the docs :)
Cookie values are otherwise sent in plaintext, and I would generally advise using TLS (HTTPS) to protect cookies in transit, as a stolen cookie is a real risk. Storing sensitive values in the cookie itself is not recommended in general.
If the server uses TLS, authetication doesn't really matter that much anyway though, right. Since TLS is doing the auth already, so we don't really need second auth.
I think Karelbilek has a point in the case of using any other than the cookie store implementations. As long as your cookie is big and random the attacker will not be able to guess the cookie of another user. The whole idea of a persistent storage is to use this random value as a lookup key. Since the session manager is the only one with access to the store no one else is able to magically create a session. The chance of an attacker being able to guess an active session are as big as the odds of an attacker being able to generate a correct signature without knowing the private key.
It's not clear what the ask is here? Remove cookie authentication? Not going to happen.
- Many users of this package may put state in the cookie that would be at risk of being manipulated
- Detecting tampering is useful
- Not all applications or users of this package use TLS - unfortunate, but true.
- a layer of protection against store implementations with predictable IDs
Since the HMAC validation extremely minimal w.r.t CPU load, the risk vs. benefit here is unclear.