5

I'm trying to create a stateless application server architecture and I would like to store session data in cookies. All pages using the session would be served over HTTPS. I was planning on using AES256 to ensure the client can't change the value of the cookie.

So the flow would look like this:

  1. Server receives request and decrypts the session cookie using the AES key which would be stored on the server.
  2. If the session is changed, the new session is encrypted using AES and the secret key. New value is then sent with the response.

Are there any serious flaws with this approach? I would like to get others opinions before I implement it.

3

I was planning on user AES256 to ensure the client can't change the value of the cookie.

Encryption provides confidentiality, it does not provide authentication.

If you do not want users to see a session data value, then you should encrypt then authenticate the value. This prevents a bit flipping attack from changing the value inside of the encrypted token because the keyed hash will no longer match if any bits are swapped.

If confidentiality is not required, then you can simply authenticate. For example, you could use a HMAC over SHA-256. This will show the end user what the value is in cleartext, however they will not be able to change the value because they will not be able to recalculate the keyed hash value without the key.

e.g. Your cookie would be set as follows:

Set-Cookie: Session=Username=admin&expires=20150809104100&hash=7C2CD7DB7DF4055E782E3A5F70487FEB9A5CABEED3FB70F5D8772586FD8B2759

Expires prevents a user from saving their cookie offline for later use when they are not an admin because the hash is calculated over expiry too:

Username=admin&expires=20150809104100

You can use this site to verify this (key used was stackexchange, however you should use a cryptographically secure pseudo randomly generated 128 bit key).

However, there is an internet standard technology for doing this already called JSON Web Tokens. The HS256 algorithm will generate the client-side token value calculated by HMAC over SHA-256.

If you want encryption as well choose A128GCM - note that a 128 bit key is sufficient for your data - a 256 bit key using AES-256 is slower and unnecessary. It may even be less secure as there are significant differences how AES processes a 128 and 256 bit key.

As JSON Web Encryption only supports authenticated encryption algorithms, this would also prevent bit-flipping.

2

Encryption alone is not enough because it only provides confidentiality and this task also requires authenticity.

If the plaintext in the attacker's cookie contains something like User number 9 is authenticated then the attacker can change bits in the ciphertext that when it is decrypted on the server it will say User number 1 is authenticated and be authenticated as user number 1. This is done by progressively changing bits in the cookie ciphertext and sending it to the server.

To prevent such tampering, you need to implement authenticated encryption that will detect (on the server) unwanted changes in the ciphertext (on the client).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.