peliculas - Efectos de cambiar SECRET_KEY de Django

django wikipedia

Question

SECRET_KEY un error y SECRET_KEY mi SECRET_KEY mi proyecto Django en un repositorio público.

Esta clave debería haberse mantenido en secreto según los documentos https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SECRET_KEY

El proyecto Django es en vivo y ha estado funcionando por un tiempo con algunos usuarios activos. ¿Cuáles son los efectos si cambio el SECRET_KEY ? ¿Se verán afectados los usuarios, las cookies, las sesiones, etc. existentes? Obviamente, la nueva SECRET_KEY ya no se almacenará en una ubicación pública.

Answer 1

De acuerdo con esta página https://docs.djangoproject.com/en/dev/topics/signing/ , SECRET_KEY se usa principalmente para cosas transitorias: la firma de datos enviados a través del cable para que pueda detectar la manipulación, por ejemplo. Parece que las cosas que PODRÍAN romperse son:

• Cookies firmadas, por ejemplo, valores de tipo "recordar mi autenticación en esta computadora". En este caso, la cookie se invalidará, la firma no podrá verificarse y el usuario tendrá que volver a autenticarse.
• Para cualquier usuario que haya solicitado enlaces para restablecer la contraseña o descargar un archivo personalizado, esos enlaces ya no serán válidos. Los usuarios simplemente tendrían que volver a solicitar esos enlaces.

Alguien con experiencia en Django más reciente y / o sobresaliente que yo puede sonar de otra manera, pero sospecho que a menos que esté haciendo algo explícitamente con la API de firma, esto solo creará un inconveniente leve para sus usuarios.

Answer 2

Desde que se hizo esta pregunta, la documentación de Django ha cambiado para incluir una respuesta.

La clave secreta se usa para:

• Todas las sesiones si está utilizando cualquier otra sesión de backend que django.contrib.sessions.backends.cache , o si usa SessionAuthenticationMiddleware y está utilizando el valor predeterminado get_session_auth_hash() .
• Todos los mensajes si está utilizando CookieStorage o FallbackStorage .
• El progreso del asistente de formularios al usar el almacenamiento de cookies con formtools.wizard.views.CookieWizardView .
• Todos los tokens password_reset() .
• Todo en progreso desde vistas previas.
• Cualquier uso de firma criptográfica, a menos que se proporcione una clave diferente.

Si gira su clave secreta, se invalidará todo lo anterior. Las claves secretas no se usan para las contraseñas de los usuarios y la rotación de claves no las afectará.

No estaba claro para mí exactamente cómo debería rotar la clave secreta. Encontré una discusión sobre cómo Django genera una clave para un nuevo proyecto , así como una Gist que analiza otras opciones . Finalmente decidí hacer que Django creara un nuevo proyecto, copiara la nueva clave secreta en mi viejo proyecto y luego borrara el nuevo proyecto .

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

Answer 3

Editar: Esta respuesta se basa en django 1.5

SECRET_KEY se usa en muchos lugares, primero señalaré qué es lo que se ve afectado y luego trataré de repasar esa lista y dar una explicación precisa del impacto.

La lista de cosas que usan SECRET_KEY directa o indirectamente:

• Firma de objetos JSON
• funciones criptográficas para hmacs salados o siembra del motor aleatorio que impacta:
  • token para cambiar la contraseña
  • Comentar seguridad de formulario para proteger contra solicitudes POST falsificadas
  • forma de seguridad
  • proteger contra la alteración de mensajes ya que el marco de mensajes puede usar cookies para pasar mensajes entre vistas.
  • proteger datos de sesión y crear claves de sesión aleatorias para evitar manipulaciones también.
  • crear sal aleatoria para la mayoría de las contraseñas de contraseña
  • crear contraseñas aleatorias si es necesario
  • crearse a sí mismo cuando se usa startproject
  • crear la clave CSRF

En realidad, muchos de los elementos enumerados aquí usan SECRET_KEY través de django.utils.crypt.get_random_string() que lo usa para django.utils.crypt.get_random_string() el motor aleatorio. Esto no se verá afectado por un cambio en el valor de SECRET_KEY .

La experiencia del usuario directamente afectada por un cambio de valor es:

• sesiones, la decodificación de datos se romperá, que es válida para cualquier back-end de sesión (cookies, base de datos, archivo basado o caché).
• El token de restablecimiento de contraseña ya enviado no funcionará, los usuarios tendrán que solicitar uno nuevo.
• el formulario de comentarios (si se utiliza django.contrib.comments ) no validará si se solicitó antes de que se modifique el valor y se envíe después del cambio de valor. Creo que esto es muy poco importante, pero puede ser confuso para el usuario.
• los mensajes (de django.contrib.messages ) no validarán el servidor en las mismas condiciones de tiempo que para el formulario de comentarios.

ACTUALIZACIÓN : ahora trabajando en django 1.9.5, un vistazo rápido a la fuente me da casi las mismas respuestas. Podría hacer una inspección minuciosa más tarde.

Answer 4

La cadena SECRET_KEY se usa principalmente para encriptar y / o almacenar datos de cookies. Muchos frameworks (incluido Django) vienen a esto porque las cookies de sesión predeterminadas tienen sus propios inconvenientes.

Imagine que tiene formulario en django para editar artículos con un campo oculto. En este campo oculto se almacena el ID del artículo que tiene edición. Y si quiere estar seguro de que nadie le puede enviar ninguna otra identificación de artículo, agregará un campo oculto adicional con una identificación hash. Entonces, si alguien cambiará la identificación, la sabrá porque el hash no será el mismo.

Por supuesto, este es un ejemplo trivial, pero así es como se usa SECRET_KEY.

Django está internamente usándolo, por ejemplo, para {% csrf_token%} y algunas cosas más. Realmente no debería tener ningún impacto en su aplicación si la cambia, en función de su pregunta y de que no la está utilizando.

Lo único es que tal vez los valores de la sesión se descartarán. Entonces, por ejemplo, los usuarios tendrán que volver a iniciar sesión en admin, porque django no podrá decodificar la sesión con otra clave.