Cifrado autenticado frente a cifrado solo

La confidencialidad responde a «¿quién puede leerlo?»; la integridad, a «¿quién puede cambiarlo sin que se note?». Un cifrado solo, como AES en modo CBC o CTR sin nada más, da lo primero y no lo segundo. En CTR, cambiar un bit del texto cifrado cambia exactamente ese bit del texto claro. En CBC, cambiar un byte del bloque anterior (o del vector de inicialización, para el primer bloque) cambia de forma controlada el mismo byte del bloque siguiente. Quien conoce o intuye una parte del texto claro puede alterarla sin conocer la clave.

El cifrado autenticado añade una etiqueta que se calcula con la clave sobre todo el mensaje. Al descifrar, la etiqueta se comprueba primero y, si no coincide, no se devuelve nada. Los modos AES-GCM y ChaCha20-Poly1305 lo hacen en una sola operación; con un cifrado solo, la alternativa es cifrar y después calcular un HMAC con otra clave sobre el texto cifrado, comprobándolo antes de descifrar.

Abre el laboratorio y lee CookiePreferencias.php junto a CuentaBancaria.php. Los dos cifran con AES de 256 bits, los dos usan un vector o nonce nuevo cada vez, y en un vistazo rápido parecen equivalentes. Fíjate en el nombre del cifrado que recibe cada llamada y en qué devuelve cada uno además del texto cifrado.

Cuando el descifrado de un cifrado solo falla, la causa suele ser el relleno del último bloque. Si la aplicación responde distinto según el relleno sea válido o no —un código de estado, un mensaje, un tiempo—, cualquiera que pueda enviarle cookies modificadas recibe una respuesta de sí o no por cada intento. Con suficientes intentos, esa diferencia basta para recuperar el texto claro sin conocer la clave. No hace falta reproducirlo para reconocerlo: en un registro se ve como miles de fallos de descifrado desde un solo origen, mezclados con otro tipo de rechazo.

Lee MiddlewarePreferencias.php y después resumen-por-minuto.txt.

El middleware toma el rol de la cookie para decidir quién puede aprobar una nómina. Eso ya es un problema de diseño —la autorización depende de un dato que guarda el cliente—, y deja de ser teórico cuando ese dato se puede alterar. El controlador registra en cada aprobación el rol que trajo la cookie y el que tiene la base: busca la línea donde no coinciden.

El equipo cree que la clave no se filtró, y probablemente tiene razón: el problema no necesitaba la clave. Lo que falló es el diseño de la cookie y lo que la aplicación hace con ella. MITRE lo recoge como CWE-353, falta de comprobación de integridad, y la decisión de autorizar con un dato del cliente se clasifica aparte, como control de acceso roto.