Эффекты изменения Django SECRET_KEY

Я допустил ошибку и передал проект Django SECRET_KEY в публичный репозиторий.

Этот ключ должен храниться в секрете в соответствии с документами https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SECRET_KEY

Проект Django работает вживую и некоторое время работает с некоторыми активными пользователями. Каковы эффекты, если я изменю SECRET_KEY? Будут затронуты любые существующие пользователи, файлы cookie, сеансы и т.д.? Очевидно, что новый SECRET_KEY больше не будет храниться в общедоступном месте.

ОТВЕТЫ

Ответ 1

Изменить: этот ответ основан на django 1.5

SECRET_KEY используется во многих местах, я укажу, на что он воздействует первым, а затем попытайтесь перебрать этот список и дать точное объяснение воздействия.

Список вещей, использующих SECRET_KEY прямо или косвенно:

В действительности многие элементы, перечисленные здесь, используют SECRET_KEY через django.utils.crypt.get_random_string(), который использует его для засеивания случайного движка. На это не повлияет изменение значения SECRET_KEY.

Пользовательский интерфейс, непосредственно влияющий на изменение значения, это:

  • декодирование данных прерывается, что действительно для любого сеанса (файлы cookie, базы данных, файла или кеша).
  • пароль reset уже отправлен не будет работать, пользователи должны будут попросить новый. Форма комментариев
  • (если используется django.contrib.comments) не будет проверяться, если она была запрошена до изменения значения и отправлена ​​после изменения значения. Я думаю, что это очень незначительно, но может быть запутанным для пользователя.
  • сообщения (от django.contrib.messages) не будут проверять серверную сторону в тех же условиях синхронизации, что и для формы комментариев.

UPDATE: теперь, работая над django 1.9.5, быстрый взгляд на источник дает мне почти одинаковые ответы. Можете провести тщательную проверку позже.

Ответ 2

Поскольку этот вопрос был задан, документация по 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!)[email protected]=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
$

Ответ 3

В соответствии с этой страницей https://docs.djangoproject.com/en/dev/topics/signing/, SECRET_KEY в основном используется для переходного материала - подписание данных, отправленных по проводу, чтобы вы могли обнаружить например, фальсификация. Похоже, что вещи, которые МОГУТ разорваться, следующие:

  • Подписанные файлы cookie, например. Значения типа "запомнить мой идентификатор на этом компьютере". В этом случае cookie будет признан недействительным, подпись не сможет проверить и пользователь должен будет повторно аутентифицироваться.
  • Для всех пользователей, которые запросили ссылки для пароля reset или загрузки пользовательского файла, эти ссылки больше не будут действительны. Пользователям просто нужно будет повторно запросить эти ссылки.

Кто-то с более недавним и/или значительным опытом Django, чем я, мог бы перезвонить в противном случае, но я подозреваю, что, если вы явно не делаете что-то с подписывающим API, это должно только создать неудобство для ваших пользователей.

Ответ 4

Строка SECRET_KEY в основном используется для шифрования и/или хэширования данных cookie. Множество фреймворков (в том числе Django) приходит к этому, поскольку файлы cookie по умолчанию имеют свои собственные недостатки.

Представьте, что у вас есть форма в django для редактирования статей со скрытым полем. В этом скрытом поле хранится идентификатор статьи, которую вы редактируете. И если вы хотите быть уверены, что никто не может отправить вам какой-либо другой идентификатор статьи, вы добавите лишнее скрытое поле с хэшированным идентификатором. Поэтому, если кто-то изменит идентификатор, вы это узнаете, потому что хэш не будет таким же.

Конечно, это тривиальный пример, но именно так используется SECRET_KEY.

Django является внутренним, используя его, например, для {% csrf_token%} и еще нескольких вещей. Это действительно не должно влиять на ваше приложение, если вы измените его на основе вашего вопроса и что вы его не используете.

Единственное, что может быть, будет отключено. Так, например, пользователям придется снова войти в админ, поскольку django не сможет декодировать сеанс с помощью другого ключа.