¿Qué hay de prevenir CSRF de esta manera?

Este es probablemente un mal mecanismo, ya que viola el principio de Kerckhoff . Si un atacante sabe cómo funciona su "encriptación", puede simplemente cifrar su propio blob CSRF para un usuario específico y usarlo en ataques dirigidos.

CSRF aprovecha el hecho de que su navegador enviará una cookie que contiene un ID de sesión que lo autentica en el servidor, incluso si la solicitud es generada por un script automatizado. Para protegerse contra esto, solo necesita un token desconocido para un atacante, y el navegador no lo envía automáticamente sin instrucciones directas. La forma estándar de hacer esto es generar un valor aleatorio, conocido como token CSRF, y agregarlo a los parámetros de una solicitud POST. Mientras el script de destino verifique el token CSRF de alguna manera, estará protegido.

La forma más sencilla de hacerlo es generar un token CSRF aleatorio cuando se inicia la sesión y almacenarla como una variable de sesión. A continuación, se puede inyectar en formularios que requieren protección CSRF y se puede verificar mediante el script de destino.

Agregar cualquier "extra" a este esquema, como el cifrado / las marcas de tiempo es snakeoil, es decir, no proporciona seguridad real y complica el esquema, lo que resulta en una superficie de ataque potencialmente mayor. Recuerde: no esté un Dave!

  

una de mis universidades quiere generar el token cifrando la identificación del usuario de inicio de sesión actual concatenando marcas de tiempo con una contraseña guardada de forma segura. Y luego agregue el token en el formulario.

Está bien y es un enfoque de uso común donde las sesiones no están disponibles. Pero use un MAC estándar para esto (por ejemplo, HMAC-SHA256) en lugar de su propio hash concatenado de una sola capa.

Otra consideración es la administración clave del ciclo de vida: ¿planea cambiar el secreto del servidor de vez en cuando? ¿Tiene un mecanismo para proporcionar un cambio suave cuando lo hace (o cuando retira el secreto después de un compromiso)? ¿O está bien romper los tokens antiguos de todos en ese escenario?

Parece que está utilizando un esquema de valor firmado similar para la cookie de autenticación. En ese caso, debe considerar (si aún no lo ha hecho) incluir un identificador de contraseña de usuario como parte del texto claro / firmado, de modo que cuando el usuario cambie su contraseña, se invaliden todos los tokens emitidos anteriormente. Esto podría ser un número de generación, marca de tiempo de cambio o sal de almacenamiento.

También existe la implicación de que, dado que el dato con el que se está asociando para la protección XSRF es el ID de usuario, no puede proteger el formulario de inicio de sesión. Considere qué pasaría si un atacante utilizara XSRF para hacer que un usuario inicie sesión automáticamente en una cuenta de la elección del atacante, tal vez sin que el usuario se dé cuenta de qué cuenta inició sesión; ¿Eso constituye potencialmente una amenaza?

Un enfoque que resuelve esto si lo necesita es agregar cookies de autenticación para usuarios no autenticados e incluir un secreto en la cookie de autenticación. Luego incluya / firme ese secreto en el token XSRF: efectivamente, el token XSRF está firmando la cookie de autenticación.

Este es un enfoque válido para protegerse contra ataques CSRF. Algunas ventajas sobre los métodos tradicionales incluyen:

• No depende de la sesión
• No expone las vulnerabilidades del subdominio según Double Submit

Se llama el patrón de token cifrado. Consulte este enlace para obtener una explicación completa y una descripción general de la arquitectura. También vea la OWASP descripción oficial.