Propósito de la configuración de Django 'SECRET_KEY'

157

¿Cuál es exactamente el punto de SECRET_KEYin django? Hice algunas búsquedas en Google y revisé los documentos ( https://docs.djangoproject.com/en/dev/ref/settings/#secret-key ), pero estaba buscando una explicación más detallada de esto, y por qué se requiere

Por ejemplo, ¿qué podría pasar si la clave estuviera comprometida / otros supieran lo que era? Gracias.

— David542
fuente

Si tiene una clave secreta, y está comprometida y liberada a otros, tiene un problema. No importa si estás usando Django o no.

— Jared Farrish

Pero, ¿qué problema exactamente?

— tobych

Hice una respuesta completa aquí (enchufe descarado)

— sberder

@sberder Quizás también deberías escribir una respuesta a esta pregunta. Me imagino que podrías hacerlo mucho mejor que la no respuesta aceptada.

— kasperd

Respuestas:

Se usa para hacer hashes. Mira:

>grep -Inr SECRET_KEY *
conf/global_settings.py:255:SECRET_KEY = ''
conf/project_template/settings.py:61:SECRET_KEY = ''
contrib/auth/tokens.py:54:        hash = sha_constructor(settings.SECRET_KEY + unicode(user.id) +
contrib/comments/forms.py:86:        info = (content_type, object_pk, timestamp, settings.SECRET_KEY)
contrib/formtools/utils.py:15:    order, pickles the result with the SECRET_KEY setting, then takes an md5
contrib/formtools/utils.py:32:    data.append(settings.SECRET_KEY)
contrib/messages/storage/cookie.py:112:        SECRET_KEY, modified to make it unique for the present purpose.
contrib/messages/storage/cookie.py:114:        key = 'django.contrib.messages' + settings.SECRET_KEY
contrib/sessions/backends/base.py:89:        pickled_md5 = md5_constructor(pickled + settings.SECRET_KEY).hexdigest()
contrib/sessions/backends/base.py:95:        if md5_constructor(pickled + settings.SECRET_KEY).hexdigest() != tamper_check:
contrib/sessions/backends/base.py:134:        # Use settings.SECRET_KEY as added salt.
contrib/sessions/backends/base.py:143:                       settings.SECRET_KEY)).hexdigest()
contrib/sessions/models.py:16:        pickled_md5 = md5_constructor(pickled + settings.SECRET_KEY).hexdigest()
contrib/sessions/models.py:59:        if md5_constructor(pickled + settings.SECRET_KEY).hexdigest() != tamper_check:
core/management/commands/startproject.py:32:        # Create a random SECRET_KEY hash, and put it in the main settings.
core/management/commands/startproject.py:37:        settings_contents = re.sub(r"(?<=SECRET_KEY = ')'", secret_key + "'", settings_contents)
middleware/csrf.py:38:                % (randrange(0, _MAX_CSRF_KEY), settings.SECRET_KEY)).hexdigest()
middleware/csrf.py:41:    return md5_constructor(settings.SECRET_KEY + session_id).hexdigest()

— Roshan Mathews
fuente

¿Por qué no lo llamaron sal entonces? ;)

— datenwolf

Esto es una suposición, pero supongo que es más fácil decirle a la gente "no comparta su SECRET_KEY", en lugar de "su SALTes una clave secreta que debe guardar para usted".

— Roshan Mathews

Esa distinción es muy importante. En criptografía, las sales no son secretas, pero SECRET_KEYdeben mantenerse seguras. El uso de SECRET_KEYes mucho más parecido al uso de una clave en un hash firmado como HMAC (que, si el rendimiento no fuera una consideración, probablemente se usaría en su lugar).

— Travis Jensen

Esto no me parece una respuesta. Todo lo que hizo fue un solo comando grep sin explicar qué hace. ¿Dónde está la respuesta a "qué podría pasar si la clave estuviera comprometida?"

— kasperd

Además, dado que SECRET_KEY es confidencial, el prefijo SECRET a la clave garantiza que Django cifrará / enmascarará los valores donde sea necesario.

— Linus_30

La documentación de Django para la firma criptográfica cubre los usos de la configuración 'SECRET_KEY':

Este valor [la SECRET_KEYconfiguración] es la clave para asegurar los datos firmados: es vital que mantenga esto seguro, o los atacantes podrían usarlo para generar sus propios valores firmados.

(También se hace referencia a esta sección de la documentación de Django para la configuración 'SECRET_KEY' ).

La API de firma criptográfica en Django está disponible para cualquier aplicación para firmas de valores criptográficamente seguras. Django hace uso de esto en varias características de nivel superior:

Firma de datos serializados (por ejemplo, documentos JSON).
Tokens únicos para una sesión de usuario, solicitud de restablecimiento de contraseña, mensajes, etc.
Prevención de ataques entre sitios o de repetición agregando (y luego esperando) valores únicos para la solicitud.
Generando una sal única para funciones hash.

Entonces, la respuesta general es: hay muchas cosas en una aplicación de Django que requieren una firma criptográfica, y la configuración 'SECRET_KEY' es la clave utilizada para esas. Debe tener una cantidad de entropía criptográficamente fuerte (difícil de adivinar para las computadoras) y única entre todas las instancias de Django.

— nariz grande
fuente

"y único entre todas las instancias de Django". ¿Esto implica que si tengo 3 servidores web que ejecutan la misma aplicación Django detrás de un equilibrador de carga, debería tener 3 SECRET_KEYconfiguraciones distintas ?

— Adam Parkin

@ AdamParkin, eso suena como un buen comienzo para una nueva pregunta , para obtener su propia respuesta.

— bignose

Gran sugerencia, realizada: stackoverflow.com/questions/51657422/…

— Adam Parkin

De acuerdo con la documentación de Django sobreSECRET_KEY :

La clave secreta se usa para:

Todas las sesiones si está utilizando cualquier otro back-end de sesión que no sea django.contrib.sessions.backends.cache, o está utilizando el predeterminado get_session_auth_hash().

Todos los mensajes si está utilizando CookieStorageo FallbackStorage.

Todos los tokens PasswordResetView.

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 utilizan para contraseñas de usuarios y la rotación de claves no las afectará.

— Michael B
fuente

Información útil sobre lo que sucede si SECRET_KEYse gira. +1

— Hassan Baig