4. A02: Cryptographic Failures

4.1 Introducción

Las aplicaciones web procesan continuamente información sensible: contraseñas, sesiones, datos personales, correos, documentos, registros médicos, datos financieros, claves API, tokens y configuraciones internas. Si esa información se transmite o almacena sin protección adecuada, el sistema puede quedar expuesto aunque otros controles funcionen correctamente.

OWASP denomina Cryptographic Failures a las fallas relacionadas con la protección insuficiente de datos mediante criptografía o mecanismos equivalentes. Antes esta categoría se asociaba mucho a "Sensitive Data Exposure", pero el nombre actual apunta mejor al problema de fondo: no basta con reconocer que los datos son sensibles, hay que usar bien la protección criptográfica donde corresponde.

Este tema no busca convertirnos en criptógrafos, sino desarrollar criterio para entender cuándo la aplicación necesita cifrado, hashing, gestión segura de claves y configuraciones robustas, y qué errores comunes destruyen esa protección.

4.2 Qué protege realmente la criptografía en una aplicación web

En seguridad web, la criptografía suele cumplir varias funciones distintas. Cada una protege un aspecto diferente de la información.

• Confidencialidad: impedir que terceros lean datos sensibles.
• Integridad: detectar o evitar alteraciones no autorizadas.
• Autenticidad: ayudar a verificar identidad o procedencia.
• No exposición accidental: reducir impacto si una base de datos, backup o canal es comprometido.

Por eso la pregunta correcta no es solamente "¿la aplicación usa cifrado?", sino "¿qué datos protege, en qué momento, con qué mecanismo y frente a qué amenaza?".

4.3 Datos sensibles: primero hay que identificarlos

Una organización no puede proteger bien lo que no identifica claramente. Antes de hablar de algoritmos o certificados, la aplicación debe saber qué información requiere protección especial.

Si el equipo no distingue estos activos de la información no sensible, tenderá a subproteger unos o a sobreexponer otros.

4.4 Cifrado en tránsito

El cifrado en tránsito protege la información mientras viaja entre cliente y servidor, o entre servicios internos. Su objetivo es impedir que un atacante en el camino pueda leer o alterar el tráfico fácilmente.

En aplicaciones web esto suele lograrse con HTTPS, es decir, HTTP sobre TLS.

Si la aplicación transmite datos sensibles sin HTTPS o acepta versiones débiles del canal, puede exponer:

• Credenciales enviadas por formularios.
• Cookies de sesión.
• Datos personales y financieros.
• Tokens de autenticación.
• Consultas y respuestas completas de negocio.

4.5 Qué aporta HTTPS y qué no aporta

HTTPS brinda tres beneficios principales cuando está bien implementado:

• Confidencialidad del canal.
• Integridad del tráfico.
• Autenticidad del servidor mediante certificados.

Sin embargo, HTTPS no resuelve por sí solo:

• Inyecciones.
• Control de acceso roto.
• XSS.
• Mala gestión de sesiones.
• Exposición de datos en respuestas legítimas.

HTTPS protege el camino; no arregla decisiones inseguras dentro de la aplicación.

4.6 Cifrado en reposo

El cifrado en reposo protege la información cuando ya está almacenada, por ejemplo en bases de datos, discos, backups, buckets de almacenamiento o archivos exportados. Su objetivo es reducir el impacto si un soporte es robado, un backup se filtra o una capa de infraestructura queda expuesta.

Es importante entender que cifrar en reposo no sustituye el control de acceso de la aplicación. Si el sistema descifra y entrega datos a cualquier usuario no autorizado, el problema sigue existiendo. Aun así, sigue siendo una capa valiosa cuando el riesgo está en la extracción directa de soportes o datos persistentes.

4.7 Cifrar no es lo mismo que hashear

Una confusión muy común es tratar cifrado y hashing como si fueran equivalentes. No lo son.

Por eso las contraseñas no deberían almacenarse cifradas "para luego verlas", sino hasheadas con algoritmos apropiados para ese uso.

4.8 Contraseñas: nunca deben almacenarse en claro

Uno de los errores más graves y todavía presentes en muchas aplicaciones es guardar contraseñas en texto plano o con mecanismos triviales. Si una base de datos se expone y las contraseñas están legibles, el impacto es inmediato y devastador.

Las contraseñas deben almacenarse usando algoritmos de hashing diseñados específicamente para resistir ataques de fuerza bruta y cracking masivo. El objetivo es que, aun si la base es robada, recuperar las contraseñas reales sea costoso y lento.

Guardar contraseñas en claro, cifrarlas con una clave compartida o usar hash rápido sin endurecimiento son prácticas inseguras.

4.9 Hashing seguro de contraseñas

El almacenamiento adecuado de contraseñas requiere mecanismos preparados para este caso de uso, como funciones de derivación de clave y hashing lento. Además, se debe incorporar sal y un costo computacional apropiado.

Conceptos importantes:

• Salt: valor aleatorio por contraseña para evitar ataques basados en tablas precalculadas y patrones repetidos.
• Coste o work factor: parámetro que aumenta el esfuerzo de cómputo y dificulta cracking masivo.
• Algoritmo adecuado: usar mecanismos pensados para contraseñas, no hashes genéricos rápidos.

El error conceptual más frecuente es elegir algoritmos rápidos porque "rinden mejor". Para contraseñas, esa velocidad favorece al atacante.

4.10 Secretos, claves y credenciales técnicas

Las aplicaciones modernas usan numerosos secretos además de las contraseñas de usuarios: claves de cifrado, secretos JWT, tokens de acceso, cadenas de conexión, credenciales de servicios cloud, llaves SSH y claves API de terceros.

Si esos secretos quedan expuestos en código fuente, archivos de configuración, variables de entorno inseguras, imágenes de contenedor o repositorios públicos, la aplicación puede ser comprometida incluso sin explotar una vulnerabilidad clásica.

Proteger secretos implica:

• No hardcodearlos en el código.
• Limitar quién puede acceder a ellos.
• Rotarlos cuando sea necesario.
• Usar almacenes o mecanismos seguros de gestión.

4.11 El problema de la gestión de claves

La seguridad de un esquema criptográfico no depende solo del algoritmo. También depende críticamente de cómo se generan, almacenan, distribuyen, usan y rotan las claves.

Errores frecuentes:

• Guardar la clave junto con los datos cifrados.
• Usar la misma clave para múltiples propósitos incompatibles.
• No rotar claves a lo largo del tiempo.
• Permitir acceso amplio a claves maestras.
• No contar con procedimientos para revocar o reemplazar claves comprometidas.

Un algoritmo robusto pierde valor si la clave está mal protegida.

4.12 Algoritmos débiles o configuraciones obsoletas

No toda criptografía ofrece el mismo nivel de protección. Usar mecanismos viejos, parámetros débiles o configuraciones heredadas puede generar una falsa sensación de seguridad.

Ejemplos conceptuales de malas decisiones:

• Permitir protocolos TLS obsoletos.
• Usar cifrados débiles o suites inseguras.
• Emplear hashes rápidos genéricos para contraseñas.
• Usar claves demasiado cortas o reutilizadas.
• Depender de mecanismos caseros en lugar de librerías confiables.

4.13 Criptografía casera: una mala práctica recurrente

Cuando un equipo intenta "ocultar" datos con transformaciones simples, codificación base64, operaciones reversibles triviales o esquemas diseñados internamente, no está aplicando seguridad real. Está creando ofuscación.

La ofuscación puede dificultar una lectura superficial, pero no reemplaza cifrado robusto ni gestión segura de claves. En revisiones de seguridad, este problema aparece con frecuencia en:

• Tokens fabricados manualmente.
• Parámetros "protegidos" con concatenaciones o XOR simples.
• Datos sensibles codificados y tratados como si estuvieran cifrados.
• Contraseñas transformadas con algoritmos no apropiados.

4.14 Datos sensibles que la aplicación devuelve sin necesidad

A veces el problema no es que falte cifrado, sino que la aplicación expone demasiada información en respuestas, logs, trazas o mensajes de error. Si el servidor devuelve más datos de los necesarios, está ampliando innecesariamente la superficie de exposición.

Ejemplos:

• Mostrar números completos de tarjeta donde bastaría un fragmento.
• Devolver secretos o hashes en respuestas JSON.
• Incluir datos personales completos en logs de aplicación.
• Exponer tokens en URLs, reportes o pantallas de error.

La mejor protección de un dato sensible muchas veces empieza por no transportarlo ni mostrarlo si no es imprescindible.

4.15 Protección de cookies y tokens sensibles

Las cookies de sesión, tokens de autenticación y otros artefactos de identidad son datos sensibles. Si se interceptan o roban, un atacante puede asumir el contexto del usuario.

Su protección implica:

• Transmitirlos solo por HTTPS.
• Usar atributos adecuados en cookies, como Secure y HttpOnly.
• No incluirlos en URLs.
• Evitar almacenamiento inseguro del lado cliente.
• Controlar expiración, renovación e invalidación.

Desde seguridad, estos elementos deben tratarse como equivalentes temporales de identidad.

4.16 Datos sensibles en logs, backups y archivos auxiliares

Muchas exposiciones ocurren fuera del flujo principal de la aplicación. Aunque la interfaz sea correcta, los datos pueden filtrarse por canales secundarios.

Hay que revisar especialmente:

• Logs de aplicación y servidor.
• Backups de bases de datos.
• Archivos temporales o exportaciones.
• Capturas de errores y trazas de debugging.
• Ambientes de prueba con datos reales copiados.

Un backup mal protegido o un log expuesto puede anular por completo el esfuerzo puesto en otras capas de seguridad.

4.17 Ejemplos típicos de Cryptographic Failures

• Formulario de login servido por HTTP en lugar de HTTPS.
• Contraseñas almacenadas en texto plano.
• Hash de contraseñas con algoritmos demasiado rápidos.
• Claves API hardcodeadas en el repositorio.
• Datos sensibles guardados sin cifrado en backups accesibles.
• Cookies de sesión sin Secure.
• Uso de TLS obsoleto o certificados mal gestionados.
• Exposición de secretos en logs o mensajes de error.

4.18 Impacto de esta categoría

Las fallas criptográficas pueden tener impacto directo e inmediato porque afectan datos de alto valor y mecanismos centrales de identidad y confianza.

4.19 Señales que justifican una revisión más profunda

Durante un análisis, algunos indicadores sugieren revisar de cerca la protección criptográfica:

• La aplicación todavía acepta HTTP o redirige tarde a HTTPS.
• Existen secretos en código fuente o archivos públicos.
• Se observan datos sensibles completos en respuestas o logs.
• Las cookies de sesión carecen de atributos de seguridad.
• El equipo no sabe qué algoritmo o política usa para contraseñas.
• Hay backups accesibles desde ubicaciones débiles o compartidas.
• No existe proceso de rotación o inventario de claves.

4.20 Qué no se debe hacer con contraseñas

Conviene dejar muy explícitas algunas malas prácticas porque siguen apareciendo con frecuencia:

• Guardar contraseñas en texto plano.
• Poder recuperar la contraseña original y enviarla por correo.
• Hashear contraseñas con algoritmos rápidos sin endurecimiento.
• Compartir el mismo secreto o pepper sin control adecuado.
• Registrar contraseñas en logs por error.

Si la aplicación puede "mostrarte tu contraseña actual", hay un problema grave de diseño.

4.21 Buenas prácticas de prevención

La prevención de Cryptographic Failures combina decisiones técnicas y operativas.

• Clasificar correctamente los datos sensibles.
• Usar HTTPS de forma consistente en todo el sitio y servicios asociados.
• Aplicar almacenamiento seguro de contraseñas con mecanismos apropiados.
• Proteger secretos y claves fuera del código fuente.
• Elegir algoritmos y parámetros actuales y mantenidos.
• Minimizar la exposición de datos en respuestas, logs y backups.
• Planificar rotación, revocación y control de acceso a claves.

4.22 Minimización de datos como defensa

Una defensa muy poderosa y muchas veces subestimada consiste en almacenar, procesar y exponer menos información. Cuantos menos datos sensibles maneje la aplicación, menor será el impacto si algo falla.

Ejemplos de minimización:

• No guardar datos que no son necesarios.
• Mostrar solo fragmentos de información sensible.
• Evitar copiar datos sensibles a logs o entornos de prueba.
• Reducir retención innecesaria de registros históricos.

4.23 Relación con otras vulnerabilidades

Las fallas criptográficas suelen potenciar otras categorías del curso.

• Con Authentication Failures, si el robo de sesiones o credenciales se vuelve más fácil.
• Con Security Misconfiguration, si HTTPS o certificados están mal configurados.
• Con Vulnerable and Outdated Components, si la protección depende de librerías obsoletas.
• Con Logging Failures, si secretos y datos sensibles quedan registrados sin control.

Esto muestra que la criptografía no es una isla: forma parte de un sistema más amplio de protección.

4.24 Qué debes recordar de este tema

• La protección de datos sensibles exige identificar primero qué información es crítica.
• HTTPS protege el canal, pero no reemplaza otros controles de aplicación.
• Cifrado y hashing cumplen funciones distintas y no deben confundirse.
• Las contraseñas deben almacenarse con mecanismos apropiados para hashing seguro.
• La seguridad de la criptografía depende también de la gestión de claves y secretos.
• Logs, backups y archivos auxiliares pueden filtrar tanta información como la aplicación principal.
• La minimización de datos reduce impacto y superficie de exposición.

4.25 Conclusión

Cryptographic Failures no se limita a elegir un algoritmo. Se trata de proteger correctamente información sensible en cada etapa de su ciclo de vida: transmisión, almacenamiento, uso y retención. Una aplicación puede tener lógica sólida y aun así quedar comprometida si credenciales, sesiones, secretos o backups están mal protegidos.

En el próximo tema estudiaremos A03: Injection, una de las categorías más conocidas de seguridad web, donde el problema ya no es la protección de datos por cifrado, sino la forma en que la aplicación interpreta entradas maliciosas.