Los fallos de uso, uno a uno

Un servicio valida un token de sesión comparándolo con el valor esperado usando una comparación normal de cadenas, la que corta en cuanto encuentra el primer carácter distinto. Ese corte temprano filtra información por el tiempo: un atacante que mide cuánto tarda la comparación va averiguando el token carácter a carácter. Para comparar dos valores secretos —tokens, firmas, códigos de autenticación— se usa una comparación en tiempo constante, que siempre tarda lo mismo pase lo que pase. El arreglo es cambiar el operador de igualdad por la función de comparación constante que trae la librería criptográfica.

El fallo es «comparar con el operador equivocado»: el mismo == de siempre, que para secretos filtra por el reloj.

Otro servicio genera vectores de inicialización y tokens con un generador de números al azar de propósito general, el de la librería estándar del lenguaje. Ese generador es predecible: a partir de unas cuantas salidas se puede reconstruir su estado y anticipar las siguientes, así que los IV y tokens dejan de ser impredecibles. Todo lo que en criptografía debe ser impredecible —claves, IV y nonces, tokens, sales— sale de un generador criptográficamente seguro, no del de propósito general. El arreglo es usar la fuente de azar criptográfico del sistema o de la librería criptográfica.

El fallo es alimentar una primitiva correcta con un azar que se puede adivinar: el algoritmo resiste, la entrada no.

Un servicio «cifra» un dato aplicándole una operación XOR con una clave fija inventada por el equipo, en vez de usar una primitiva estándar. Inventarse un algoritmo es uno de los errores más viejos: un XOR con clave fija se rompe con análisis básico, y en general nadie fuera de un puñado de especialistas diseña criptografía que resista. La regla del oficio es no inventar: se usan primitivas estándar, revisadas por años de escrutinio público —AES-GCM para cifrar, las funciones de hash vigentes, las librerías conocidas—. El arreglo es tirar el invento y cifrar con una primitiva estándar bien usada.

El fallo no es un detalle de configuración: es construir la criptografía en vez de usar la que ya está probada.

Para depurar un problema, un servicio de CifraLab dejó una línea que escribe en el registro la clave y el token que está usando, «temporalmente», y quedó. Un secreto en un log es un secreto filtrado: los registros se copian, se centralizan, se ven por mucha gente y se retienen durante meses, así que la clave acaba en sitios donde nadie la controla. El arreglo es no registrar nunca material criptográfico —claves, tokens, sales, contenido descifrado— y, si hace falta depurar, registrar un identificador que no revele el secreto. La línea «temporal» es la vía más común por la que un secreto sale a la luz.

El fallo es tratar el registro como un lugar privado; no lo es, y todo lo que se escribe ahí deja de ser secreto.

Viste los cuatro fallos de uso provocados uno a uno: la comparación que corta antes de tiempo, el azar predecible, el cifrado casero y el secreto dejado en el registro. Esta verificación cierra el módulo: abre el laboratorio, recorre esos fragmentos y lee el código que la auditoría anotó al cerrar la sala.