Эффекты изменения секретного ключа Django

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

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

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

4 ответов


Edit: этот ответ основан на django 1.5

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

список вещей через SECRET_KEY прямо или косвенно:

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

опыт непосредственно влияет на изменение стоимости:

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

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


поскольку этот вопрос был задан, то документация Django изменилось, чтобы включить ответ.

секретный ключ используется для:

  • все сеансы, если вы используете любой другой бэкэнд сеанса, чем django.contrib.sessions.backends.cache, или если вы используете SessionAuthenticationMiddleware и используют значение по умолчанию get_session_auth_hash().
  • все сообщения, если вы используете CookieStorage или FallbackStorage.
  • прогресс мастера форм при использовании хранилища cookie с formtools.wizard.views.CookieWizardView.
  • все password_reset() жетоны.
  • все в процессе предварительного просмотра формы.
  • любое использование криптографической подписи, если иной ключ.

если вы повернете свой секретный ключ, все вышеперечисленное будет признано недействительным. Секретные ключи не используются для паролей пользователей и ротация ключей на них не повлияет.

мне не было ясно, как именно я должен повернуть секретный ключ. Я нашел обсуждение как!--33-->Django генерирует ключ для нового проекта, а также суть, которая обсуждает другие функции. Я, наконец, решил просто заставить 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

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

  • подписанные cookies, например, значения типа "remember my auth on this computer". В этом случае файл cookie будет признан недействительным, подпись не будет проверена, и пользователю придется повторная аутентификация.
  • для всех пользователей, которые запросили ссылки для сброса пароля или загрузки пользовательского файла, эти ссылки больше не будут действительны. Пользователям просто придется повторно запросить эти ссылки.

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


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

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

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

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

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