Seguridad Django SECRET_KEY, ¿cómo son los métodos más seguros

Navega tus respuestas
21

Estoy llegando a un punto en el que implementaré mi aplicación Django en el entorno hostil conocido como "internet" y estoy tratando de entender mejor las ramificaciones de Django SECRET_KEY . Uno de los procedimientos estándar que parece es asegurar la clave secreta en el settings.py . Lo suficientemente justo. Hasta ahora, los documentos dicen que no debe cometer su clave secreta a SVN, CVS, etc. Para esto, proporciona un acceso fácil a su clave. Sin embargo, si alguien estuviera tentado a enviar la clave secreta a su repositorio, esto indicaría que la clave secreta es estática (consulte la pregunta 4).

De todos modos, aquí están mis preguntas:

  1. ¿Por qué es más seguro almacenar la clave secreta como una variable de entorno que almacenarla directamente en settings.py ? Por ejemplo, si un atacante puede leer settings.py , lo más probable es que solo pueda escribir $ echo $DJANGO_SECRET_KEY !
  2. ¿Por qué es más seguro almacenar la clave secreta en un archivo que almacenarla directamente en settings.py ? Si puede leer settings.py , probablemente puede leer django_secret_key.txt .
  3. Si el atacante ha comprometido su máquina, ¿no pueden simplemente cargar el intérprete de python con settings.py a > print settings.SECRET_KEY ?
  4. Finalmente, ¿sería una mala práctica generar aleatoriamente la clave secreta cada vez que se reinicia el proceso del servidor web? Esto podría ser completamente aleatorio, o podría solicitar la entrada del usuario para la clave. Obviamente, este último presenta una seria debilidad si el propio atacante puede reiniciar el servicio web e ingresar la clave de su elección.
pregunta James 26.06.2014 - 06:42
fuente

1 respuesta

18

Una vez que un atacante ya tiene acceso al sistema, ya es demasiado tarde. La principal preocupación de no filtrar la clave es que a menudo se usa como semilla para las sesiones de hash y firma. La idea es que su producción SECRET_KEY necesita ser completamente diferente a su desarrollo o puesta en escena SECRET_KEY . En realidad, puede generarlo aleatoriamente cada reinicio, aunque esto podría afectar la experiencia del usuario (consulte los detalles a continuación).

Mientras cumpla con el principio de cambiar la clave, no hay mucho peligro si se compromete o no (siempre y cuando se asegure de que se cambie una vez que vaya de dev a prod). Si no lo hace, entonces alguien que tenga la clave puede predecir el resultado de los algoritmos de hash (utilizados para las sesiones) o incluso firmar sesiones.

Si un atacante ha obtenido acceso a su sistema, ya está demasiado lejos porque ya no es su sistema. Una cosa que debe asegurarse es que los permisos de archivo en su archivo de configuración solo pueden ser leídos por el usuario que ejecuta el servidor web y por nadie más. Esto evita que alguien que obtuvo acceso ilegítimamente a una cuenta limitada, que no es la misma que la cuenta del servidor web, ponga en peligro su clave.

Hay una buena respuesta aquí en Stack Overflow: Django SECRET_KEY escrito por sberder que detalla para qué se utiliza:

  

En realidad, muchos de los elementos enumerados aquí utilizan SECRET_KEY hasta django.utils.crypt.get_random_string() , que lo utiliza para generar 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 interrumpirá, que es válida para cualquier backend de sesión (cookies, base de datos, basado en archivos o caché).
    •   
  • el token de restablecimiento de contraseña ya enviado no funcionará, los usuarios tendrán que pedir uno nuevo.
    •   
  • el formulario de comentarios (si se usa django.contrib.comments ) no se validará si se solicitó antes del cambio de valor y se envió después del cambio de valor. Creo que esto es muy pequeño pero puede ser confuso para el usuario.
    •   
  • los mensajes (de django.contrib.messages ) no validarán el lado del servidor en las mismas condiciones de tiempo que en el formulario de comentarios.
    •   
    
respondido por el Lucas Kauffman 26.06.2014 - 09:13
fuente

Lea otras preguntas en las etiquetas

¿La eliminación de espacios en una cadena protegería contra la inyección de SQL? ¿Cuáles son los aspectos negativos de la creación de huellas de seguridad falsas?