¿Agregar la aleatoriedad a un token antes de cifrarlo lo hace más seguro?

No es necesario agregar ninguna aleatoriedad a un token cifrado. Si está correctamente encriptado, el usuario no tiene forma de inferir nada sobre los datos encriptados.

  

El problema aquí es que, cada vez que un usuario particular vea una página en particular, se generará el mismo token para ellos.

Esto parece extraño. Su cifrado no parece utilizar un estándar seguro. De lo contrario, cada vez que cifrara el mismo token, el cyphertext cambiaría. Debes usar una IV, y nunca pienses en AES-ECB, ese modo no funciona y no debería usarse ni siquiera para enseñar a los niños cómo funciona AES.

Si utiliza estándares de la industria, sabrá acerca del Vector de inicialización (IV). En términos generales, el IV es un valor agregado al proceso que cambia el cyphertext, por lo que incluso si cifra dos plaintexts idénticos con la misma clave, el cyphertext correspondiente cambiará.

La IV es la información aleatoria que estás pensando en agregar. Ya está allí.

Intentemos desglosarlo:

Problema: reproducir un token :

  

Además de permitir que la misma solicitud se reproduzca contra el punto final hasta el infinito

Por lo general, los tokens de autenticación resuelven este problema expirando: los datos cifrados incluyen una marca de datos (que tiene el efecto secundario de hacer que cada token sea único) y el servidor rechazará cualquier token más antiguo que, digamos, 15 minutos.

Problema: rompiendo criptografía :

  

esto hace que sea más probable que alguien pueda romper el cifrado del token

No soy un experto, pero me parece que debería usar un IV aleatorio para cada cifrado e incluir el IV con el texto cifrado como parte del token. Esto solucionaría el problema de criptoanálisis al que se alude y tendría el efecto secundario de hacer que sus tokens sean únicos. (Si no está utilizando IVs aleatorios, entonces probablemente tenga problemas mucho mayores)

¿Por qué no usar una biblioteca estándar para hacer esto en lugar de salir de su profundidad para diseñar su propio esquema de cifrado? Recomendaría JWT .

Finalmente, como servicio público necesito corregir esto: LOS GUID NO SON ALEATORIOS DE ALTA CALIDAD.

Consulte Wikipedia / Universally_unique_identifier .

UUID / GUID están diseñados para ser únicos , no intentan ser impredecibles . Hay 5 formas estándar de derivar un UUID; 4 de ellos son una combinación de dirección MAC + nombre de host + marca de tiempo. Los UUID de la versión 4 son totalmente aleatorios, pero como la generación de UUID / GUID debe ser rápida y sin bloqueo, utilizan generadores de números aleatorios no criptográficos.

POR FAVOR, NO USE UUIDs / GUIDS COMO FUENTE DE ALEATORIA CRIPTOGRAFICA . En su lugar, use /dev/random en unix, SecureRandom en java, o lo que sea el equivalente en su sistema operativo / lenguaje de programación

La solución que se usa en mi plataforma de elección es "cifrar / descifrar con IV administrado (Vector de inicialización)". Lo que esto significa es que, después del cifrado, todo el texto plano se cifra con un IV criptográfico seguro, y luego el IV se coloca en formato base64 antes del comienzo del texto cifrado. Tras el descifrado, la IV se saca del frente y se usa como la IV para el texto cifrado. Todo esto es transparente para el desarrollador. Tenga en cuenta que es perfectamente seguro exponer el IV, ya que el descifrado con la clave correcta pero el IV incorrecto resultará en una condición de falla. Si su lenguaje de programación tiene una característica similar, utilícelo; Al generar un IV aleatorio cada vez que cifres algo, no necesitas poner ningún dato adicional en el texto simple.

Para mí, esto parece un XY Problem .

La mejor manera de proteger un secreto es no contarle a nadie el secreto. El token se genera en el lado del servidor. El servidor ya conoce los datos. Y luego vuelve a reproducir el token en el servidor, que contiene solo los datos que el servidor ya tiene . Eso es completamente innecesario.

Otras respuestas han señalado la solución rápida e inmediata para su problema de cifrado mediante el uso de cifrado con IVs. Pero la mejor solución sería hacer esto superfluo.

  

El servidor crea el token utilizando varios valores , lo cifra (mediante un algoritmo estándar de la industria, nada propio) utilizando una clave que solo el servidor conoce, y lo devuelve como parte de los datos de la página

En lugar de cifrar esos valores, guárdelos en una base de datos. Usted puede potencialmente, si realmente debe, aún cifrar esos valores y luego guardarlos. Pero no hay absolutamente ninguna necesidad de que estos valores salgan del servidor, incluso en forma cifrada. Luego genere un token verdaderamente aleatorio (con un CSPRNG), y úselo como clave de búsqueda. Envía este token al cliente.

  

El token está incrustado en el enlace en la página

Use el token aleatorio que acaba de generar para eso.

  

Cuando el cliente hace clic en ese enlace, el token se envía al servidor, se descifra y se analiza, y los valores se utilizan para determinar qué hacer

En lugar de descifrar y analizar los valores, se usa el token para buscarlos en la base de datos. Hecho. Si solo almacenó los datos encriptados, todavía necesita descifrarlos, por supuesto.

Esto también funciona si tiene varios servidores. Si el token se genera en el servidor A y se envía al servidor B, haga que el servidor B use una conexión segura con el servidor A y solicite los datos a través del token del servidor A. En este escenario, también, los datos nunca se envían al cliente.

  

Esto se hace porque necesitamos que ciertos bits de información se envíen desde el cliente al servidor, pero no queremos filtrar esos bits de información al cliente porque revelarían detalles del funcionamiento interno del servidor

El estado interno nunca debe filtrarse desde una implementación. Esto ya es un olor a código y un buen indicio de que su arquitectura es defectuosa.