cookies - desencriptar - descifrar aes online

¿El cifrado RIJNDAEL es seguro de usar con pequeñas cantidades de texto entregado a los usuarios?

Question

Estoy pensando en hacer el cambio para almacenar datos de sesión en cookies cifradas en lugar de hacerlo en algún lugar de mi servidor. Si bien esto dará como resultado un mayor ancho de banda utilizado para cada solicitud, ahorrará espacio adicional de almacenamiento y carga de servidor de la base de datos.

De todos modos, planeo encriptar los contenidos de la cookie usando RIJNDAEL 256.

function encrypt($text, $key)
{
return mcrypt_encrypt(MCRYPT_RIJNDAEL_256,$key,$text,MCRYPT_MODE_ECB,mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256,MCRYPT_MODE_ECB),MCRYPT_RAND));
}

Lo que en uso produciría algo como esto (base64 codificado para mostrar)

print base64_encode(encrypt(''text'', ''key''));
7s6RyMaYd4yAibXZJ3C8EuBtB4F0qfJ31xu1tXm8Xvw=

No me preocupa que una sola cookie de usuario se vea comprometida tanto como me preocupa que un atacante descubra la key y pueda construir cualquier sesión para cualquier usuario, ya que ellos saben lo que uso para firmar los datos.

¿Hay alguna manera de verificar los tiempos de craqueo estimados en relación con los parámetros utilizados? ¿O hay una medida estándar de tiempo en relación con el tamaño del texto o la clave utilizada?

Escuché a alguien decir que las llaves debían exceder las 256bits para ser lo suficientemente seguras como para ser utilizadas con RIJNDAEL. También me pregunto si la longitud del texto cifrado debe ser de cierta duración para no revelar la clave.

Los datos generalmente serán de unos 200 caracteres

a:3{s:7:"user_id";i:345;s:5:"token";s:32:"0c4a14547ad221a5d877c2509b887ee6";s:4:"lang";s:2:"en";}

Entonces, ¿esto es seguro?

Answer 1

AES-128 debería ser más que suficiente, sin necesidad de utilizar teclas más largas, si la clave se elige al azar.

Sin embargo, hay otros problemas. El primero es que no deberías usar ECB. Con BCE, un bloque dado de texto plano de 128 bits siempre se mapea en el mismo texto cifrado de 128 bits si la clave es la misma. Esto significa que los adversarios pueden modificar quirúrgicamente el texto cifrado inyectando diferentes bloques para los cuales conocen el texto cifrado correspondiente. Por ejemplo, podrían mezclar los datos de dos usuarios diferentes. Con otros modos, CBC, por ejemplo, está bien, el texto cifrado también depende del IV (vector de inicialización), que debería ser diferente en cada ejecución del algoritmo. De esta forma, el mismo texto simple se cifra de manera diferente cada vez y el adversario no puede obtener ninguna ventaja. También necesita guardar el IV en alguna parte con el texto cifrado, sin necesidad de protegerlo. Siempre que la posibilidad de reutilizar el mismo IV sea no despreciable, también debe cambiar la clave.

El segundo problema es que también debe agregar un código de autenticación de mensaje. De lo contrario, no sería capaz de distinguir las cookies falsificadas de las buenas.

Answer 2

Evita usar BCE. Puede revelar información sobre lo que está encriptado. Dos bloques con el mismo texto plano tendrán el mismo texto cifrado. CBC evitaría esto, pero requiere que se genere o guarde un IV.

Evite simplemente guardar una clave y IV. Genere una clave maestra de 256 bits utilizando un generador de números aleatorios criptográficamente fuerte y guárdela en su aplicación en un lugar seguro. Úselo para generar claves de sesión para usar en el cifrado. El IV se puede derivar de la clave de sesión. Al generar la clave de sesión, incluya todos los datos disponibles que puedan usarse para restringir el alcance de la clave de sesión. (por ejemplo, incluir el alcance de la cookie, la dirección del host remoto, un aviso aleatorio almacenado con los datos encriptados, y / o un ID de usuario si no está dentro de los datos encriptados)

Dependiendo de cómo se utilizarán los datos, es posible que deba incluir un MAC. ECB y CBC no están diseñados para detectar ningún cambio en el texto cifrado, y dichos cambios darán como resultado la basura en texto sin formato. Es posible que desee incluir un HMAC con los datos cifrados para permitirle autenticarlo antes de tomarlo como un canon. Una clave HMAC de sesión debe derivarse de la clave de cifrado de la sesión. Alternativamente, puede usar el modo PCBC. PCBC fue creado para detectar cambios en el texto cifrado, pero su capacidad para hacerlo está limitada por el tamaño del relleno, que depende de los datos cifrados, y no todas las API criptográficas lo tendrán como opción.

Una vez que haya llegado a incluir un MAC, debería considerar tomar medidas contra los ataques de repetición. Cada vez que alguien puede volver a enviar datos viejos dentro del alcance de una sesión, existe la posibilidad de un ataque de repetición. Hacer que el uso de la clave de sesión sea lo más limitado posible sin causar problemas al usuario es una forma de frustrar los ataques de repetición. Otra cosa que podría hacer es incluir una fecha y hora en los datos cifrados para crear una ventana para que los datos se consideren válidos.

En verano, proteger la llave es solo la punta del iceburg.

Answer 3

Rijndael pasó a llamarse AES. Sí, es seguro de usar.

Dicho esto, debes considerar cuidadosamente lo que colocas en la cookie. Depende de lo que tenga disponible en el modo de almacenamiento en su sistema, pero puede simplemente elegir un número aleatorio (digamos un número de 64 bits) y almacenarlo en la cookie. En su sistema del lado del servidor, mantendría un registro de a quién estaba asociado ese número y los demás detalles. Esto evita el cifrado por completo. Usas los demás detalles para validar (en la medida en que cualquier cosa pueda ser validada) si la cookie fue devuelta desde el navegador al que originalmente la enviaste.

Alternativamente, puede usar una clave de cifrado diferente para cada sesión, manteniendo una pista de qué clave se utilizó con cada sesión.

Incluso si usa el cifrado directo con una clave fija, considere incluir un número aleatorio con los datos que se cifrarán; esto hace que sea más difícil descifrarlo utilizando un ataque de texto claro conocido porque, por definición, no se puede conocer el número aleatorio.

Answer 4

Si usa una clave larga, diría que la clave fue bastante segura. Algunas cosas de las que debes preocuparte:

Está descargando el almacenamiento de datos al cliente. NUNCA CONFÍE EN EL CLIENTE. Esto no significa que no pueda hacer esto, solo que tenga que tratar los datos en la cookie como no confiables (no tome ninguna decisión más seria que qué ''tema'' muestre al usuario basado en ella) o proporcione para una forma de validar los datos.

Algunos ejemplos de cómo validar los datos serían:

• incluir una sal (para que las personas con los mismos datos de sesión no obtengan la misma cookie) y
• una suma de comprobación (para que alguien que cambie incluso un poco de la cookie lo haga inútil).

Answer 5

Sí Rijndael (AES) es seguro, sin embargo su implementación está lejos de ser segura. Hay 2 problemas pendientes con su implementación. El uso del modo ECB y su IV es una variable estática que se utilizará para todos los mensajes. Un IV siempre debe ser un Nonce criptográfico . Su código es una clara violación de CWE-329.

El modo ECB nunca se debe usar, se debe usar el modo CBC y esta es la razón por la cual:

Original:

Encriptado con el modo ECB:

Encriptado usando el modo CBC: