Principales patrones de uso incorrecto de la criptografía

El modo Electronic Codebook (ECB) cifra cada bloque de forma independiente con la misma clave. Los bloques de texto plano idénticos producen bloques de texto cifrado idénticos. La demostración clásica es el «pingüino ECB»: cifrar una imagen de mapa de bits con ECB conserva la estructura de la imagen a nivel de bloques, por lo que el contorno del pingüino sigue siendo claramente visible en el texto cifrado. El modo ECB no proporciona seguridad semántica y nunca debe utilizarse para ningún fin práctico de cifrado.

Implementar primitivas criptográficas desde cero es una de las prácticas más peligrosas del desarrollo de software. La criptografía requiere una corrección perfecta en condiciones adversas: una filtración sutil de tiempo, un error de uno en el relleno o una interpretación incorrecta de los requisitos de seguridad pueden crear vulnerabilidades explotables que resulten indistinguibles de un comportamiento correcto durante las pruebas normales. Incluso los criptógrafos expertos cometen errores de implementación; los desarrolladores de aplicaciones deben utilizar exclusivamente bibliotecas sometidas a auditorías exhaustivas.

MD5 dejó de ser resistente a colisiones en 2004; crear dos archivos con el mismo hash MD5 es trivial desde el punto de vista computacional. Los ataques de colisión contra SHA-1 se demostraron de forma práctica con el ataque SHAttered de Google en 2017, que generó dos archivos PDF con el mismo hash SHA-1. Ninguno de los dos debe utilizarse con fines de seguridad: firmas digitales, integridad del contenido, almacenamiento de contraseñas o HMAC. Utilice SHA-256, SHA-3 o BLAKE2 en implementaciones modernas.

Utilizar time() u otros valores predecibles para inicializar un generador de números pseudoaleatorios constituye una vulnerabilidad crítica cuando la salida del PRNG se utiliza con fines de seguridad. Un atacante que sepa aproximadamente cuándo se generó una clave puede probar por fuerza bruta el espacio de semillas (todas las marcas de tiempo posibles en un intervalo pequeño) para recuperar la clave. Un ejemplo clásico: las primeras versiones de Netscape inicializaban la generación de claves SSL con la hora y el ID del proceso, ambos observables por un atacante en la misma máquina.

rand() en C, java.util.Random y el módulo random de Python utilizan generadores congruenciales lineales deterministas o Mersenne Twister, diseñados para ofrecer calidad estadística en simulaciones, no seguridad. Un atacante que observe suficiente salida de estos generadores puede reconstruir su estado interno y predecir toda la salida futura. Para fines de seguridad, utilice CSPRNG proporcionados por el sistema operativo: secrets.token_bytes() en Python, crypto.randomBytes() en Node.js o /dev/urandom en Linux.

El cifrado sin autenticación solo proporciona confidencialidad, no integridad. Un atacante que no pueda leer el texto plano aún puede modificar el texto cifrado y provocar cambios potencialmente predecibles en el texto plano (especialmente en los modos CTR o CBC). Esta maleabilidad permite ataques: un atacante que intercepte una transacción bancaria cifrada podría invertir bits para cambiar el importe de la transferencia o la cuenta de destino sin conocer el texto plano. Utilice siempre cifrado autenticado (AEAD).

Codificar claves de cifrado o vectores de inicialización directamente en el código fuente constituye una vulnerabilidad crítica. El código fuente suele confirmarse en repositorios de control de versiones, a veces públicos. Incluso en repositorios privados, cualquiera que tenga acceso al código dispone de la clave. Las claves codificadas hacen que todas las instancias utilicen la misma clave y que la rotación de claves requiera un nuevo despliegue. Las claves deben almacenarse en variables de entorno, sistemas de gestión de secretos (HashiCorp Vault, AWS Secrets Manager) o módulos de seguridad de hardware.

Utilizar el mismo vector de inicialización para varios cifrados con la misma clave crea vulnerabilidades graves. En el modo CTR, reutilizar el IV genera el mismo flujo de claves, lo que permite recuperar el texto plano mediante XOR. En el modo CBC, reutilizar el IV permite a un atacante detectar cuándo dos mensajes comienzan con los mismos bloques de texto plano. En GCM, reutilizar el nonce (IV) es catastrófico (consulte la lección sobre la reutilización de nonces). Genere un IV aleatorio nuevo para cada operación de cifrado; antepóngalo al texto cifrado para almacenarlo junto con el contexto de descifrado.

Almacenar contraseñas procesadas con MD5, SHA-256 o cualquier otra función hash criptográfica rápida es inadecuado. Las GPU modernas pueden calcular miles de millones de hashes SHA-256 por segundo, lo que hace que los ataques de fuerza bruta sin conexión contra bases de datos de hashes robadas sean trivialmente rápidos. El procesamiento de contraseñas requiere funciones lentas y resistentes a la memoria diseñadas específicamente para este fin: bcrypt, scrypt o Argon2id. Estas funciones están diseñadas para encarecer la fuerza bruta incluso con hardware especializado, de modo que los ataques sin conexión resulten computacionalmente inviables.

Desactivar la validación de certificados SSL/TLS (establecer ssl.CERT_NONE en Python, pasar -k a curl o establecer trustAllCerts=true en Android) elimina la protección contra ataques de intermediario. Un atacante puede presentar cualquier certificado e interceptar todas las comunicaciones. Esta práctica aparece durante el desarrollo para evitar errores relacionados con certificados autofirmados, pero con frecuencia persiste en producción. Utilice siempre una validación adecuada de certificados y corrija correctamente los problemas subyacentes de los certificados.

Las funciones criptográficas comunican los fallos mediante valores devueltos o excepciones. Ignorarlos permite que la ejecución continúe con un estado no válido: un descifrado que produjo datos basura, una verificación que falló o una generación de claves que produjo un error. En API basadas en C como OpenSSL, ignorar los valores devueltos es especialmente peligroso porque el programa puede continuar utilizando memoria no inicializada. Compruebe siempre todos los valores devueltos por las funciones criptográficas y gestione los fallos de forma segura.

¿Por qué se considera inseguro el modo ECB (Electronic Codebook) para cifrar datos?

Principales usos incorrectos que debe evitar: nunca utilice el modo ECB (filtra patrones de bloques); nunca implemente primitivas criptográficas por su cuenta; rechace MD5 y SHA-1 con fines de seguridad; inicialice los PRNG con un CSPRNG, no con time(); utilice un CSPRNG para toda aleatoriedad sensible para la seguridad; autentique siempre los datos cifrados (AEAD); nunca codifique claves ni IV; genere un IV nuevo para cada cifrado; utilice Argon2id para las contraseñas, no hashes rápidos; valide siempre los certificados TLS; y compruebe todos los valores devueltos por las funciones criptográficas.