改变Django的SECRET_KEY的效果 [英] Effects of changing Django's SECRET_KEY

问题描述

我犯了一个错误，并将我的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 的价值变化的影响。

直接受到更改影响的用户体验值为：

• 会话，数据解码将中断，对任何会话后端（Cookie，数据库，基于文件或缓存）


• 已经发送的密码重置令牌将不起作用，用户将不得不要求一个新的。


• 注释表单（如果使用 django.contrib.comments ）将不会验证是否在值更改之前被请求，并在值更改后提交。我认为这是非常小的，但可能会让用户感到困惑。


• 消息（来自 django.contrib.messages ）不会验证服务器端在与注释表单相同的时间条件下。

更新：现在在django上工作1.9.5，快速浏览来源给我几乎相同的答案。稍后可以彻底检查。

I made a mistake and committed my Django project's SECRET_KEY into a public repository.

This key should have been kept secret according to the docs https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SECRET_KEY

The Django project is live and has been running for a while with some active users. What are the effects if I change the SECRET_KEY? Will any existing users, cookies, sessions, etc.. be affected? Obviously, the new SECRET_KEY will no longer be stored in a public location.

解决方案

Edit: This answer is based on django 1.5

SECRET_KEY is used in a lot of various places, I'll point out what is impacted by it first and then try to go over that list and give precise explanation of the impact.

The list of things using SECRET_KEY directly or indirectly:

• JSON object signing
• crypto functions for salted hmacs or seeding the random engine which impacts:
  • password reset token
  • comment form security to protect against forged POST requests
  • form security
  • protect against message tampering as the message framework may use cookies to pass messages between views.
  • protect session data and create random session keys to avoid tampering as well.
  • create random salt for most password hashers
  • create random passwords if necessary
  • create itself when using startproject
  • create CSRF key

In reality a lot of the items listed here use SECRET_KEY through django.utils.crypt.get_random_string() which uses it to seed the random engine. This won't be impacted by a change in value of SECRET_KEY.

User experience directly impacted by a change of value are:

• sessions, the data decode will break, that is valid for any session backend (cookies, database, file based or cache).
• password reset token already sent won't work, users will have to ask a new one.
• comments form (if using django.contrib.comments) will not validate if it was requested before the value change and submitted after the value change. I think this is very minor but might be confusing for the user.
• messages (from django.contrib.messages) won't validate server-side in the same timing conditions as for comments form.

UPDATE: now working on django 1.9.5, a quick look at the source gives me pretty much the same answers. Might do a thorough inspection later.

这篇关于改变Django的SECRET_KEY的效果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！