Patrón de token cifrado CSRF: ¿necesita 'nonce'?

1

Para el patrón de token cifrado anti-CSRF, la OWASP page describe la página anterior El token cifrado se compone de tres elementos: el ID del usuario, un valor de marca de tiempo y un nonce.

La necesidad programática de los dos primeros es obvia, pero ¿qué pasa con el tercero? ¿Cuál es la necesidad real del componente de datos aleatorios?

Entiendo por qué en el caso del patrón de token de sincronizador ordinario.

Pero, ¿cuál sería el problema para el patrón de token cifrado con la implementación de un token compuesto solo por UserId y timestamp, que luego estará sujeto a encrypt-then-mac.

¿Se considera importante hacer que el token cifrado sea más criptográficamente seguro (al hacer que el texto simple sea más largo y menos predecible)?

    
pregunta Henry 12.11.2015 - 21:38
fuente

1 respuesta

1

En realidad no. El nonce está ahí para propósitos anticolisión, no para la seguridad criptográfica. Incluso podría almacenarlo como un contador en una base de datos si lo desea; es solo que la marca de tiempo no tiene una resolución suficiente para garantizar que no haya colisiones.

También debo señalar que los patrones enumerados en la página OWASP vinculada son sugerencias y no son garantías de seguridad. Por ejemplo, su patrón de token encriptado sugerido no menciona que debes usar AEAD o Encrypt-then-MAC o bien podrías estar perdiendo el tiempo. (Y si va con Encrypt-then-MAC, necesita cifrado y claves MAC por separado).

    
respondido por el Reid Rankin 13.11.2015 - 02:18
fuente

Lea otras preguntas en las etiquetas