The following Stack Exchange Article on the CraftCMS Security Key is comprehensive and helpful.

1) Where To Put It

I’m wondering how I should proceed with the SECURITY_KEY which is now mandatory in Craft 3 (RC2). It has to be the same for one project, right? So it should be shared across developers. But is it a good idea to commit it to a Git repository? I guess not.

But then – where do I put it without losing it and still sharing it with team mates.

2) What If It Changed?

Due to some circumstances I lost the security key of the initial installation and added a new one. Could that lead to unwanted behavior down the road?

Enlightenment of any kind is much appreciated :)

First a bit of history:

Craft 2 has a similar concept where it would store a unique random security key in craft/storage/runtime/validation.key. Alternatively, you could set the validationKey config setting if you wanted to provide your own key instead of use the one generated by Craft.

Craft 2 would essentially only use this for encrypting cookie data in a browser for authenticated sessions. Because everything in craft/storage/runtime is temporary and could be deleted at any time, it is important in load-balanced environments to use the validationKey config setting and set it to the same key for every web instance behind the load balancer.

It is possible that a plugin might go through craft()->security->encrypt(), which takes the key into account, someone nukes the validation.key file that lives in craft/storage/runtime and Craft is unable to decrypt the data at that point.

Craft 3 decided that it would probably need to start encrypting data in the database at some point in the future, so it needed a more reliable way to guarantee there was a security key it could use.

So craft/storage/runtime/validation.key was deprecated and moved to craft/storage/security.key, the validationKey config settings was renamed to securityKey and Craft 3 now requires it to be set in some form or another.

Craft 3 also added another way to set it if you use the composer starter project via the .env SECURITY_KEY environment variable, so that you can use 'securityKey' => getenv('SECURITY_KEY'), in your craft/config/general.php file.

Now to the questions:

It has to be the same for one project, right?

It should be, if you want to reliably encrypt and decrypt data across environments.

So it should be shared across developers.

It should be, if you want to reliably encrypt and decrypt data across developers.

But is it a good idea to commit it to a Git repository?

Definitely not a public repository. Arguable in a private one.

Due to some circumstances I lost the security key of the initial installation and added a new one. Could that lead to unwanted behavior down the road?

You wouldn't be able to decrypt any data that was encrypted with the old key.

In the case of session cookies, the worst that would happen is you'd lose your current session. In the case of encrypted database email settings, you'd have to re-save your email settings. In the case that a plugin is doing some custom encrypting and decrypting and relying on Craft's craft\services\Security class to to it, you wouldn't be able to decrypt that data.

• Wow, I call that an answer. Thanks Brad! Quick follow-up question: user passwords are involved here too, right? – medoingthings Dec 19 '17 at 9:35
• User passwords are hashed, the security key doesn't make much sense in that case - except perhaps arguably as a salt. – Erik Weber Dec 19 '17 at 13:05
• 1Yeah, it has nothing to do with password hashing. – Brad Bell Dec 19 '17 at 18:21