En seguridad informática hay una idea peligrosa que aparece una y otra vez: “uso HTTPS, así que mis datos están seguros”. Esta frase, tan común como incorrecta, es la puerta de entrada perfecta al OWASP Top 10 – A02: Cryptographic Failures.
Este punto no habla de ataques sofisticados ni de hackers con sudaderas negras. Habla de algo mucho más cotidiano —y mucho más grave—: usar mal la criptografía o no usarla cuando es necesaria.
De “exposición de datos” a “fallos criptográficos”
En ediciones anteriores del OWASP Top 10, este riesgo se conocía como Sensitive Data Exposure. El cambio de nombre a Cryptographic Failures no es un simple ajuste semántico. Es una declaración de intenciones.
El problema real no es que los datos se expongan “por accidente”, sino que:
Se almacenan sin protección
Se cifran con algoritmos obsoletos
Se gestionan claves de forma negligente
Se confía en mecanismos que no ofrecen seguridad real
Cuando la criptografía falla, la aplicación puede funcionar perfectamente… mientras los datos quedan totalmente expuestos.
Qué es realmente un fallo criptográfico
Un fallo criptográfico no significa que el algoritmo sea débil. En la mayoría de los casos, los algoritmos funcionan exactamente como fueron diseñados. El problema está en cómo los usamos.
Algunos ejemplos habituales:
Guardar contraseñas en texto plano
Cifrar contraseñas en lugar de hashearlas
Usar MD5 o SHA-1 porque “siempre se ha hecho así”
Reutilizar claves en distintos sistemas
Incluir secretos directamente en el código fuente
Pensar que Base64 es cifrado
La criptografía no perdona errores conceptuales. Si se aplica mal, la seguridad es una ilusión.
Cifrado, hashing y codificación: la confusión clásica
Uno de los orígenes más comunes de A02 es no distinguir correctamente entre tres conceptos fundamentales:
Cifrado Es un proceso reversible. Sirve para proteger datos que más adelante deben recuperarse, como información personal o datos almacenados.
Hashing Es un proceso irreversible. Está pensado para verificar, no para recuperar. Por eso es la técnica correcta para almacenar contraseñas.
Codificación No es un mecanismo de seguridad. Base64, por ejemplo, solo transforma datos para facilitar su transporte. Cualquiera puede revertirlo.
Cuando una aplicación mezcla estos conceptos, el resultado suele ser desastroso.
Contraseñas: el punto más frágil del sistema
Las contraseñas merecen un capítulo propio dentro de A02. No porque sean un mecanismo perfecto, sino porque siguen siendo el más usado.
Errores críticos que todavía se ven en producción:
Contraseñas almacenadas en texto plano
Contraseñas cifradas con clave reversible
Hashes rápidos sin salt
La práctica correcta implica:
Algoritmos diseñados específicamente para contraseñas
Uso de salt único por usuario
Coste computacional suficiente para frenar ataques de fuerza bruta
Aquí no hay atajos. Si las contraseñas se gestionan mal, todo el sistema cae detrás.
HTTPS no lo soluciona todo
HTTPS protege los datos en tránsito, pero no garantiza que:
Se usen versiones seguras de TLS
Las cookies estén correctamente configuradas
No haya contenido mixto
Los datos se almacenen de forma segura en el servidor
Es posible tener un candado verde en el navegador y, aun así, estar filtrando información sensible sin darse cuenta.
HTTPS es una condición necesaria, pero nunca suficiente.
Tokens, sesiones y APIs modernas
Las aplicaciones actuales dependen cada vez más de APIs y tokens de autenticación. Y aquí aparecen nuevos fallos criptográficos:
Tokens predecibles
JWT sin firma o mal configurados
Tokens expuestos en URLs
Almacenamiento inseguro en el cliente
Muchos de estos errores no rompen la funcionalidad, pero sí la seguridad. El sistema “funciona”, hasta que alguien decide mirarlo con mentalidad de auditor.
Datos sensibles: no todo vale lo mismo
Uno de los errores de diseño más comunes es no clasificar los datos.
No toda la información requiere el mismo nivel de protección, pero hay datos que nunca deberían almacenarse sin medidas criptográficas adecuadas, como:
Credenciales
Identificadores personales
Tokens de acceso
Información financiera
A esto se suman los grandes olvidados: backups, logs y ficheros temporales, que a menudo contienen más información sensible que la propia base de datos principal.
Pensar como auditor: detectar A02
Detectar fallos criptográficos no siempre requiere herramientas avanzadas. Muchas veces basta con observar:
Cómo se gestionan las contraseñas
Qué información aparece en cookies y cabeceras
Qué algoritmos se usan realmente
Dónde se almacenan los secretos
La automatización ayuda, pero el criterio humano es insustituible. Un escáner puede avisar; un profesional entiende el impacto.
Buenas prácticas: menos magia, más criterio
La criptografía segura no consiste en usar lo último, sino en usar lo adecuado:
Algoritmos actuales y bien mantenidos
Gestión centralizada de secretos
Separación de responsabilidades
Decisiones documentadas
La seguridad madura no se basa en trucos, sino en disciplina técnica.
Conclusión
OWASP A02 no trata de romper sistemas. Trata de recordar algo esencial: los datos tienen valor, y protegerlos es una responsabilidad técnica y ética.
La mayoría de los fallos criptográficos no ocurren por falta de herramientas, sino por falta de comprensión. Por eso este punto es clave en cualquier formación técnica: obliga a pensar, a cuestionar y a asumir que la seguridad no es un añadido, sino parte del diseño.
Cuando la criptografía falla, no hay parche que lo arregle después. Solo queda aprender… y hacerlo mejor la próxima vez.
