Я допустил ошибку и передал проект Django SECRET_KEY
в публичный репозиторий.
Этот ключ должен храниться в секрете в соответствии с документами https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SECRET_KEY
Проект Django работает вживую и некоторое время работает с некоторыми активными пользователями. Каковы эффекты, если я изменю SECRET_KEY
? Будут затронуты любые существующие пользователи, файлы cookie, сеансы и т.д.? Очевидно, что новый SECRET_KEY
больше не будет храниться в общедоступном месте.
Изменить: этот ответ основан на django 1.5
SECRET_KEY
используется во многих местах, я укажу, на что он воздействует первым, а затем попытайтесь перебрать этот список и дать точное объяснение воздействия.
Список вещей, использующих SECRET_KEY
прямо или косвенно:
startproject
В действительности многие элементы, перечисленные здесь, используют SECRET_KEY
через django.utils.crypt.get_random_string()
, который использует его для засеивания случайного движка. На это не повлияет изменение значения SECRET_KEY
.
Пользовательский интерфейс, непосредственно влияющий на изменение значения, это:
django.contrib.comments
) не будет проверяться, если она была запрошена до изменения значения и отправлена после изменения значения. Я думаю, что это очень незначительно, но может быть запутанным для пользователя.django.contrib.messages
) не будут проверять серверную сторону в тех же условиях синхронизации, что и для формы комментариев.UPDATE: теперь, работая над django 1.9.5, быстрый взгляд на источник дает мне почти одинаковые ответы. Можете провести тщательную проверку позже.
Поскольку этот вопрос был задан, документация по Django была изменена и теперь содержит ответ.
Секретный ключ используется для:
- Все сеансы, если вы используете какой-либо другой сеансовый бэкэнд, кроме
django.contrib.sessions.backends.cache
, или используете по умолчаниюget_session_auth_hash()
.- Все сообщения, если вы используете
CookieStorage
илиFallbackStorage
.- Все токены
PasswordResetView
.- Любое использование криптографической подписи, если не предоставлен другой ключ.
Если вы поверните свой секретный ключ, все вышеперечисленное будет признано недействительным. Секретные ключи не используются для паролей пользователей, и поворот ключей не повлияет на них.
Мне не было ясно, как именно я должен повернуть секретный ключ. Я нашел обсуждение того, как Django генерирует ключ для нового проекта, а также Gist, в котором обсуждаются другие варианты. В конце концов я решил просто заставить Django создать новый проект, скопировать новый секретный ключ в мой старый проект, а затем стереть новый проект.
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
Похоже, Django добавил get_random_secret_key()
в версии 1.10. Вы можете использовать это для генерации нового секретного ключа.
$ ./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
$
startproject
, вы увидите, что он просто генерирует случайную строку с использованием модуля crypto
.
В соответствии с этой страницей https://docs.djangoproject.com/en/dev/topics/signing/, SECRET_KEY в основном используется для переходного материала - подписание данных, отправленных по проводу, чтобы вы могли обнаружить например, фальсификация. Похоже, что вещи, которые МОГУТ разорваться, следующие:
Кто-то с более недавним и/или значительным опытом Django, чем я, мог бы перезвонить в противном случае, но я подозреваю, что, если вы явно не делаете что-то с подписывающим API, это должно только создать неудобство для ваших пользователей.
Строка SECRET_KEY в основном используется для шифрования и/или хэширования данных cookie. Множество фреймворков (в том числе Django) приходит к этому, поскольку файлы cookie по умолчанию имеют свои собственные недостатки.
Представьте, что у вас есть форма в django для редактирования статей со скрытым полем. В этом скрытом поле хранится идентификатор статьи, которую вы редактируете. И если вы хотите быть уверены, что никто не может отправить вам какой-либо другой идентификатор статьи, вы добавите лишнее скрытое поле с хэшированным идентификатором. Поэтому, если кто-то изменит идентификатор, вы это узнаете, потому что хэш не будет таким же.
Конечно, это тривиальный пример, но именно так используется SECRET_KEY.
Django является внутренним, используя его, например, для {% csrf_token%} и еще нескольких вещей. Это действительно не должно влиять на ваше приложение, если вы измените его на основе вашего вопроса и что вы его не используете.
Единственное, что может быть, будет отключено. Так, например, пользователям придется снова войти в админ, поскольку django не сможет декодировать сеанс с помощью другого ключа.
data decode will break
и, возможно, указать какой-то код (в django или в примере проекта), который сломается? РЕДАКТИРОВАТЬ: по-прежнему использовать Django 1.4 - это так?SECRET_KEY
используется вsalted_hmac
используемом для хеширования данных сеанса.