Effects of changing Django's SECRET_KEY

Question

I made a mistake and committed my Django project's SECRET_KEY into a public repository.

This key should have been kept secret according to the docs.

The Django project is live and has been running for a while with some active users. What are the effects if I change the SECRET_KEY? Will any existing users, cookies, sessions, etc.. be affected? Obviously, the new SECRET_KEY will no longer be stored in a public location.

sberder · Accepted Answer · 2016-07-07T09:00:47.330

247

Edit: This answer is based on django 1.5

SECRET_KEY is used in a lot of various places, I'll point out what is impacted by it first and then try to go over that list and give precise explanation of the impact.

The list of things using SECRET_KEY directly or indirectly:

JSON object signing
crypto functions for salted hmacs or seeding the random engine which impacts:
- password reset token
- comment form security to protect against forged POST requests
- form security
- protect against message tampering as the message framework may use cookies to pass messages between views.
- protect session data and create random session keys to avoid tampering as well.
- create random salt for most password hashers
- create random passwords if necessary
- create itself when using startproject
- create CSRF key

In reality a lot of the items listed here use SECRET_KEY through django.utils.crypt.get_random_string() which uses it to seed the random engine. This won't be impacted by a change in value of SECRET_KEY.

User experience directly impacted by a change of value are:

sessions, the data decode will break, that is valid for any session backend (cookies, database, file based or cache).
password reset token already sent won't work, users will have to ask a new one.
comments form (if using django.contrib.comments) will not validate if it was requested before the value change and submitted after the value change. I think this is very minor but might be confusing for the user.
messages (from django.contrib.messages) won't validate server-side in the same timing conditions as for comments form.

UPDATE: now working on django 1.9.5, a quick look at the source gives me pretty much the same answers. Might do a thorough inspection later.

edited Jul 07 '16 at 09:00

answered Mar 13 '13 at 11:16

sberder

4,505
2
26
15

2

I'm changing SECRET_KEY on my local dev server and that doesn't log me out, so it seems that at least sessions(cache) work correctly after change. Could you please elaborate further on what you mean by `data decode will break` and maybe point out some code(in django or example project) that will break? EDIT: still using django 1.4 - is that the case? – Kirill Zaitsev Dec 21 '13 at 19:40
@teferi I don't know about 1.4, it's a matter of taking a look at the code. I pointed at all the sources for each point, you can take a look at "protect session data and create random session keys". It's normal you're still logged in but you won't be able to read the data contained in the session as `SECRET_KEY` is used in `salted_hmac` used to hash the session data. – sberder Dec 24 '13 at 03:24
1

if it's used for password hash salt, doesn't that mean passwords in the database has to be reset? – Henning May 20 '14 at 18:32
11

@Henning I don’t think so. The [passwords are stored](https://docs.djangoproject.com/en/dev/topics/auth/passwords/) as `$$$` in auth_user, so the random salt is stored alongside the password in each case. – Dawn Drescher Jun 18 '14 at 05:16
2

Would the answer be significantly different for in Django versions > 1.5 ? (e.g. the now-current 1.9) – das-g Mar 17 '16 at 08:34
1

@sberder could you update the answer according to latest django version? – trikoder_beta Jul 07 '16 at 08:39
1

@sberder Having a hard time seeing where the secret key is used to "create a random salt for most password hashers" – chb Dec 29 '21 at 17:26
@chb keep in mind this was the case for 1.5.x, if you look at more recent branches that part of the code has changed very significantly. But for the sake of answering, checking back the [code in 1.5.x branch](https://github.com/django/django/blob/stable/1.5.x/django/contrib/auth/hashers.py), the [`BasePasswordHasher.salt()`](https://github.com/django/django/blob/stable/1.5.x/django/contrib/auth/hashers.py#L185) method uses [`get_random_string()`](https://github.com/django/django/blob/stable/1.5.x/django/utils/crypto.py#L57) from the `django.utils.crypto` module that uses `SECRET_KEY` – sberder Jan 04 '22 at 05:05
@sberder thank you for helpful response. it's precisely the older versions of the framework that I'm most interested in – chb Jan 05 '22 at 20:22

score 57 · Answer 2 · edited Jun 20 '20 at 09:12

Since this question was asked, the Django documentation has changed to include an answer.

The secret key is used for:

All sessions if you are using any other session backend than django.contrib.sessions.backends.cache, or are using the default get_session_auth_hash().

All messages if you are using CookieStorage or FallbackStorage.

All PasswordResetView tokens.

Any usage of cryptographic signing, unless a different key is provided.

If you rotate your secret key, all of the above will be invalidated. Secret keys are not used for passwords of users and key rotation will not affect them.

It wasn't clear to me exactly how I should rotate the secret key. I found a discussion of how Django generates a key for a new project, as well as a Gist that discusses other options. I finally decided to just get Django to create a new project, copy the new secret key into my old project, and then erase the new project.

cd ~/junk # Go to some safe directory to create a new project.
django-admin startproject django_scratch
grep SECRET_KEY django_scratch/django_scratch/settings.py # copy to old project
rm -R django_scratch

Update

It looks like Django added the get_random_secret_key() function in version 1.10. You could use that to generate a new secret key.

$ ./manage.py shell -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"
s!)5@5s79sp=92a+!f4v!1g0d0+64ln3d$xm1f_7=749ht&-zi
$ ./manage.py shell -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"
_)+%kymd=f^8o_fea1*yro7atz3w+5(t2/lm2cz70*e$2mn\g3
$

No, @kdazzle, if you look at the [source code for `startproject`](https://github.com/django/django/blob/1.8.6/django/core/management/commands/startproject.py#L31), you can see that it just generates a random string using the `crypto` module. — Don Kirkby, Nov 06 '15 at 19:28

score 20 · Answer 3 · answered Mar 02 '13 at 04:38

According to this page https://docs.djangoproject.com/en/dev/topics/signing/, the SECRET_KEY is mostly used for transitory stuff -- signing data sent over the wire so you can detect tampering, for example. It looks like the things that COULD break are:

Signed cookies, e.g. "remember my auth on this computer" type values. In this case, the cookie will be invalidated, the signature will fail to verify and the user will have to re-authenticate.
For any users that have requested links for a password reset or a custom file download, those links will no longer be valid. The users would simply have to re-request those links.

Someone with more recent and/or salient Django experience than me might chime in otherwise, but I suspect that unless you are explicitly doing something with the signing API, this should only create a mild inconvenience for your users.

It would probably cause a problem if you are running the same server using multiple processes. — dbn, May 02 '14 at 20:02
@osa would you want to log out ALL your users each time you push code/restart your server? — EralpB, Feb 28 '19 at 09:19

score 6 · Answer 4 · answered Mar 13 '13 at 01:36

The SECRET_KEY string is primarily used for encrypting and/or hashing cookies data. A lot of frameworks (including Django) come to this since default session cookies have its own drawbacks.

Imagine that you have form in django for editing articles with a hidden field. In this hidden field is stored ID of article you have editing. And if you want to be sure that no-one can send you any other article id, you will add an extra hidden field with hashed id. So if someone will change the ID, you will know it because the hash won't be the same.

Of course this is a trivial example but this is how the SECRET_KEY is used.

Django is internaly using it for example for {% csrf_token %} and few more things. It really shouldn't have any impact on your application if you will change it, based on your question and that you aren't using it.

The only thing is that maybe the session values will be dropped. So for example users will have to login into admin again, because django won't be able to decode session with different key.

score 4 · Answer 5 · edited Oct 07 '21 at 11:02

I made this same mistake. The default password was 50 long so I used powershell to generate a 50 long random string and replaced the old SECRET_KEY with it. I was logged in and after replacing the SECRET_KEY my previous session had been invalidated.

With Powershell (source):

# Load the .net System.Web namespace which has the GeneratePassword function
[Reflection.Assembly]::LoadWithPartialName("System.Web")

#  GeneratePassword(int length, int numberOfNonAlphanumericCharacters)
[System.Web.Security.Membership]::GeneratePassword(50,5)

With Bash (source):

# tr includes ABCabc123 and the characters from OWASP's "Password special characters list"
cat /dev/urandom | tr -dc 'A-Za-z0-9!"#$%&\''()*+,-./:;<=>?@[\]^_`{|}~' | head -c 100 ; echo

At this point I thought why not try a larger key, so I tried it with a 100 and 1000 long key. Both worked. If I understand the source code, the object returned by the signer function is a hmac hash in base64. RFC 2104 has this to say for the required length of a HMAC secret key.

Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC.

The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function. Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength. (A longer key may be advisable if the randomness of the key is considered weak.)

To translate into normal speak, the size of the secret key needs to be the same size as the output. The key also needs to be in bits. Each digit in base64 represents 6 bits. So if you had a 50 character password, you would have a 50 x 6 = 300 bit secret key. If you are using SHA256, then you would need a 256 bit key (sha256 uses 256 bits by definition). So a 50 long password should work unless you plan to use a hashing algorithm larger than SHA256.

But since any extra bits in the key are being hashed, the size of it wont drastically decrease performance. But it would guarantee you that you have a enough bits for larger hash functions. SHA-512 would be covered by a 100 long SECRET_KEY (50 x 6 = 600 bits > 512 bits).

Amirhossein Rafiee · Answer 6 · 2023-04-28T19:45:15.813

0

install django-extensions :

pip install django-extensions

You will need to add the django_extensions application to the INSTALLED_APPS setting of your Django project settings.py file :

INSTALLED_APPS = (
    ...
    'django_extensions',
)

Creates a new secret key that you can put in your settings.py:

python manage.py generate_secret_key

edited Apr 28 '23 at 19:45

answered May 06 '22 at 03:03

Amirhossein Rafiee

1
1

Effects of changing Django's SECRET_KEY

6 Answers6

Update

Linked