[2.2.x] Feature Suggestion: Multiple values for application.secret

[t.det...@uq.edu.au]

Like all frameworks using cookie-based sessions, the linchpin to session security in Play Framework is the signing key for session cookies. There's discussion around setting it to something secure initially, but allowing seamless rotation would probably be a good idea too so the secret remains a moving target. For Koa, it's a core feature, and Heroku now have a plugin for performing automatic key rotation on a fortnightly basis. Both mechanisms work by accepting values produced by older keys after rotation to a new key so that users don't notice the switch.

To implement this in Play Framework I suggest altering play.api.libs.Crypto to allow either a list or a string for application.secret. In terms of operation, Crypto.sign and Crypto.encryptAES use the first value for the list of secret keys, but Crypto.extractSignedToken and Crypto.decryptAES check all secret keys. Best case performance would be similar, with obviously slower worst-case performance for tampered values.

Does this sound worthwhile? I've been playing around with the code, and other than processing ConfigException$WrongType it doesn't appear too difficult.

-- Tim

[Fernando Correia]

I second this idea. Periodically rotating keys is a good practice. At a minimum, it should be easier to upload a new version to production with a new secret key that would still accept the previous secret key.

For an example, Windows Azure Storage supports two keys[1]: a primary and a secondary. This scheme is designed for easy rotation. You can periodically move the secondary key value to the primary key, discarding the old primary key value, and generating a new value for the secondary key. So at any time the service accepts two keys and the clients can keep working as you rotate the keys.

[1] http://www.windowsazure.com/en-us/documentation/articles/storage-manage-storage-account/#regeneratestoragekeys

[Martin Pallmann]

+1 from me.

You can't really be secure if you can't roll the secrets...

Mybe you want open an issue on github for that.

-Martin

[Martin Pallmann]

Damn. Just saw the post is one year old and not a month. Maybe still it would be good to have something like this?

[James Roper]

This should be much easier now to do that we have DI, it shouldn't be too difficult to provide an alternative implementation of the Crypto API.

For manual rotation, implementing is easy.  For automatic rotation, the difficulty comes in that you need somewhere to store the keys.

On 27 February 2015 at 02:26, Martin Pallmann <sayh...@martinpallmann.de> wrote:

Damn. Just saw the post is one year old and not a month. Maybe still it would be good to have something like this?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Roberto Tyley]

On Thursday, February 26, 2015 at 11:15:29 PM UTC, James Roper wrote:

This should be much easier now to do that we have DI, it shouldn't be too difficult to provide an alternative implementation of the Crypto API.

For manual rotation, implementing is easy.  For automatic rotation, the difficulty comes in that you need somewhere to store the keys.

As part of the GDPR work we're doing at the Guardian, I've created a library against Play 2.6 to enable automatic Application Secret rotation in a cluster of Playframework servers:

https://github.com/guardian/play-secret-rotation

The library allows for an overlap period (say, a few hours) during which cookies signed with either the old or new secret are accepted, so users aren't booted off their existing sessions. I've also included an implementation that uses AWS Parameter Store as it's backing datastore for the secret. We now automatically rotate our Application Secret every 6 hours :)