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

Я сделал ошибку и поместил свой проект 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прямо или косвенно:

• Подписание объекта JSON
• криптографические функции для соленых hmacs или заполнения случайного механизма, который влияет на:
  • токен сброса пароля
  • безопасность формы комментария для защиты от поддельных запросов POST
  • форма безопасности
  • Защита от подделки сообщений, так как структура сообщений может использовать файлы cookie для передачи сообщений между представлениями.
  • защитить данные сеанса и создать случайные ключи сеанса, чтобы избежать вмешательства также.
  • создать случайную соль для большинства хэшей паролей
  • создать случайные пароли при необходимости
  • создать себя при использовании startproject
  • создать ключ CSRF

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

Пользовательский опыт, непосредственно затронутый изменением значения:

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

ОБНОВЛЕНИЕ : теперь работает над 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
$

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

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

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

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

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

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

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

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

Я сделал эту же ошибку. Пароль по умолчанию был длиной 50, поэтому я использовал powershell для генерации случайной строки длиной 50 и заменил на нее старый SECRET_KEY. Я вошел в систему и после замены SECRET_KEY мой предыдущий сеанс был признан недействительным.

С Powershell ( источник ):

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

С Bash ( источник ):

# 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

В этот момент я подумал, почему бы не попробовать больший ключ, поэтому я попробовал его с ключом длиной 100 и 1000. Оба работали. Если я понимаю исходный код , объект, возвращаемый функцией подписи, является хэшем hmac в base64. RFC 2104 имеет это сказать для требуемой длины секретного ключа HMAC.

Приложения, использующие ключи длиной более B байтов, сначала хешируют ключ с использованием H, а затем используют результирующую L-байтовую строку в качестве фактического ключа для HMAC.

Ключ для HMAC может иметь любую длину (ключи, длина которых превышает B байтов, сначала хэшируются с использованием H). Тем не менее, настоятельно рекомендуется использовать менее L байтов, поскольку это приведет к снижению уровня безопасности функции. Ключи длиннее L байтов являются приемлемыми, но дополнительная длина не будет значительно увеличивать силу функции. (Более длинный ключ может быть полезен, если случайность ключа считается слабой.)

Чтобы перевести на обычную речь, размер секретного ключа должен совпадать с размером вывода. Ключ также должен быть в битах. Каждая цифра в base64 представляет 6 бит. Таким образом, если бы у вас был пароль из 50 символов, у вас был бы секретный ключ 50 x 6 = 300 бит. Если вы используете SHA256, то вам потребуется ключ 256 бит ( sha256 использует 256 бит по определению ). Таким образом, пароль длиной 50 должен работать, если вы не планируете использовать алгоритм хеширования больше, чем SHA256.

Но так как все дополнительные биты в ключе хэшируются, его размер не сильно снижает производительность. Но это гарантирует, что у вас достаточно битов для больших хеш-функций. SHA-512 будет охвачен длиной SECRET_KEY длиной 100 ( 50 x 6 = 600 бит> 512 бит ).