Claves de firma y de sesión del framework

En Django, SECRET_KEY firma las sesiones (salvo con el motor de sesiones que solo usa caché), los mensajes guardados en cookies, los enlaces de restablecimiento de contraseña y cualquier firma que no traiga su propia clave. Su documentación advierte que una clave conocida puede llevar a escalar privilegios e incluso a ejecutar código. En Laravel, APP_KEY cifra y firma todas las cookies, la de sesión incluida, y lo que la aplicación cifre con su servicio de cifrado. En Express, el secret del componente de sesiones firma la cookie que lleva el identificador de sesión.

Lo que una clave así no protege también importa, porque decide el alcance de un cambio de clave: al cambiarla, en Django se cierran las sesiones y dejan de valer los enlaces de restablecimiento ya enviados, pero las contraseñas no se tocan, porque su resumen no depende de esa clave.

Django trae una comprobación para producción, manage.py check --deploy, que revisa los ajustes de seguridad del despliegue. Considera débil una clave que tiene menos de 50 caracteres, menos de 5 caracteres distintos o empieza por el prefijo que Django pone a las claves que genera automáticamente al crear un proyecto.

Para rotar sin cerrar todas las sesiones de golpe existe SECRET_KEY_FALLBACKS: la clave nueva va en SECRET_KEY y la vieja en esa lista, que se vacía cuando ya pueden caducar las sesiones y enlaces firmados con ella. Una clave que se queda en la lista no está retirada: sigue validando firmas. Abre tienda-check-deploy.txt y cruza sus avisos con el inventario.

La guía de OWASP para la configuración incorrecta pide entornos endurecidos igual pero con credenciales distintas. Una clave del framework es una credencial: si producción y otro entorno comparten la misma, quien lea el archivo de configuración de ese otro entorno puede fabricar cookies que producción acepta como suyas y, en Laravel, descifrar lo que producción cifró.

El inventario no muestra las claves, solo una huella de cada una: dos huellas iguales significan la misma clave. Compara las huellas del portal de autores y lee después accesos-entornos.txt para saber quién puede leer ese archivo.

Los tres frameworks permiten tener varias claves a la vez para que una rotación planificada no cierre todas las sesiones: Django con SECRET_KEY_FALLBACKS, Laravel con APP_PREVIOUS_KEYS y el componente de sesiones de Express con una lista de secretos en la que el primero firma y todos se aceptan al comprobar. Las tres listas se pensaron para lo mismo: retirar con calma una clave que nadie más conoce.

Con una clave filtrada la lógica se invierte. Mientras siga en la lista, quien la tenga puede producir cookies que el servidor da por firmadas por él, por mucho que haya una clave nueva delante. Lee registro-incidentes.txt y después la lista de secretos de boletin-servidor.js.

La clave de producción del portal de autores la puede leer un proveedor externo desde preproducción. No hay indicio de abuso, pero ya no se puede tratar como secreta. La lista de claves anteriores es la herramienta de la rotación tranquila y aquí juega en contra, porque mantendría válida justo la clave que hay que dejar de aceptar. El costo de cerrar sesiones se asume. Si hay datos cifrados con la clave vieja, se descifran y se vuelven a cifrar en una tarea controlada antes de destruirla, sin dejarla puesta en la aplicación.