Feature request: some way to rotate session secrets

[rmunn]

There might be reasons why someone might want to update the secret used in session cookies without invalidating sessions. Maybe the previous secret got exposed because someone checked it into Git and pushed it to GitHub, and although nobody has exploited it yet, the secret needs to be changed. Or maybe someone wants to set a policy for their site to rotate the session secret once a month, just on general principles. Either way, it would be useful to have a way to keep two session secrets, previousSecret and currentSecret.

The way I see it working is this. If a session fails to decrypt with currentSecret, decryption is attempted with previousSecret (unless it's undefined) and if that succeeds, the session is re-encrypted with currentSecret and a new cookie is issued. In addition, there would need to be a function provided called rotateSecret or some such, which would move currentSecret to previousSecret and then store a new value in currentSecret.

Doing secret rotation this way would mean that secrets cannot be rotated faster than the expiration time of any given session cookie (otherwise you'd need more than one previousSecret, i.e. if secrets were rotated every day but cookies were valid for 7 days, you'd need to been 7 previous secrets), but that would be fine in any conceivable scenario that I can think of.

[pixelmund]

This is now supported in v1.2.0 !

I've looked through the next-iron-session repository to see how they handle secret rotation and liked the approach. You can find more clear instructions to setup password rotation in the README

[rmunn]

Looks really good, thanks! Having a list is more flexible than the previousSecret I had suggested, since it would allow things like rotating secrets every day while keeping a 7-day expiration. (Which is more paranoid than my use case needs, but some people might need that).

The only thing I'd change about the implementation is that if a session cookie shows up with an ID not in the list, I'd prefer for the session to be destroyed rather than an error thrown. Because the most likely scenario where a cookie shows up with an invalid secret ID is when a secret was rotated out before that session expired, maybe because the secret was leaked (:scream: indeed). I'd much rather have that be treated the same as a session that timed out, rather than have to catch an exception and then figure out what happened to throw that exception.

Apart from that one quibble, thanks for a speedy implementation!

[pixelmund]

That's a good point i haven't thought of. Thanks for your request! I will try to get it in shortly.