更改 Django 的 SECRET_KEY 的效果

Question

我犯了一个错误，将我的 Django 项目的 SECRET_KEY 提交到公共存储库中。

这个密钥应该保密according to the docs。

Django 项目已经上线，并且已经有一些活跃用户运行了一段时间。如果我更改SECRET_KEY 会有什么影响？任何现有的用户、cookie、会话等会受到影响吗？显然，新的SECRET_KEY 将不再存储在公共位置。

Answer 1

根据这个页面https://docs.djangoproject.com/en/dev/topics/signing/，SECRET_KEY 主要用于临时性的东西——例如对通过网络发送的数据进行签名，以便您可以检测到篡改。看起来可能会破坏的东西是：

• 签名的 cookie，例如“记住我在这台计算机上的身份验证”类型值。在这种情况下，cookie 将失效，签名将无法验证，用户将不得不重新验证。
• 对于请求密码重置或自定义文件下载链接的任何用户，这些链接将不再有效。用户只需重新请求这些链接。

比我有更新和/或突出 Django 经验的人可能会提出其他意见，但我怀疑除非您明确使用签名 API 做某事，否则这只会给您的用户带来轻微的不便。

Answer 2

SECRET_KEY 字符串主要用于加密和/或散列 cookie 数据。由于默认会话 cookie 有其自身的缺点，因此很多框架（包括 Django）都会这样做。

想象一下，您在 django 中有一个表单，用于编辑带有隐藏字段的文章。在此隐藏字段中存储您正在编辑的文章的 ID。如果您想确保没有人可以向您发送任何其他文章 ID，您将添加一个带有散列 ID 的额外隐藏字段。因此，如果有人更改 ID，您会知道，因为哈希值不会相同。

当然这是一个简单的例子，但这就是 SECRET_KEY 的使用方式。

Django 在内部使用它，例如 {% csrf_token %} 和其他一些东西。如果您根据您的问题和您没有使用它来更改它，那么它确实不会对您的应用程序产生任何影响。

唯一的问题是可能会话值将被丢弃。因此，例如用户将不得不再次登录管理员，因为 django 将无法使用不同的密钥解码会话。

Answer 3

编辑：此答案基于 django 1.5

SECRET_KEY 用在很多不同的地方，我会先指出受它影响的内容，然后尝试查看该列表并给出影响的准确解释。

直接或间接使用SECRET_KEY的事物列表：

• JSON object signing
• crypto functions 用于盐渍 hmacs 或播种影响的随机引擎：
  • password reset token
  • comment form security 防止伪造的 POST 请求
  • form security
  • protect against message tampering 作为消息框架可能会使用 cookie 在视图之间传递消息。
  • protect session data and create random session keys 以避免篡改。
  • create random salt for most password hashers
  • create random passwords 如有需要
  • create itself when using startproject
  • create CSRF key

实际上，这里列出的许多项目都使用SECRET_KEY 到django.utils.crypt.get_random_string()，它们使用它来播种随机引擎。这不会受到 SECRET_KEY 值更改的影响。

价值变化直接影响的用户体验有：

• 会话，数据解码将中断，这对任何会话后端（cookie、数据库、基于文件或缓存）都有效。
• 已发送的密码重置令牌将不起作用，用户必须要求一个新令牌。
• cmets 表单（如果使用django.contrib.comments）将不会验证是否在值更改之前请求并在值更改之后提交。我认为这非常轻微，但可能会让用户感到困惑。
• 消息（来自django.contrib.messages）不会在与 cmets 表单相同的时间条件下验证服务器端。

更新：现在正在使用 django 1.9.5，快速查看源代码给了我几乎相同的答案。以后可能会进行彻底的检查。

Answer 4

自从提出这个问题后，Django documentation 已更改为包含答案。

密钥用于：

• 如果您使用除django.contrib.sessions.backends.cache 之外的任何其他会话后端，或者使用默认的get_session_auth_hash()，则为所有会话。
• 如果您使用的是CookieStorage 或FallbackStorage，则为所有消息。
• 所有PasswordResetView 令牌。
• 加密签名的任何使用，除非提供不同的密钥。

如果您轮换您的密钥，上述所有内容都将失效。密钥不用于用户的密码，密钥轮换不会影响他们。

我不清楚应该如何轮换密钥。我找到了关于 Django generates a key for a new project 的讨论，以及讨论 other options 的 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 在 1.10 版本中添加了get_random_secret_key() function。您可以使用它来生成新的密钥。

$ ./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
$

Answer 5

我犯了同样的错误。默认密码是 50 长，所以我使用 powershell 生成了一个 50 长的随机字符串，并用它替换了旧的 SECRET_KEY。我已登录，更换 SECRET_KEY 后，我之前的会话已失效。

使用 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)

使用 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

此时我想为什么不尝试更大的密钥，所以我尝试了 100 和 1000 长密钥。两者都有效。如果我理解source code，则签名函数返回的对象是base64 中的hmac 哈希。 RFC 2104 对所需的 HMAC 密钥长度有这样的说法。

使用密钥时间更长的应用程序 比 B 字节将首先使用 H 散列密钥，然后使用 生成的 L 字节字符串作为 HMAC 的实际密钥。

HMAC 的密钥可以是任意长度（长度超过 B 字节的密钥是 首先使用 H) 进行哈希处理。然而，小于 L 字节是强 气馁，因为它会降低安全强度 功能。长度超过 L 字节的密钥是可以接受的，但额外的 长度不会显着增加功能强度。 （一种 如果密钥的随机性为 被认为是弱者。）

要翻译成普通话，密钥的大小需要与输出的大小相同。密钥也需要以位为单位。 base64 中的每个数字代表 6 位。因此，如果您有一个 50 个字符的密码，那么您将拥有一个 50 x 6 = 300 位的密钥。如果您使用的是 SHA256，那么您需要一个 256 位密钥（sha256 根据定义使用 256 位）。因此，除非您打算使用大于 SHA256 的散列算法，否则 50 长的密码应该可以工作。

但是由于密钥中的任何额外位都会被散列，因此它的大小不会显着降低性能。但它会保证你有足够的位来处理更大的散列函数。 SHA-512 将被 100 长的 SECRET_KEY 覆盖（50 x 6 = 600 位 > 512 位）。