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.