<p>Craft 3, .env, SECURITY_KEY variable.</p>

CC BY-SA 4.0
2020-03-03T10:52:29.257Z
2020-03-03T10:52:29.257Z
user10604
<p>First a bit of history:</p>

<p>Craft 2 has a similar concept where it would store a unique random security key in <code>craft/storage/runtime/validation.key</code>.  Alternatively, you could set the <a href="https://craftcms.com/docs/config-settings#validationKey" rel="noreferrer">validationKey</a> config setting if you wanted to provide your own key instead of use the one generated by Craft.</p>

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

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

<p>Craft 3 decided that it would probably need to start <a href="https://github.com/craftcms/cms/issues/1977" rel="noreferrer">encrypting data in the database</a> at some point in the future, so it needed a more reliable way to guarantee there was a security key it could use.</p>

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

<p>Craft 3 also added another way to set it if you use the composer <a href="https://github.com/craftcms/craft" rel="noreferrer">starter project</a> via the <code>.env</code> <a href="https://github.com/craftcms/craft/blob/master/.env.example#L5" rel="noreferrer">SECURITY_KEY</a> environment variable, so that you can use <code>'securityKey' =&gt; getenv('SECURITY_KEY'),</code> in your <code>craft/config/general.php</code> file.</p>

<p>Now to the questions:</p>

<blockquote>
  <p>It has to be the same for one project, right?</p>
</blockquote>

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

<blockquote>
  <p>So it should be shared across developers.</p>
</blockquote>

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

<blockquote>
  <p>But is it a good idea to commit it to a Git repository?</p>
</blockquote>

<p>Definitely not a public repository.  Arguable in a private one.</p>

<blockquote>
  <p>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?</p>
</blockquote>

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

<p>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 <code>craft\services\Security</code> class to to it, you wouldn't be able to decrypt that data.</p>

CC BY-SA 3.0
2017-12-19T09:35:03.450Z
Wow, I call that an answer. Thanks Brad! Quick follow-up question: user passwords are involved here too, right?
medoingthings
CC BY-SA 3.0
2017-12-19T13:05:57.747Z
User passwords are hashed, the security key doesn't make much sense in that case - except perhaps arguably as a salt.
Erik Weber
CC BY-SA 3.0
2017-12-19T18:21:45.303Z
Yeah, it has nothing to do with password hashing.
Brad Bell
CC BY-SA 3.0
2017-12-18T19:11:05.370Z
2017-12-18T19:11:05.370Z
Brad Bell
<h1>1) Where To Put It</h1>

<p>I’m wondering how I should proceed with the <code>SECURITY_KEY</code> 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.</p>

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

<h1>2) What If It Changed?</h1>

<p>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? </p>

<p>Enlightenment of any kind is much appreciated :)</p>

<craft3><security>
How to handle the SECURITY_KEY?
# How to handle the SECURITY_KEY?

(Asked by: username_0 on 2017-12-18)

# 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 :)

**Tags:** craft3, security

---

## 2 answers

### Answer by username_2 on 2017-12-18. Score: 17 | Accepted answer

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](https://craftcms.com/docs/config-settings#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](https://github.com/craftcms/cms/issues/1977) 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](https://github.com/craftcms/craft) via the `.env` [SECURITY\_KEY](https://github.com/craftcms/craft/blob/master/.env.example#L5) 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.

> **Comments:**
> **username_0**: Wow, I call that an answer. Thanks Brad! Quick follow-up question: user passwords are involved here too, right?  
> **username_3**: User passwords are hashed, the security key doesn't make much sense in that case - except perhaps arguably as a salt.  
> **username_2**: Yeah, it has nothing to do with password hashing.  

---

### Answer by username_1 on 2020-03-03. Score: 0

Craft 3, .env, SECURITY\_KEY variable.


---

