En este capítulo, A04:2025 Fallos criptográficos – Cryptographic Failures, aprenderás a identificar, comprender y prevenir uno de los riesgos más críticos en la seguridad moderna: los fallos criptográficos. Estos errores no solo implican algoritmos débiles, claves mal gestionadas o datos sin cifrar: representan la línea que separa la confidencialidad de tus usuarios y un desastre absoluto.

A lo largo del contenido verás cómo se rompen los sistemas criptográficos, desde configuraciones TLS inseguras hasta almacenamiento de contraseñas con hashes débiles. Estudiarás ataques reales, vulnerabilidades comunes según CWE, técnicas de explotación utilizadas por atacantes y las mejores prácticas actuales —incluyendo TLS moderno, gestión de claves, uso de bóvedas de secretos, y preparación para la criptografía post-cuántica.

Este capítulo te permitirá comprender no solo la teoría, sino el pensamiento práctico que debe tener un profesional de seguridad, aprendiendo a anticipar fallos, detectarlos y corregirlos antes de que se conviertan en una filtración de datos.

Fallos criptográficos – Cryptographic Failures

Cuando hablamos de fallos criptográficos, no estamos hablando solo de algoritmos rotos o de que alguien dejó MD5 en un sistema viejo. Estamos hablando de una categoría entera de negligencia, de errores de diseño, de malas decisiones de arquitectura que convierten cualquier aplicación en un objetivo fácil. Y no importa si usás HTTPS o AES-256. Si no entendés cómo, cuándo y por qué usar criptografía, igual vas a quedar expuesto.

Este riesgo —A04:2025— cayó en el ranking, pero no porque se haya vuelto menos importante, sino porque otras categorías subieron por el contexto. Pero los fallos criptográficos siguen ahí, escondidos en cada login mal hecho, en cada base de datos con hashes débiles, en cada token generado con poca entropía, y en cada conexión que usa TLS 1.0 porque “todavía anda”.

La mayoría de las vulnerabilidades de este tipo se agrupan bajo CWE como el uso de algoritmos rotos (CWE-327), entropía insuficiente (CWE-331), generadores de números aleatorios predecibles (CWE-1241, CWE-338), y almacenamiento criptográfico inseguro. ¿El patrón común? Gente usando herramientas potentes sin saber cómo funcionan. Es como si te dieran una Glock y no supieras sacarle el seguro: tarde o temprano, te disparás solo.

Las apps siguen almacenando datos sensibles sin cifrar: contraseñas, tarjetas, historiales médicos, PII, lo que se te ocurra. Y no estoy hablando de sistemas de hace 15 años: estoy hablando de plataformas modernas, donde los desarrolladores siguen metiendo SHA-1 en producción, o donde las contraseñas se guardan como bcrypt(md5(pass)), creyendo que eso es seguro. Hay bases de datos enteras expuestas, rutas que devuelven dumps enteros, y servidores que descifran todo automáticamente sin ningún control. Ni MAC, ni separación de claves, ni nada.

La criptografía se rompe cuando no se implementa con criterio. Si usás algoritmos obsoletos, si compartís claves entre servicios, si generás tus IVs con un contador o con el timestamp, si hardcodeás secretos en el código, o si usás Math.random() para un token de recuperación, no tenés cifrado: tenés una ilusión.

Además, el cifrado en tránsito tampoco es suficiente si no lo hacés bien. TLS 1.2 o 1.3 es lo mínimo. Todo lo demás está muerto. Y eso incluye protocolos antiguos, algoritmos como RC4 o 3DES, y configuraciones débiles. Si tu servidor todavía acepta SSLv3, es directamente negligencia. Si no forzás HSTS, si no configurás los certificados como corresponde, si no usás claves fuertes y modernas, estás dando vueltas con un paraguas roto en una tormenta.

También está el tema de los PRNG. Generar claves, IVs o tokens con generadores no criptográficos es un clásico. Y es muy fácil de pasar por alto. Hoy tenés CSPRNGs en todos los lenguajes modernos, pero siguen existiendo implementaciones donde la seed se inicializa con la hora del sistema o con una variable de entorno. Y sí, eso se rompe. Rápido. Con GPU. Y en silencio.

Pero el problema va más allá del código. Es cultural. Hay equipos que siguen usando contraseñas en claro porque “es más fácil para debuggear”. También Hay arquitectos que definen que no hace falta cifrar porque “la red está segmentada”. Hay managers que cortan presupuesto de seguridad porque “ya usamos HTTPS”. Y después, cuando explota, nadie sabe cómo, pero todos sabían que podía pasar.

Los secretos, además, se siguen gestionando como si estuviéramos en 2005. Aparecen en .env, en logs, en pipelines, en backups sin cifrar, en registros que terminan en Pastebin. Nadie rota claves, nadie valida accesos, nadie monitorea cuándo y desde dónde se accede a los secretos. Y después se sorprenden cuando alguien accede a producción con una clave vieja encontrada en un repo viejo. Vault, KMS, Hashicorp, AWS Secrets Manager, da igual cuál uses. El tema es usar algo. No dejarlo librado al azar.

Y ojo con la aleatoriedad. No basta con “usar un generador seguro”. Hay que saber cuándo usarlo, cómo inicializarlo, y qué hacer con el resultado. Muchos modos de cifrado, como GCM o CCM, requieren IVs únicos por clave. Si repetís IVs, aunque uses AES-256, te reventaron. No hace falta romper el cifrado: con un par de textos cifrados con el mismo IV, se puede sacar el contenido.

En cuanto al almacenamiento, siempre repito lo mismo: si no necesitás guardar datos sensibles, no los guardes. Tokenizá, truncá, desechá. Y si los vas a guardar, hacelo con cifrado fuerte, autenticado, usando claves bien protegidas y rotadas. Y no mezcles roles: las claves para firmar no deben cifrar. Las claves para cifrar no deben autenticar. Cada función, su clave.

Y sí, pensá en la postcuántica. Hoy no es urgente, pero lo va a ser. Los algoritmos que usamos hoy para firmas y clave pública no van a aguantar una computadora cuántica decente. El NIST ya publicó estándares postcuánticos como Kyber, Dilithium y Sphincs+. Si estás diseñando para largo plazo, pensá en cómo vas a migrar.

En resumen, los fallos criptográficos no son un “problema técnico”. Son el síntoma de una falta de cultura de seguridad. Usar criptografía sin saber es como usar un arma sin entrenamiento. Puede que dispares, pero no sabés a qué. Y tarde o temprano, el tiro te vuelve.

OWASP TOP 10 

OWASP es popular por publicar el TOP 10 Owasp Web cada cuatro años. Este es un  documento que lista los diez riesgos más críticos en aplicaciones web, con el objetivo de  ayudar a las organizaciones a identificar y mitigar las vulnerabilidades asociadas con estos riesgos. https://owasp.org/Top10/es/ Cada uno de estos riesgos representa una debilidad común y significativa que a menudo se puede explotar para comprometer la seguridad de una aplicación web. OWASP proporciona información detallada sobre posibles vulnerabilidades y técnicas de ataque para cada riesgo.

El Top 10 de OWASP es una lista que se actualiza periódicamente de los riesgos de seguridad de las aplicaciones web más críticos. Lo mantiene el Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP), una organización sin fines de lucro centrada en mejorar la seguridad de las aplicaciones web. Sirve como una valiosa guía para que los desarrolladores, los expertos en pruebas de penetración de aplicaciones web y las organizaciones comprendan y prioricen los riesgos de seguridad comunes en las aplicaciones web.

El Top 10 de OWASP es una lista conocida de los diez riesgos de seguridad de aplicaciones web más críticos. Se actualiza periódicamente para garantizar que refleje el panorama actual de amenazas y los desafíos de seguridad en constante evolución que enfrentan las aplicaciones web. La primera versión del Top 10 de OWASP se publicó en 2003. Su objetivo era crear conciencia sobre los riesgos comunes de seguridad de las aplicaciones web y ayudar a los desarrolladores a priorizar los esfuerzos de seguridad. La lista incluía riesgos como secuencias de comandos entre sitios (XSS), inyección de SQL y problemas de gestión de sesiones. Cada lanzamiento del Top 10 de OWASP se basa en las versiones anteriores, mejorando su precisión, relevancia y practicidad.

La evolución de A04:2025 – Fallos Criptográficos: de un riesgo invisible a una amenaza estructural en la era digital

En la historia del OWASP Top 10, pocas categorías han tenido una transformación tan interesante y significativa como Fallos Criptográficos (Cryptographic Failures). Aunque la criptografía siempre fue un componente esencial de la seguridad de la información, durante muchos años la industria la consideró una disciplina estable, madura, casi estática, donde los algoritmos y protocolos ampliamente adoptados parecían ofrecer garantías sólidas. Sin embargo, la realidad demostró lo contrario: los fallos criptográficos no son problemas raros o teóricos, sino uno de los factores que más contribuyen a brechas masivas, filtraciones de datos, compromisos de credenciales y ataques avanzados que afectan a millones de usuarios. La evolución de esta categoría, desde sus primeras apariciones bajo distintos nombres hasta convertirse en A04:2025, refleja no solo cambios tecnológicos, sino el reconocimiento tardío de que la criptografía mal implementada es una amenaza tan seria como cualquier inyección o fallo de acceso.

⚪No cambia

🟡Fusionado

🔵Cambia de posición

🟢Nuevo

En los primeros años del OWASP Top 10 (2003, 2004, 2007 y 2010), los fallos criptográficos existían, pero estaban dispersos en categorías más amplias como “Sensitive Data Exposure”, “Insecure Storage” o “Cryptographic Storage Failures”. La percepción dominante era que la criptografía era un área relativamente controlada: la mayoría de los desarrolladores simplemente reutilizaban las funciones criptográficas provistas por sus frameworks, y se asumía que eso era suficiente para proteger datos sensibles. Sin embargo, estos primeros rankings mostraban señales claras de un problema subyacente: cifrado débil, uso de algoritmos obsoletos, claves demasiado cortas, almacenamiento inseguro de credenciales, falta de salts en hashes de contraseñas y configuraciones iniciales incorrectas en TLS/SSL. En ese momento, la categoría no ocupaba posiciones altas, pero OWASP ya advertía que los desarrolladores cometían errores sistemáticos al implementar o configurar criptografía.

Entre 2010 y 2017, a medida que las aplicaciones comenzaron a exponerse más a internet, crecieron también los ataques orientados al robo de datos sensibles. La expansión del comercio electrónico, las APIs públicas, la autenticación tokenizada y los servicios cloud generó nuevos vectores de ataque. OWASP reorganizó la categoría en 2013 y 2017, dándole mayor visibilidad bajo el nombre Sensitive Data Exposure, que finalmente se transformaría en Cryptographic Failures en la edición 2021. Esta transición es importante: OWASP pasó de enfocarse en la “exposición del dato” a enfocar la “causa raíz”, que casi siempre era una mala implementación criptográfica. Durante esta etapa, comenzaron a tomar relevancia ataques que demostraron fragilidades en la criptografía real, como BEAST, POODLE, Heartbleed, FREAK o ataques contra configuraciones TLS inseguras. Cada uno de estos incidentes reveló que los errores no estaban solo en algoritmos viejos, sino en cómo la industria aplicaba la criptografía: versiones inseguras de TLS activas por defecto, bibliotecas mal configuradas, validación incorrecta de certificados, gestión deficiente de claves, e incluso ignorancia completa sobre cómo funcionan los mecanismos criptográficos.

La verdadera madurez llegó en OWASP Top 10 – 2021, cuando la categoría cambió oficialmente su nombre a Cryptographic Failures, elevándola a uno de los primeros puestos. Esta decisión reflejaba un problema mucho más amplio que la simple exposición de datos sensibles: la criptografía era usada en prácticamente todos los aspectos críticos del software —desde autenticación, confidencialidad e integridad hasta transmisión segura, tokens JWT, APIs, almacenamiento, control de versiones y contenedores— pero casi siempre se aplicaba incorrectamente. OWASP descubrió que los desarrolladores utilizaban algoritmos rotos como MD5 o SHA-1, cifraban datos sin utilizar IVs aleatorios, implementaban cifrados propios (conocidos como homebrew crypto), validaban incorrectamente certificados, configuraban mal el modo de operación (ECB, CBC sin autenticación, GCM mal aplicado), generaban claves con poca entropía o implementaban PRNGs no criptográficamente seguros. El problema ya no era que el dato se exponía: el problema era que la mayoría de las aplicaciones cifraban mal.

OWASP TOP 10  2021

 

OWASP TOP 10  2025

Con la llegada de OWASP Top 10 – 2025, la categoría A04: Cryptographic Failures mantiene un lugar dominante dentro de los primeros puestos. El ascenso o estabilización en este nivel refleja que, pese a que la industria avanzó hacia arquitecturas más seguras, la criptografía sigue siendo un área donde los errores de implementación tienen consecuencias catastróficas. En 2025, los principales vectores de ataque ya no giran tanto en torno a algoritmos rotos —porque la mayoría fueron eliminados— sino a configuraciones incorrectas, validaciones defectuosas, generación de claves inapropiada, mal manejo del ciclo de vida de claves, errores en hardware security modules, mala integración de TLS en microservicios, exposición accidental de claves privadas en repositorios públicos y fallos en la criptografía aplicada a contenedores, almacenamiento cloud y pipelines CI/CD. La complejidad del software moderno aumentó la dependencia en criptografía, pero no necesariamente mejoró la competencia en su uso.

Uno de los factores principales que explica el peso de esta categoría en 2025 es la explosión del uso de APIs, microservicios, autenticación federada (OAuth, OpenID Connect), tokens JWT y servicios serverless. En estos entornos, la criptografía no es simplemente “un componente”, sino la columna vertebral del modelo de seguridad. Un JWT mal firmado, una clave HS256 compartida públicamente, un certificado expirado, un algoritmo débil o una configuración errónea en un balanceador puede comprometer a toda una infraestructura. Además, la automatización masiva generada por DevOps, IaC y contenedores crea nuevos escenarios donde claves y secretos se propagan sin control: archivos .env, variables de entorno accesibles, secretos incluidos en imágenes Docker, configuraciones YAML subidas por error a GitHub. OWASP reconoce en 2025 que gran parte de los incidentes modernos se deben no al cifrado en sí, sino al mal manejo del cifrado.

Otro elemento clave en la evolución hacia 2025 es el surgimiento de nuevas amenazas como la computación cuántica, que está impulsando una transición global hacia algoritmos resistentes a ataques cuánticos. Aunque esta tecnología aún no es una amenaza directa, OWASP observa que la industria está entrando en una nueva fase donde la longevidad criptográfica se vuelve tan importante como la fortaleza actual. Los fallos criptográficos ya no se miden solo por su impacto técnico inmediato, sino por el riesgo futuro que representan sistemas que no adopten protocolos modernos o que utilicen claves inapropiadas. En 2025, OWASP integra en esta categoría buenas prácticas asociadas a criptografía post-cuántica, rotación de claves, gestión segura mediante vaults y análisis continuo del estado criptográfico.

 

Lo más significativo es que A04:2025 consolida una idea fundamental que OWASP viene transmitiendo desde hace más de una década: la criptografía no es un problema de matemáticas, sino de implementación. Los algoritmos modernos son extremadamente robustos, pero si se aplican mal —si una clave se expone, si se usa un modo incorrecto, si el sistema no valida certificados, si el random no es seguro— deja de importar cuán sólido sea el algoritmo. El eslabón más débil casi siempre está en el desarrollador, el pipeline, la configuración o el operador. En 2025, OWASP deja claro que los fallos criptográficos continúan siendo uno de los riesgos más devastadores porque son silenciosos, difíciles de detectar y, cuando ocurren, permiten al atacante obtener lo que más valor tiene en una aplicación: sus datos, su identidad y su integridad.

En síntesis, la evolución de Fallos Criptográficos desde 2003 hasta 2025 es la historia de un riesgo que siempre estuvo ahí, pero que la industria ignoró hasta que su impacto se volvió imposible de negar. Su consolidación como A04:2025 confirma que no importa cuán avanzadas sean las arquitecturas modernas: si la criptografía falla, todo falla. La categoría es una advertencia clara: ninguna aplicación puede considerarse segura si utiliza criptografía débil, mal implementada, mal configurada o mal gestionada. Y en un mundo donde cada interacción, cada token, cada archivo y cada bit viaja cifrado, los errores en esta capa se convierten en el punto más crítico de toda la infraestructura.

A04:2025 Fallos criptográficos

En este capítulo, A04:2025 Fallos criptográficos – Cryptographic Failures, aprenderás a identificar, comprender y prevenir uno de los riesgos más críticos en la seguridad moderna: los fallos criptográficos. Estos errores no solo implican algoritmos débiles, claves mal gestionadas o datos sin cifrar: representan la línea que separa la confidencialidad de tus usuarios y un desastre absoluto.

A lo largo del contenido verás cómo se rompen los sistemas criptográficos, desde configuraciones TLS inseguras hasta almacenamiento de contraseñas con hashes débiles. Estudiarás ataques reales, vulnerabilidades comunes según CWE, técnicas de explotación utilizadas por atacantes y las mejores prácticas actuales —incluyendo TLS moderno, gestión de claves, uso de bóvedas de secretos, y preparación para la criptografía post-cuántica.

Este capítulo te permitirá comprender no solo la teoría, sino el pensamiento práctico que debe tener un profesional de seguridad, aprendiendo a anticipar fallos, detectarlos y corregirlos antes de que se conviertan en una filtración de datos.

Fallos criptográficos – Cryptographic Failures

Cuando hablamos de fallos criptográficos, no estamos hablando solo de algoritmos rotos o de que alguien dejó MD5 en un sistema viejo. Estamos hablando de una categoría entera de negligencia, de errores de diseño, de malas decisiones de arquitectura que convierten cualquier aplicación en un objetivo fácil. Y no importa si usás HTTPS o AES-256. Si no entendés cómo, cuándo y por qué usar criptografía, igual vas a quedar expuesto.

Este riesgo —A04:2025— cayó en el ranking, pero no porque se haya vuelto menos importante, sino porque otras categorías subieron por el contexto. Pero los fallos criptográficos siguen ahí, escondidos en cada login mal hecho, en cada base de datos con hashes débiles, en cada token generado con poca entropía, y en cada conexión que usa TLS 1.0 porque “todavía anda”.

La mayoría de las vulnerabilidades de este tipo se agrupan bajo CWE como el uso de algoritmos rotos (CWE-327), entropía insuficiente (CWE-331), generadores de números aleatorios predecibles (CWE-1241, CWE-338), y almacenamiento criptográfico inseguro. ¿El patrón común? Gente usando herramientas potentes sin saber cómo funcionan. Es como si te dieran una Glock y no supieras sacarle el seguro: tarde o temprano, te disparás solo.

Las apps siguen almacenando datos sensibles sin cifrar: contraseñas, tarjetas, historiales médicos, PII, lo que se te ocurra. Y no estoy hablando de sistemas de hace 15 años: estoy hablando de plataformas modernas, donde los desarrolladores siguen metiendo SHA-1 en producción, o donde las contraseñas se guardan como bcrypt(md5(pass)), creyendo que eso es seguro. Hay bases de datos enteras expuestas, rutas que devuelven dumps enteros, y servidores que descifran todo automáticamente sin ningún control. Ni MAC, ni separación de claves, ni nada.

Bajando dos posiciones hasta el n.º 4, esta debilidad se centra en fallos relacionados con la falta de criptografía, criptografía insuficientemente robusta, fuga de claves criptográficas y errores relacionados. Tres de las Enumeraciones de Debilidades Comunes (CWE) más comunes en este riesgo implicaban el uso de un generador de números pseudoaleatorios débil: CWE-327 Uso de un algoritmo criptográfico defectuoso o arriesgado, CWE-331: Entropía insuficiente , CWE-1241: Uso de un algoritmo predecible en un generador de números aleatorios y CWE-338 Uso de un generador de números pseudoaleatorios criptográficamente débil (PRNG) .

El almacenamiento criptográfico inseguro es una vulnerabilidad común que existe cuando los datos confidenciales no se almacenan de forma segura.

Las credenciales de usuario, la información del perfil, los detalles de salud, la información de la tarjeta de crédito, etc. se consideran información confidencial en un sitio web.

Estos datos se almacenarán en la base de datos de la aplicación. Si estos datos se almacenan de forma incorrecta, es decir, sin utilizar cifrado o hash*, serán vulnerables a los atacantes.

(*El hash es la transformación de los caracteres de una cadena en cadenas más cortas de longitud fija o en una clave. Para descifrar la cadena, debe estar disponible el algoritmo utilizado para formar la clave)

Implicación

• Al utilizar esta vulnerabilidad, un atacante puede robar y modificar dichos datos débilmente protegidos para llevar a cabo robos de identidad, fraudes con tarjetas de crédito u otros delitos.

Objetos vulnerables

• Base de datos de la aplicación.

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
32	13,77%	3,80%	100.00%	47,74%	7.23	3.90	1.665.348	2.185

Descripción.

En general, todos los datos en tránsito deben cifrarse en la capa de transporte ( capa 4 del sistema OSI). Los obstáculos anteriores, como el rendimiento de la CPU y la gestión de claves privadas y certificados, ahora se superan mediante CPU con instrucciones diseñadas para acelerar el cifrado (p. ej., compatibilidad con AES ). La gestión de claves privadas y certificados se simplifica gracias a servicios como LetsEncrypt.org , donde los principales proveedores de servicios en la nube ofrecen servicios de gestión de certificados aún más integrados para sus plataformas específicas.

Además de proteger la capa de transporte, es importante determinar qué datos necesitan cifrado en reposo y cuáles necesitan cifrado adicional en tránsito (en la capa de aplicación , capa 7 del sistema OSI). Por ejemplo, las contraseñas, los números de tarjetas de crédito, los historiales médicos, la información personal y los secretos comerciales requieren protección adicional, especialmente si dichos datos están sujetos a leyes de privacidad, como el Reglamento General de Protección de Datos (RGPD) de la UE o regulaciones como el

Estándar de Seguridad de Datos PCI (PCI DSS). Para todos estos datos:

• ¿Se utilizan algoritmos o protocolos criptográficos antiguos o débiles de forma predeterminada o en códigos más antiguos?
• ¿Se utilizan claves criptográficas predeterminadas, se generan claves criptográficas débiles, se reutilizan las claves o falta una gestión y rotación de claves adecuadas?
• ¿Se registran las claves criptográficas en los repositorios de código fuente?
• ¿No se aplica el cifrado? Por ejemplo, ¿faltan directivas de seguridad o encabezados de encabezados HTTP (navegador)?
• ¿El certificado de servidor recibido y la cadena de confianza están correctamente validados?
• ¿Se ignoran, reutilizan o no se generan los vectores de inicialización con la seguridad suficiente para el modo criptográfico? ¿Se utiliza un modo inseguro como ECB? ¿Se utiliza cifrado cuando el cifrado autenticado es más adecuado?
• ¿Se están utilizando contraseñas como claves criptográficas en ausencia de una función de derivación de claves basada en contraseñas?
• ¿Se utiliza la aleatoriedad con fines criptográficos que no fueron diseñados para cumplir con los requisitos criptográficos? Incluso si se elige la función correcta, ¿debe el desarrollador generarla? Y, de no ser así, ¿ha sobrescrito el desarrollador la potente funcionalidad de generación de semillas integrada con una semilla que carece de suficiente entropía/imprevisibilidad?
• ¿Se utilizan funciones hash obsoletas como MD5 o SHA1, o se utilizan funciones hash no criptográficas cuando se necesitan funciones hash criptográficas?
• ¿Se utilizan métodos de relleno criptográfico obsoletos, como PKCS número 1 v1.5?
• ¿Son explotables los mensajes de error criptográficos o la información del canal lateral, por ejemplo, en forma de ataques de oráculo de relleno?
• ¿Se puede degradar o eludir el algoritmo criptográfico?

Consulte las referencias ASVS: Criptografía (V11), Comunicación segura (V12) y Protección de datos (V14).

Recomendaciones

1. Asegúrese de utilizar algoritmos estándar sólidos y adecuados. No cree sus propios algoritmos criptográficos. Utilice únicamente algoritmos públicos aprobados, como AES, criptografía de clave pública RSA y SHA-256, etc.
2. Asegúrese de que las copias de seguridad externas estén cifradas, pero que las claves se administren y respalden por separado.

Cómo prevenir.

Haga lo siguiente, como mínimo, y consulte las referencias:

• Clasifique y etiquete los datos procesados, almacenados o transmitidos por una aplicación. Identifique qué datos son sensibles según las leyes de privacidad, los requisitos regulatorios o las necesidades del negocio.
• Almacene sus claves más confidenciales en un HSM basado en hardware o en la nube.
• Utilice implementaciones confiables de algoritmos criptográficos siempre que sea posible.
• No almacene datos confidenciales innecesariamente. Deséchelos lo antes posible o utilice tokenización o incluso truncamiento conforme a PCI DSS. Los datos que no se conservan no pueden ser robados.
• Asegúrese de cifrar todos los datos confidenciales en reposo.
• Asegúrese de que existan algoritmos, protocolos y claves estándar sólidos y actualizados; utilice una gestión de claves adecuada.
• Cifre todos los datos en tránsito con protocolos seguros como TLS con cifrados de confidencialidad directa (FS), priorización de cifrado por parte del servidor y parámetros seguros. Aplique el cifrado mediante directivas como la Seguridad de Transporte Estricta HTTP (HSTS).
• Desactive el almacenamiento en caché de las respuestas que contienen datos confidenciales. Esto incluye el almacenamiento en caché en su CDN, servidor web y cualquier aplicación (p. ej., Redis).
• Aplicar los controles de seguridad necesarios según la clasificación de los datos.
• No utilice protocolos no cifrados como FTP y SMTP.
• Almacene contraseñas utilizando funciones de hash adaptativas y con sal robustas con un factor de trabajo (factor de retardo), como Argon2, scrypt, bcrypt (sistemas antiguos) o PBKDF2-HMAC-SHA-256. Para sistemas antiguos que utilizan bcrypt, consulte la Hoja de referencia de OWASP: Almacenamiento de contraseñas.
• Los vectores de inicialización deben seleccionarse de forma adecuada para el modo de operación. Esto podría implicar el uso de un CSPRNG (generador de números pseudoaleatorios criptográficamente seguro). Para los modos que requieren un nonce, el vector de inicialización (IV) no necesita un CSPRNG. En ningún caso, el IV debe utilizarse dos veces para una clave fija.
• Utilice siempre cifrado autenticado en lugar de sólo cifrado.
• Las claves deben generarse criptográficamente de forma aleatoria y almacenarse en memoria como matrices de bytes. Si se utiliza una contraseña, esta debe convertirse en una clave mediante una función adecuada de derivación de claves de base de contraseñas.
• Asegúrese de que la aleatoriedad criptográfica se utilice cuando corresponda y de que no se haya generado de forma predecible ni con baja entropía. La mayoría de las API modernas no requieren que el desarrollador genere el CSPRNG para garantizar su seguridad.
• Evite funciones criptográficas obsoletas, métodos de construcción de bloques y esquemas de relleno, como MD5, SHA1, modo de encadenamiento de bloques de cifrado (CBC), PKCS número 1 v1.5.
• Asegúrese de que las configuraciones y ajustes cumplan con los requisitos de seguridad haciendo que sean revisados ​​por especialistas en seguridad, herramientas diseñadas para este propósito o ambos.
• Considere prepararse para la criptografía post cuántica (PQC), consulte las referencias (ENISA, NIST)

Ejemplos de escenarios de ataque.

Escenario n.° 1 : Un sitio web no utiliza ni aplica TLS en todas sus páginas o admite un cifrado débil. Un atacante monitorea el tráfico de red (p. ej., en una red inalámbrica insegura), degrada las conexiones de HTTPS a HTTP, intercepta las solicitudes y roba la cookie de sesión del usuario. Posteriormente, el atacante reproduce esta cookie y secuestra la sesión del usuario (autenticado), accediendo o modificando sus datos privados. En lugar de lo anterior, podría alterar todos los datos transmitidos, por ejemplo, el destinatario de una transferencia de dinero.

Escenario n.° 2 : La base de datos de contraseñas utiliza hashes simples o sin sal para almacenar las contraseñas de todos. Una falla en la carga de archivos permite a un atacante recuperar la base de datos de contraseñas. Todos los hashes sin sal pueden exponerse mediante una tabla arcoíris de hashes precalculados. Los hashes generados por funciones hash simples o rápidas pueden ser descifrados por GPU, incluso si están con sal.

Ejemplos

En una de las aplicaciones bancarias, la base de datos de contraseñas utiliza hashes sin sal * para almacenar las contraseñas de todos. Una falla de inyección SQL permite al atacante recuperar el archivo de contraseñas. Todos los hashes sin sal se pueden extraer por fuerza bruta en poco tiempo, mientras que las contraseñas con sal tardarían miles de años.

(*Hashes sin sal: la sal es un dato aleatorio que se agrega a los datos originales. La sal se agrega a la contraseña antes de aplicar el hash)

ANTERIORMENTE: A02:2021 – Cryptographic Failures Fallos criptográficos

A02 sube al puesto n.º 2. Antes se presentaba como Exposición de datos sensibles, que es más un síntoma que una causa raíz. Aquí el foco está en fallos de criptografía (o su ausencia), que con frecuencia derivan en la exposición de datos. Entre las CWE más relevantes están CWE-259 (uso de contraseñas codificadas), CWE-327 (algoritmo criptográfico inseguro/obsoleto) y CWE-331 (entropía insuficiente).

Una falla criptográfica se refiere a cualquier vulnerabilidad derivada del mal uso (o la falta de uso) de algoritmos criptográficos para proteger información confidencial. Las aplicaciones web requieren criptografía para garantizar la confidencialidad de sus usuarios en diversos niveles. Tomemos, por ejemplo, una aplicación de correo electrónico segura:

• Al acceder a su cuenta de correo electrónico mediante su navegador, querrá asegurarse de que las comunicaciones entre usted y el servidor estén cifradas. De esta forma, cualquier intruso que intente capturar sus paquetes de red no podrá recuperar el contenido de sus direcciones de correo electrónico. Cuando ciframos el tráfico de red entre el cliente y el servidor, solemos denominarlo cifrado de datos en tránsito .
• Dado que sus correos electrónicos se almacenan en un servidor administrado por su proveedor, es conveniente que este no pueda leer los correos de sus clientes. Por ello, sus correos electrónicos también podrían cifrarse al almacenarse en los servidores. Esto se conoce como cifrado de datos en reposo .

Las fallas criptográficas a menudo hacen que las aplicaciones web divulguen accidentalmente datos confidenciales. Estos suelen ser datos directamente vinculados a los clientes (p. ej., nombres, fechas de nacimiento, información financiera), pero también podrían ser información más técnica, como nombres de usuario y contraseñas.

En niveles más complejos, aprovecharse de fallos criptográficos suele implicar técnicas como los «ataques de intermediario», en los que el atacante fuerza las conexiones del usuario a través de un dispositivo que controla. Posteriormente, aprovecha el cifrado débil de los datos transmitidos para acceder a la información interceptada (si es que los datos están cifrados). Por supuesto, muchos ejemplos son mucho más sencillos, y se pueden encontrar vulnerabilidades en aplicaciones web que pueden explotarse sin conocimientos avanzados de redes. De hecho, en algunos casos, los datos sensibles pueden encontrarse directamente en el propio servidor web. La aplicación web de este cuadro contiene una de estas vulnerabilidades. Para continuar, lea el material de apoyo en las siguientes tareas.

El primer paso es definir cómo se protegerán los datos en tránsito y en reposo (p. ej., contraseñas, tarjetas, historiales médicos, PII o secretos comerciales, a menudo sujetos a RGPD, PCI DSS, etc.). Revise especialmente:

• Transporte: ¿hay datos que viajan en claro (HTTP, SMTP, FTP, STARTTLS mal aplicado)? Verifique todo el tráfico, también interno (LB ↔ web ↔ backend).
• Algoritmos/protocolos: ¿se usan por defecto algoritmos o protocolos débiles u obsoletos en código antiguo?
• Gestión de claves: ¿claves por defecto/reutilizadas/débiles? ¿falta rotación? ¿claves expuestas en repositorios?
• Aplicación del cifrado: ¿faltan cabeceras y políticas que lo impongan (p. ej., en navegadores/HTTP)?
• Certificados/TLS: ¿se valida correctamente el certificado y su cadena de confianza?
• IV/nonce y modos: ¿IVs no generados de forma segura, reutilizados o ECB? ¿se usa cifrado autenticado cuando corresponde?
• Derivación de claves: ¿se usan contraseñas como claves sin una KDF adecuada?
• Aleatoriedad: ¿se emplea aleatoriedad no criptográfica o con baja entropía? ¿se sustituyó el seed seguro por uno predecible?
• Hashing: ¿se usan funciones obsoletas (MD5, SHA-1) o no criptográficas donde se requiere hashing criptográfico?
• Relleno: ¿se usan esquemas antiguos como PKCS#1 v1.5?
• Canales laterales/errores: ¿mensajes de error o tiempos permiten ataques de oráculo de padding u otros?

Consulte ASVS V7 (Crypto), V9 (Protección de datos) y V10 (SSL/TLS).

Cómo prevenir

Mínimos imprescindibles (y revise las referencias):

• Clasifique los datos que procesa/almacena/transmite; identifique los sensibles (leyes, regulaciones, negocio).
• No almacene datos sensibles innecesariamente; elímine pronto o use tokenización/truncamiento (PCI DSS).
• Cifre en reposo todo dato sensible.
• Use algoritmos, protocolos y longitudes de clave actualizados, con gestión de claves sólida (ciclo de vida y rotación).
• Cifre en tránsito con TLS (preferencia de cifrados por el servidor, Forward Secrecy, parámetros seguros) y haga cumplir su uso (p. ej., HSTS).
• Deshabilite caché de respuestas con datos sensibles.
• Aplique controles proporcionales a la clasificación de datos.
• Evite protocolos heredados (FTP, SMTP) para datos sensibles.
• Almacene contraseñas con hash adaptativo y sal (con factor de trabajo): Argon2, scrypt, bcrypt o PBKDF2.
• Seleccione IV/nonce adecuados al modo:
  • Genérelos con CSPRNG cuando aplique;
  • En modos con nonce, no necesita CSPRNG, pero nunca reutilice el mismo nonce/IV con la misma clave.
• Prefiera siempre cifrado autenticado (AEAD) en lugar de “solo cifrado”.
• Genere claves con CSPRNG y guárdelas como bytes; si parte de contraseña, derive con una KDF robusta.
• Asegure aleatoriedad criptográfica suficiente (evite seeds de baja entropía); la mayoría de APIs modernas no requieren implementar el CSPRNG manualmente.
• Evite primitivas obsoletas: MD5, SHA-1, PKCS#1 v1.5, etc.
• Verifique de forma independiente (auditoría/pruebas) la eficacia de configuración y hardening.

Ejemplos de escenarios de ataque

Escenario n.º 1

La aplicación cifra tarjetas en la base de datos con cifrado “automático”, pero al leer descifra automáticamente. Una inyección SQL extrae los números en claro.

Escenario n.º 2

El sitio no aplica TLS en todas las páginas o admite cifrados débiles. Un atacante degrada HTTPS a HTTP, roba la cookie de sesión en una Wi-Fi insegura y secuestra la sesión; también podría alterar datos (p. ej., el destinatario de una transferencia).

Escenario n.º 3

La base de datos almacena contraseñas con hash simple o sin sal. Tras una falla de carga de archivos, el atacante obtiene la base y usa tablas arcoíris o GPU para recuperar contraseñas (incluso con sal si el hash es rápido).

Exponer una base de datos en producción: un clásico de los errores criptográficos modernos

A veces no hace falta ni escanear un sistema entero para encontrar oro. Te metés en una web, escarbás un poco y te encontrás con un archivo .db en el root del sitio, como si fuera una imagen más. Lo descargás, lo abrís con sqlite3, y ahí tenés: nombres, tarjetas de crédito, hashes de contraseñas. Todo servido en bandeja. Y no, no es una vulnerabilidad compleja ni una técnica de evasión avanzada: es simplemente dejar datos sensibles al alcance de cualquiera que sepa dónde mirar. Lo más grave es que esto no es un caso aislado. Pasa todo el tiempo. Mucho más de lo que debería.

Las bases de datos en formato archivo plano, como SQLite, son prácticas para desarrollos chicos, pero cuando alguien comete el error de dejarlas en una ruta accesible desde HTTP, ya no hablamos de comodidad: hablamos de una filtración en tiempo real. En este caso puntual, la base estaba disponible para ser descargada directamente, y como buen curioso que soy, la bajé y me puse a revisarla.

Con sqlite3 example.db, entro y consulto las tablas. Me aparece customers. La inspecto con PRAGMA table_info(customers); y me devuelve cuatro columnas: ID, nombre, tarjeta de crédito y contraseña. Ejecuto SELECT * FROM customers; y no puedo evitar reírme: los datos están completos. Joy Paulson, número de tarjeta 4916 9012 2231 7905, y como si fuera poco, un hash MD5 de su contraseña: 5f4dcc3b5aa765d61d8327deb882cf99. Eso es password. Así, sin vueltas. Crackstation lo resuelve en milisegundos.

Y esto no se trata solo de que usaron un hash débil. Se trata de una mentalidad completamente errónea sobre la seguridad. No es que no sabían usar bcrypt o scrypt. Es que ni siquiera se preguntaron si valía la pena proteger esa información. Dejaron todo expuesto como si fuera contenido estático. Este tipo de fallos criptográficos no es un problema del algoritmo, es un problema humano. Mal diseño, malos hábitos y cero conciencia de las consecuencias.

Lo que más me molesta de estos casos es que no hay excusa técnica. MD5 está muerto hace años. Guardar contraseñas sin sal, sin iteraciones, sin una función de derivación de clave robusta, no solo es perezoso: es negligente. Usar SHA-1, lo mismo. Ni hablar de cifrar datos sin autenticación. Y no es solo responsabilidad del desarrollador. Muchas veces estos errores vienen de arriba, de arquitectos que nunca pisaron un entorno real, o de decisiones de negocio que priorizan el delivery sobre la seguridad. Pero cuando explota, el que queda expuesto es el usuario.

Después viene la segunda parte: la gestión de secretos. Porque una cosa es el dato cifrado o hasheado, y otra muy distinta es cómo manejás las claves y los secretos asociados. Hoy en día, con toda la movida DevOps, los secretos están por todos lados: claves de API, tokens, credenciales de bases de datos, llaves SSH, certificados. Y el problema es que siguen apareciendo en texto plano, hardcodeados en código fuente o escondidos en archivos .env que terminan subidos a GitHub por error. No hay HSM ni KMS que te salve si filtrás la clave maestra.

La solución no es mágica. Hay que tener un gestor de secretos centralizado, con control de acceso granular, rotación automática, registros de auditoría y disponibilidad alta. Si estás en Kubernetes, usá sidecars que monten secretos en memoria, no los metas como variables de entorno. Si estás en CI/CD, tratá los secretos como parte de producción: acceso mínimo, trazabilidad, rotación frecuente, y nada de dejarlos tirados en el pipeline. Y si vas a usar GitHub o Jenkins para almacenarlos, que sean secretos chicos y temporales, con permisos justos y bien auditados.

En AWS, Azure o GCP tenés servicios nativos de secretos, y si el riesgo lo amerita, agregá KMS o incluso enclaves de computación confidencial. Pero que no te agarre la manija: BYOK (Bring Your Own Key) te da más control, sí, pero también más responsabilidad. A veces, dejar que el proveedor administre claves es más sensato, si no vas a tener la infraestructura ni los procedimientos para hacerlo bien.

Otro error común es hornear secretos dentro de imágenes de contenedor. Crimen capital. Si usás Docker y dejás credenciales en el Dockerfile, no solo están visibles en el build, sino que van directo al registro. Lo correcto es inyectar secretos en runtime, usar volúmenes en memoria, sidecars efímeros y siempre cifrar el backend del orquestador. Las variables de entorno son el último recurso, no la solución estándar.

También hay que entender la diferencia entre secretos estáticos y dinámicos. Un secreto dinámico es válido solo por minutos: se usa para levantar una sesión, hacer una operación crítica, y después muere. Eso reduce la ventana de ataque. Los estáticos, en cambio, tienen que estar rotando seguido y con controles de acceso extremadamente precisos. Cada acceso tiene que quedar registrado. Y si una credencial está en uso fuera del horario o IP habitual, se dispara una alerta.

Y ojo, porque todo esto está atado al cifrado. Si tenés secretos, los vas a querer cifrar. Pero no sirve cualquier algoritmo. AES-GCM o ChaCha20-Poly1305 son lo mínimo aceptable. Nada de AES en ECB ni cifrado sin autenticación. Si estás en 2025 y seguís usando MD5 o SHA1 para integridad, estás fuera de juego. Y ni se te ocurra guardar la clave de cifrado junto al secreto cifrado. Usá DEK y KEK, separalos físicamente, y rotalos por separado.

Y como broche, el monitoreo. Nada de esto sirve si no sabés quién accedió, cuándo, desde dónde y para qué. El gestor de secretos tiene que darte logs completos, correlacionables con IP, agente y contexto. Los incidentes se resuelven con velocidad y contexto, no con suerte. Y si estás en un entorno multicloud, lo mejor que podés hacer es unificar tu política de gestión de secretos bajo una herramienta como Vault, y no depender del caos de cada proveedor.

En resumen: no expongas tus bases de datos, no uses hashes rotos, y no trates a los secretos como si fueran simples contraseñas. La seguridad no se improvisa. Se diseña. Y si lo hacés mal, te lo van a hacer saber.

C2: Utilice la criptografía para proteger los datos

Los datos sensibles (contraseñas, tarjetas, historiales médicos, PII y secretos comerciales) requieren protección reforzada, especialmente si están sujetos a RGPD, PCI DSS u otras normativas.

Los atacantes pueden robar datos por múltiples vías: tráfico sin cifrar (p. ej., Wi-Fi insegura) o inyección SQL que expone credenciales en bases de datos.

La privacidad exige salvaguardar la confidencialidad y el acceso. La criptografía convierte información legible en ininteligible y garantiza su protección en reposo y en tránsito.

Clasifique los tipos de datos en su aplicación

Defina categorías y niveles de sensibilidad para cada dato enviado, procesado y almacenado, y asígneles reglas de protección acordes.

• Público (p. ej., marketing): puede publicarse sin cifrado.
• Privado/sensible (p. ej., tarjetas de crédito): cifrado en almacenamiento, proceso y tránsito.
  Esta clasificación puede ser obligatoria (p. ej., RGPD). Además, fomente la minimización: no conserve datos sensibles si no es imprescindible.

Amenazas

• Algoritmos/protocolos débiles u obsoletos que permiten descifrado o manipulación.
• Gestión de claves deficiente (claves expuestas, sin rotación, por defecto).
• Extracción por inyección SQL de datos (incluso cifrados) si el sistema los descifra automáticamente.
• Ausencia de gobierno de claves que termina en acceso no autorizado.

Implementación

Reglas esenciales

• Nunca transmita datos en texto plano. Cifre todo el tránsito y proteja datos en reposo.
• No diseñe sus propios protocolos/rutinas criptográficas. Use estándares probados y bibliotecas auditadas.
• Centre la innovación en su producto, no en criptografía casera.

Proteger los datos en reposo

• Evite almacenar datos sensibles; si es inevitable, cifre y aplique controles de integridad.
• La criptografía es compleja y propensa a errores (p. ej., canales laterales). Prefiera soluciones abiertas y revisadas por pares:
  • Google Tink, libsodium, capacidades de almacenamiento seguro de frameworks y servicios cloud.

Almacene las contraseñas de forma segura

• Nunca guarde contraseñas en claro.
• Use hash adaptativo con sal y factor de trabajo: Argon2 (recomendado), scrypt, bcrypt o PBKDF2.
• Aplique políticas de rotación, longitud mínima y gestión de credenciales.

Caso especial: Gestión de secretos de aplicación

Los “secretos” (certificados, contraseñas de BBDD, credenciales de servicios, claves SSH/cifrado, etc.) requieren controles estrictos:

• No los guarde en código, archivos de configuración ni variables de entorno.
• Escanee repositorios con herramientas como GitRob o TruffleHog.
• Utilice bóvedas de secretos/KMS: HashiCorp Vault, Keywhiz, AWS KMS/Secrets Manager, etc.
• Diseñe el sistema para que, aun si el código se filtra, la ejecución permanezca segura.

Ciclo de vida de las claves

• Proteja claves contra accesos no autorizados y registre el acceso legítimo.
• Guárdelas en una bóveda de secretos.
• Use claves distintas por propósito/contexto.
• Diseñe agilidad criptográfica (cambiar algoritmos/tamaños).
• Implemente rotación fluida y procedimientos de revocación (periódica o tras compromiso).

Proteger los datos en tránsito

• Cifre todo el tráfico con TLS extremo a extremo, interno y externo.
• Desactive protocolos heredados para evitar degradación.

Utilice protocolos criptográficos actuales

• Prefiera TLS 1.3 (o TLS 1.2 bien configurado).
• Considere HTTP/2 o HTTP/3 (fuerzan TLS moderno).
• No ofrezca HTTP; fuerce redirección a HTTPS.
• Deshabilite compresión TLS/HTTP (mitiga CRIME/BREACH).
• Use siempre un CSPRNG (generador criptográficamente seguro).

Instruir a los clientes para que apliquen el cifrado a nivel de transporte

• HSTS (Strict-Transport-Security) para forzar HTTPS y validar certificados.
• CSP (upgrade-insecure-requests) para actualizar HTTP→HTTPS en el cliente.
• Cookies con flag Secure (y, de ser posible, HttpOnly y SameSite).

Apoye la agilidad criptográfica: la criptografía cambia con el tiempo

• Mantenga opciones criptográficas configurables (algoritmos, tamaños de clave, suites).
• Para alta disponibilidad, diseñe renovación/rotación de claves sin interrupciones.

Gestión de claves

Esta guía práctica de gestión de claves ofrece a los desarrolladores una orientación clara para implementar, de manera segura, el manejo de claves criptográficas dentro de una aplicación. El objetivo es documentar y armonizar normas y prácticas que abarquen todo el ciclo de vida de las claves —desde su generación y distribución hasta su revocación y destrucción—, así como los procedimientos de respuesta ante compromiso, recuperación y saneamiento. También contempla criterios sólidos para su almacenamiento, los mecanismos de acuerdo de claves y las responsabilidades asociadas al uso y custodia de material criptográfico.

Pautas y consideraciones generales

El punto de partida es definir una estrategia criptográfica organizacional que guíe a los equipos que trabajan en distintas aplicaciones, asegurando que todas cumplan requisitos mínimos y mejores prácticas. Esa estrategia debe traducirse en requisitos concretos de gestión de claves y criptografía para cada sistema, identificando de forma explícita todos los componentes que procesan o almacenan material de clave. Con ese mapa, los desarrolladores sabrán qué capacidades implementar, cómo integrarlas y qué controles de soporte deben operar alrededor (registro, auditoría, segregación de funciones y procesos de cambio).

Selección de claves

La elección de algoritmos y de esquemas de gestión de claves debe responder a los objetivos de seguridad de la aplicación. Si el sistema protege datos en reposo, se priorizarán suites orientadas a confidencialidad y control de acceso sobre almacenes; si transmite y recibe información, se privilegiarán protocolos que garanticen confidencialidad e integridad en tránsito, además de autenticidad extremo a extremo. Es habitual empezar por lo que provee la biblioteca criptográfica disponible, pero el análisis debe ser top-down: primero comprender las metas —confidencialidad de datos en reposo y en tránsito, autenticidad del dispositivo, autenticidad del origen de datos, integridad de mensajes, e incluso la necesidad de derivar otras claves— y, recién después, seleccionar protocolos y algoritmos acordes. A partir de allí, se definen los tipos de claves que respaldarán esos objetivos: simétricas y asimétricas para cifrado, secretos compartidos o anclajes de confianza para autenticación de dispositivos, HMAC o MAC para autenticación e integridad, y claves específicas para encapsular otras claves (KEK) cuando sea necesario.

Algoritmos y protocolos

Siguiendo NIST SP 800-57 Parte 1, muchos esquemas de seguridad apoyan parte de su funcionamiento en funciones hash aprobadas (FIPS 180) que, a su vez, intervienen en firmas digitales (FIPS 186), HMAC (FIPS 198), derivación de claves (SP 800-56 A/B/C y 800-108) y generadores de números aleatorios (SP 800-90A). En términos de clases, se contemplan funciones hash, algoritmos de clave simétrica y algoritmos de clave asimétrica, clasificados por el número de claves que participan. La NSA, a través del Commercial National Security Algorithm Suite 2.0, también sugiere una ruta de algoritmos que se espera mantengan solidez ante avances cuánticos, útil como referencia de futuro.

Funciones hash criptográficas

Las funciones hash no requieren claves y producen un valor compacto difícilmente reversible a partir de entradas potencialmente grandes. En gestión de claves, su papel es transversal: permiten construir códigos de autenticación de mensajes cuando se combinan con secretos (HMAC), comprimen mensajes para firmarlos y verificarlos de manera eficiente, participan en la derivación de material criptográfico y alimentan generadores deterministas de números aleatorios cuando así lo especifica el diseño.

Algoritmos de clave simétrica

Los cifradores simétricos transforman datos de manera que revertir la operación sin la clave correcta resulte inviable. La misma clave se utiliza para cifrar y descifrar, y suele ser compartida por más de una entidad autorizada. Además de proporcionar confidencialidad de datos en reposo o en tránsito, se emplean como base de MAC para asegurar autenticidad e integridad, participan en protocolos de establecimiento de claves y, en algunos diseños, en generadores deterministas de aleatoriedad. Su gestión exige restringir la distribución, rotarlas según políticas y protegerlas durante todo su ciclo de vida.

Algoritmos de clave asimétrica

La criptografía de clave pública utiliza pares de claves relacionadas: una pública y una privada. La primera puede divulgarse abiertamente; la segunda debe permanecer bajo control exclusivo del propietario. Estos algoritmos habilitan firmas digitales —aportando autenticación, integridad y no repudio—, el establecimiento seguro de material de claves y, en ciertos casos de diseño, la generación de números aleatorios. Su fortaleza no solo depende del tamaño de clave sino también de parámetros, curvas y rellenos adecuados.

Códigos de autenticación de mensajes (MAC)

Los MAC proporcionan autenticación e integridad sobre los datos, superando las limitaciones de los códigos de detección de errores no criptográficos que un adversario podría manipular. Cuando emisor y receptor comparten un secreto, el MAC no solo detecta alteraciones sino que también acredita que quien generó el valor poseía la clave. Por ese motivo, son un mecanismo preferente cuando se requiere validar origen y contenido sin incurrir en el costo de esquemas asimétricos.

Firmas digitales

Las firmas digitales, especificadas en FIPS 186, combinan funciones hash con algoritmos asimétricos para ofrecer garantías de autenticación, integridad y no repudio. Se aplican sobre mensajes de longitud arbitraria (dentro de los límites de la función hash) y resultan esenciales cuando múltiples partes necesitan validar la autoría y la invariabilidad de la información sin compartir secretos.

Claves de cifrado de claves

En arquitecturas maduras es frecuente encapsular claves con otras claves. Las llamadas KEK (Key Encryption Keys) protegen DEK (Data Encryption Keys) durante el almacenamiento o la distribución. Esta separación facilita la rotación, la minimización de exposición y el cumplimiento de políticas que exigen usar claves de igual o mayor fortaleza para proteger otras claves.

Punto fuerte clave

La selección de longitudes de clave y parámetros debe alinearse con el nivel de resistencia computacional que demanda la aplicación. Esto implica evaluar la sofisticación del adversario, la duración esperada de la confidencialidad, los entornos de almacenamiento y exposición, y el costo aceptable de las operaciones. NIST SP 800-131A orienta sobre longitudes adecuadas; NIST SP 800-57 (Tabla 2) permite equiparar niveles de seguridad entre algoritmos, útil al migrar hacia curvas elípticas. Como regla, una clave destinada a proteger otras claves debe tener fortaleza igual o superior a la del material que encapsula.

Consideraciones sobre la gestión de la memoria

Las claves residiendo demasiado tiempo en memoria pueden dejar trazas recuperables. Para mitigar, conviene reducir su tiempo en claro, emplear borrado seguro, segmentar componentes que se refresquen con mayor frecuencia y diseñar procesos de recuperación ante fallos en los medios donde se generen, registren o distribuyan claves y certificados. NIST SP 800-57 describe estas prácticas y ayuda a planificar contingencias.

Secreto perfecto hacia adelante

El uso de claves efímeras en los protocolos —por ejemplo, en TLS con suites que negocian ECDHE— habilita confidencialidad directa perfecta: aun si una clave de largo plazo se viera comprometida en el futuro, las sesiones pasadas permanecerán protegidas. La hoja de referencia de TLS detalla cómo seleccionar configuraciones que garanticen PFS en tránsito.

Uso de la clave

De acuerdo con el NIST, cada clave debe tener un propósito único: cifrado, autenticación, encapsulado, generación de aleatoriedad o firma. Compartir una misma clave entre propósitos distintos puede reducir la seguridad efectiva de uno o ambos procesos y amplía el impacto de un eventual compromiso. Además, distintos usos imponen requisitos temporales y de retención diferentes, lo que refuerza la necesidad de separar funciones y políticas.

Temas del módulo criptográfico

NIST SP 800-133 define el módulo criptográfico como el conjunto de hardware, software y/o firmware que implementa funciones de seguridad dentro de límites controlados para proteger claves. Esta noción es clave para evaluar el nivel de garantía del sistema, los controles físicos y lógicos que lo rodean y la validez de certificaciones como FIPS 140-2/3.

Gestión de secretos

La gestión de secretos se volvió ubicua con DevOps: claves de API, credenciales de bases de datos, permisos IAM, llaves SSH, certificados… Demasiadas veces aparecen en texto plano dentro del código, perdidos en archivos de configuración o duplicados en herramientas de despliegue. Por eso, las organizaciones necesitan centralizar cómo almacenan, aprovisionan, auditan, rotan y retiran secretos, reduciendo la exposición y pudiendo atribuir con precisión el origen de una fuga. Esta guía ofrece recomendaciones prácticas para que la gestión de secretos sea consistente y segura, sin frenar la velocidad de entrega.

El primer paso es elegir una tecnología suficientemente robusta y altamente disponible: tanto personas (por ejemplo, acceso de emergencia a una cuenta raíz durante un incidente) como aplicaciones (p. ej., credenciales de base de datos) dependerán de ese servicio. Si el gestor de secretos se cae o responde lento, las aplicaciones se resienten y los equipos pierden capacidad de recuperación. Junto con la disponibilidad, conviene estandarizar y centralizar: distintos equipos (DevOps, marketing, SRE) consumen secretos de maneras diversas; estandarizar la interacción y el ciclo de vida evita “santuarios” opacos. Aun con una única solución central, suele ser necesario proteger su “secreto maestro” en una segunda solución, y documentar claramente para qué existe cada secreto y dónde se encuentra. Si la organización utiliza más de un gestor (por ejemplo, servicios nativos de cada nube y, además, un gestor corporativo), la documentación y los flujos de autoservicio se vuelven obligatorios.

Cualquier diseño debe aplicar privilegios mínimos y controles de acceso granulares. Quien puede leer o actualizar un secreto puede filtrarlo, por lo que los permisos deben ajustarse objeto a objeto y con separación de funciones. Para reducir errores humanos y fugas, automatizar es clave: canalizaciones que creen y roten secretos, secretos dinámicos de corta duración emitidos al inicio de la aplicación, y rotación automática de secretos estáticos cuando no sea viable la emisión dinámica. La rotación puede ser gradual (nuevas claves para escritura y las antiguas para lectura), rápida o programada; lo importante es que sea repetible, observable y con baja tasa de error.

Hay patrones arquitectónicos que facilitan esa automatización. En Kubernetes, un sidecar (por ejemplo, Vault Agent o Conjur Secrets Provider) se autentica con el gestor de secretos mediante la cuenta de servicio del pod, recupera las credenciales y las expone en un volumen en memoria que consume el contenedor principal; puede renovarlas periódicamente para mantenerlas siempre vigentes. En nubes públicas, es común rotar credenciales con funciones sin servidor: en AWS, una Lambda orquestada por Secrets Manager ejecuta pasos de creación, establecimiento, prueba y finalización de la nueva versión; el secreto queda actualizado sin intervención manual y con auditoría completa.

Proteger secretos en memoria añade una capa más en entornos sensibles. No siempre es rentable, pero si el modelo de amenazas incluye volcados de memoria o acceso al proceso, conviene minimizar la ventana de exposición: evitar tipos inmutables (como String en .NET/Java) y preferir buffers/matrices que puedan sobrescribirse, poner a cero la memoria tras el uso y, cuando sea posible, aprovechar cifrado de memoria o aislamiento reforzado. Hay límites prácticos —ataques como Rowhammer/Meltdown/Spectre recuerdan que el sistema operativo no es un blindaje perfecto, y en la nube conviene evaluar opciones de computación confidencial—, pero en C/C++ esta disciplina es factible y, en lenguajes con GC, requiere más cuidado.

La auditoría es esencial: quién pidió un secreto, para qué sistema, si se aprobó o rechazó, cuándo se usó, cuándo expiró, intentos de reutilización, errores de autenticación/autorización y acciones administrativas. El servicio debe operar con sincronización horaria fiable y detectar desalineaciones. Esta trazabilidad también alimenta respuesta a incidentes y cumplimiento.

Los secretos siguen un ciclo de vida claro: creación, rotación, revocación y vencimiento. Deben generarse con aleatoriedad criptográfica, tener privilegios mínimos y transmitirse de manera segura (idealmente por canales autenticados de extremo a extremo o canales secundarios confiables). La rotación periódica limita la ventana útil de credenciales robadas; la periodicidad depende del tipo de secreto (minutos para sesiones efímeras, más largo para hardware), aunque las credenciales de usuario no se rotan “por calendario” sino ante sospecha o evidencia de compromiso (alineado con NIST). La revocación debe ser inmediata y verificable, y la expiración obligatoria cuando el tipo de secreto lo permite; las aplicaciones deben comprobar vigencia antes de usarlo.

Nunca transmitas secretos sin TLS. Hoy no hay excusa: además, el propio gestor puede aprovisionar certificados. A nivel operativo, hay que asumir inactividad y contingencias: programar mantenimientos en ventanas seguras, tener copias de seguridad cifradas y probadas regularmente, y definir un procedimiento de “romper el vidrio” para recuperar servicio si el gestor queda inaccesible. Las credenciales de emergencia deben residir, cifradas y con controles estrictos, en un sistema secundario y someterse a pruebas periódicas.

Las políticas organizacionales ayudan a consolidar prácticas: requisitos mínimos de complejidad, algoritmos aprobados, caducidades y metadatos obligatorios. Precisamente, los metadatos importan para no quedar prisioneros de un proveedor: quién creó/consumió/rotó/eliminó el secreto, cuándo ocurrió, con qué propósito, tipo de secreto y contacto responsable. Sin metadatos, migrar o auditar se vuelve mucho más costoso.

La autenticación sin contraseña (OIDC/OAuth 2.0) reduce superficie al desplazar contraseñas hacia tokens de corta duración emitidos por un IdP, pero entonces la seguridad gira en torno a los tokens portadores: siempre por TLS, almacenamiento seguro (cookies HttpOnly/secure en web, keystores en móvil), validación estricta de firma/issuer/audience y rotación segura de refresh tokens. Es un buen complemento para reducir secretos estáticos en apps de usuario.

En CI/CD, los sistemas de build y despliegue tocan muchos entornos y, a menudo, almacenan secretos. Hay que tratarlos como producción: hardening, parches, monitoreo y controles de acceso mínimos. Evitar que logs filtren secretos, impedir ejecutores “abiertos” y exigir trazabilidad de quién definió o disparó un pipeline. ¿Dónde viven los secretos? Pueden residir como “secrets” en la propia herramienta (GitHub/GitLab/Jenkins), en un gestor dedicado (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Vault/Conjur), o bien cifrarse “como servicio” y enviarse a Git para que el consumidor los descifre en despliegue (por ejemplo, con un sidecar). Si se guardan en la herramienta de CI/CD, que no sean secretos “grandes” ni de largo plazo, con rotación frecuente y visibilidad estrictamente necesaria. Cuando se integran con un gestor, las credenciales que usa el pipeline deben ser de alcance reducido, temporales y atribuibles al solicitante. Una opción más segura es que la aplicación recupere sus propios secretos en tiempo de ejecución; el pipeline solo orquesta cuentas de servicio y despliegue.

En nubes públicas, conviene usar servicios nativos de secretos y, cuando el riesgo lo justifica, apoyarse en KMS/HSM y computación confidencial. AWS Secrets Manager y SSM Parameter Store, GCP Secret Manager y Azure Key Vault cubren lo esencial; AWS Nitro Enclaves, Azure Dedicated HSM y los entornos confidenciales de Google/Azure/AMD SEV o Intel SGX añaden aislamiento y atestación. Respecto al cifrado, hay dos decisiones: lado del servidor (en reposo gestionado por el proveedor) versus lado del cliente (cifrado extremo a extremo hasta el consumidor), y clave del proveedor versus BYOK/CMK. BYOK otorga más control, pero también más complejidad: solo adoptar si el modelo de amenazas lo exige. No olvidar los límites de API: un gestor con cuotas puede ser un cuello de botella o vector de DoS; usar caché de claves de datos y segmentar cargas por cuenta/proyecto reduce el impacto.

Con contenedores y orquestadores, los secretos no deben “hornearse” en imágenes. Es preferible montarlos en volúmenes (idealmente en memoria) o recuperarlos en runtime mediante un sidecar. Las variables de entorno son la peor opción: se filtran fácil por diagnósticos o volcados; si no queda alternativa, que las inyecte el orquestador y no Dockerfile, y asumiendo el riesgo. Los sidecars efímeros que extraen, escriben en volumen compartido y terminan reducen el acoplamiento con el gestor y evitan SDKs en la app. Además, almacenar secretos en el backend del orquestador exige cifrado y una gestión de claves correcta.

La implementación se beneficia de distinguir secretos dinámicos (de corta vida para sesiones, despliegues o integridad en memoria) y estáticos (claves de almacenamiento, TLS PKI, servicios sin roles temporales). En ambos casos es vital imponer limitaciones de acceso simples de entender y extender, y —si no hay control fino— separar ambientes por gestores distintos. La monitorización debe correlacionar quién accedió, desde qué IP y con qué agente; accesos inesperados (por ejemplo, credenciales de CI/CD usadas fuera del rango del runner) disparan alertas y suposición de compromiso. La usabilidad no es opcional: documentación clara, SDKs mantenidos, CLI, plugins para IDE/CI/CD/IaC, flujos de autoservicio y errores que ayuden a autodiagnóstico son lo que evita atajos inseguros.

Como la gestión de secretos está unida al cifrado, elegir algoritmos modernos y autenticados es imprescindible (AES-GCM o ChaCha20-Poly1305); revisar fuentes como keylength.com o el CNSA 2.0 de la NSA para horizontes cuánticos ayuda a planificar. El cifrado convergente —mismo texto plano y clave produce el mismo cifrado— puede detectar reutilización, pero abre vectores de “confirmación” para atacantes; solo considerar si el diseño y los recursos computacionales mitigan el riesgo y siempre con secretos suficientemente largos. Nunca almacenes la clave junto al secreto sin cifrado de sobre: una DEK protegida por una CMK/KEK en un servicio de claves, idealmente con separación física/lógica y rotación independiente. Encryption-as-a-Service (EaaS) simplifica: el proveedor maneja claves y operaciones, y las apps consumen APIs seguras.

Detectar secretos expuestos es tan importante como gestionarlos. Integrar detección desde el “shift-left”: secretos de prueba estándar para reducir falsos positivos, validaciones en el IDE o pre-commit, firmas actualizadas y más de una herramienta cuando sea posible (por ejemplo, Yelp Detect Secrets y otras). Considerar los secretos como superficie en el modelado de amenazas y documentar procesos: quién tiene acceso, cómo se rotan, dependencias que se rompen al rotar, puntos de contacto e impacto de exposición.

La respuesta a incidentes debe priorizar velocidad y contención. Documentar quién avisa, a quién, y qué acciones ejecutar: revocar de inmediato, rotar con procesos automatizados y eliminar rastros en repos y logs (sin destruir la integridad del registro). Los equipos de IR necesitan el historial de uso del secreto (quién, cuándo, última rotación). Centralizar los logs relevantes, probar su fidelidad en ejercicios de equipo morado y establecer alertas efectivas acorta el tiempo de detección.

Por último, en multicloud aparecen retos adicionales: APIs distintas, políticas heterogéneas, rotación dispareja, controles de acceso y auditorías fragmentadas. Una estrategia viable es adoptar un gestor independiente de nube (Vault/Conjur) para estandarizar políticas y automatizar rotaciones, mantener control de acceso preciso por entorno y proveedor, y consolidar la observabilidad en un plano común de logs y métricas. Eso reduce fricción operativa, evita bloqueos de proveedor y mantiene la coherencia de cumplimiento entre plataformas.

En síntesis, gestionar secretos bien es menos una cuestión de “dónde guardo una contraseña” y más un sistema: políticas claras, automatización, controles finos, trazabilidad, usabilidad para desarrolladores y un plan de contingencia ensayado. Con esos cimientos, el riesgo baja sin sacrificar la velocidad de entrega que DevOps exige.

Gestión de Secretos: Cómo evitar que tus claves terminen en Pastebin

No es un secreto que los secretos están en todos lados. Y no lo digo en sentido figurado: hablo literalmente. Claves API, credenciales de base de datos, tokens, llaves SSH, certificados, configuraciones sensibles, todo lo que alguna vez tuvo que estar a salvo… no lo está. Lo peor es que muchos desarrolladores los dejan regados por el código, escondidos en .env, en repos privados que se hacen públicos sin querer o como variables de entorno en entornos que cualquiera puede inspeccionar. Y sí, lo he visto en producción más veces de las que me gustaría admitir.

La gestión de secretos ya no es opcional. Con la explosión de DevOps y la cultura de la automatización, los secretos se volvieron parte crítica del ciclo de vida de una aplicación. Y si no los tratás como tal, vas a tener una filtración. Así de simple. No es “si”, es “cuándo”. Por eso, quiero dejarte un recorrido completo por cómo gestionar secretos de forma seria. Como lo hacemos los que nos rompimos la cabeza en incidentes reales, no los que hacen diagramas bonitos en las conferencias.

Alta disponibilidad o muerte

Cuando el gestor de secretos se cae, tu sistema queda paralizado. Así de crudo. No podés generar credenciales, ni acceder a las bases, ni renovar tokens. En un incidente, eso significa que tu equipo de respuesta está atado de manos. Por eso, cualquier solución que elijas tiene que ser resiliente. Tiene que aguantar carga, caídas, reintentos, y sobre todo, estar siempre lista para responder. Ya sea una app accediendo a una DB, o un operador reestableciendo accesos, la disponibilidad no es negociable.

Centralización sin caos

A veces los equipos usan cada uno su sistema. Marketing con un gestor de contraseñas, desarrollo con los secretos embebidos en GitLab, infraestructura con Vault. Y cuando hay una filtración, nadie sabe de dónde vino. Centralizar no significa imponer una única herramienta, sino unificar cómo se accede, se rota, se audita y se documenta cada secreto. A veces vas a tener varias soluciones, pero tienen que integrarse de forma que puedas tener trazabilidad completa. Y el secreto raíz de cada sistema tiene que estar fuera del alcance de ese mismo sistema. Si tenés un Vault, no podés guardar su master key en él mismo. Sentido común, pero se olvida fácil.

Control de acceso real, no simbólico

No todos deberían tener acceso a todo. Ni siquiera a leer. Cada secreto tiene que estar bajo una política de mínimo privilegio real. Nada de “admin” para todos porque es más rápido. Segmentá por entorno, por rol, por propósito. Y asegurate de auditar cada acceso. Los sistemas tienen que permitir definir accesos por objeto, no solo por rol genérico. Y sí, va a doler armarlo al principio. Pero te ahorrás el infierno cuando algo se compromete.

Automatización o extinción

Si todavía estás rotando secretos a mano, estás pidiendo que alguien lo filtre. Hay que automatizar desde la creación hasta la expiración. Los secretos dinámicos, que se generan al vuelo y expiran solos, son una joya. Con eso reducís la exposición al mínimo. La rotación automática de claves estáticas también tiene que estar en tu playbook. Hay varios modelos: gradual (nuevas para escribir, viejas para leer), programada, forzada ante compromiso. Elegí el que se adapte a tu entorno, pero no lo dejes al olvido.

En Kubernetes, el patrón sidecar funciona como un reloj: el sidecar se conecta al gestor, levanta el secreto, lo mete en memoria y lo expone al contenedor principal. Cuando expira, lo renueva. Vos solo consumís. En la nube, usás funciones sin servidor (Lambda, Azure Functions) que se activan en cada rotación, actualizan el secreto y te olvidás.

La memoria también filtra

Poca gente piensa en esto, pero si un secreto vive mucho tiempo en memoria, también se puede extraer. En ambientes muy sensibles, esto importa. Lenguajes como C o Rust te dejan manipular memoria a bajo nivel y sobrescribirla. En Java o .NET, es más jodido porque usan strings inmutables que quedan dando vueltas en el heap. ¿Solución? Usá arrays de bytes y borrá la memoria después de usarlos. Si podés cifrar en memoria o usar aislamiento por hardware (SGX, SEV, enclaves), mejor todavía. No es para todos los escenarios, pero cuando tenés que elevar la barra, esto hace la diferencia.

Auditarlo todo

Cada vez que alguien toca un secreto, tiene que quedar registro. Quién lo pidió, para qué, si fue aceptado o rechazado, cuándo expiró, si hubo intentos de reuso, fallos de login, rotaciones. Todo. Con timestamp firme y con sincronización horaria. Y no solo los accesos: también los cambios administrativos. Si alguien modifica una política o crea un nuevo acceso, también tiene que quedar logueado. Cuando pasa algo, esos logs son oro puro.

Ciclo de vida: nacer, rotar, revocar, morir

No hay secreto eterno. Todo lo que se crea, se tiene que poder rotar, revocar y caducar. Se crean con entropía real, privilegios mínimos y se entregan por canales seguros. No mandes contraseñas por email, SMS, ni Slack. Usá canales autenticados o multifactor. Y sí, hacelo automático. Si un secreto ya no se necesita o fue comprometido, revocalo. Y siempre definí una expiración. No dejes secretos vivos por tiempo indefinido. Que la app verifique si sigue activo antes de confiar en él.

TLS everywhere

No hay excusa para transmitir secretos sin cifrar. Ninguna. Hoy TLS está en todos lados. Y si tu gestor de secretos no tiene certificados válidos o no valida la conexión, buscá otro.

Plan de recuperación o sos boleta

¿Qué pasa si tu gestor de secretos se cae? ¿Tenés una copia de emergencia de las credenciales root? ¿Están cifradas, rotadas y almacenadas fuera de ese mismo sistema? ¿Alguien las puede recuperar? Si no tenés respuestas claras, tenés un problema. La recuperación de desastres también aplica a los secretos. Y se prueba. No alcanza con tener backups: hay que restaurarlos y verificar que sirven.

Políticas, metadatos y trazabilidad

Cada secreto tiene que tener asociado: quién lo creó, cuándo, para qué, con qué propósito, quién lo usa, a quién contactar si se rompe, tipo de secreto, y cómo se rota. Todo eso son metadatos que te salvan cuando tenés que migrar, analizar o resolver incidentes. Sin eso, estás a ciegas.

Autenticación sin contraseña: menos superficie, más control

OIDC y OAuth2 no eliminan la necesidad de secretos, pero te ayudan a reducirlos. Los tokens portadores que usás tienen que ir por TLS, estar bien firmados y almacenados en lugares seguros (nada de localStorage). Los tokens se validan: firma, emisor, audiencia. Y los refresh tokens también se rotan. Si alguien los roba, tenés que poder detectarlo y actuar.

CI/CD: donde los secretos van a morir (si no lo controlás)

Las herramientas de CI/CD manejan secretos todo el tiempo. Y si no están protegidas, son el primer punto de exfiltración. Tratá tu pipeline como producción. Endurecelo, auditá todo, usá credenciales mínimas, rotá con frecuencia y jamás metas secretos grandes o sensibles en las herramientas mismas. Si vas a usar secretos en GitHub, GitLab o Jenkins, que sean de alcance corto y rotables. Idealmente, que el pipeline orqueste, pero que los secretos los maneje la app.

Gestión de secretos en la nube: cada proveedor, su lío

AWS, GCP, Azure… todos tienen su gestor. Usalos bien, con permisos por secreto, rotación habilitada y controlando el acceso IAM como corresponde. Si usás enclaves como Nitro o Confidential Computing, mejor. Pero no dependas de un solo proveedor. Vault, Conjur y otros te permiten abstraer todo eso y unificar tu estrategia. No quedes preso de la nube.

Contenedores: no hornees secretos, inyectalos

Nunca metas secretos en la imagen. Usá volúmenes en memoria, sidecars que los levanten y contenedores efímeros que los entreguen. Variables de entorno son un mal necesario, pero evitables. Y si usás Kubernetes, cifrá su backend de almacenamiento de secretos. No lo des por seguro solo porque lo maneja el orquestador.

Cifrado serio, no de cartón

Si vas a cifrar, usá AES-GCM o ChaCha20-Poly1305. Nada de ECB, ni de “me inventé mi algoritmo”. Si necesitás cifrado convergente (para deduplicación), sabé que tiene riesgos. Y jamás guardes la clave junto al secreto que cifra. Usá DEK/KEK, y administrá esas claves por separado. Encryption-as-a-Service puede ayudarte si no querés manejar claves vos.

Detección de secretos: más vale prevenir

Usá herramientas como Yelp Detect Secrets, validación en IDE, hooks de Git, pipelines que escaneen código y registros. Documentá qué buscar, cómo reaccionar y quién se encarga. Y cuando encuentres un secreto filtrado, activá el plan de contención: revocar, rotar, borrar y loguear todo.

Multicloud: el infierno de los secretos duplicados

Cada proveedor tiene sus APIs, sus políticas y sus bugs. Si no estandarizás cómo manejás los secretos en todos ellos, vas a fallar. Un gestor independiente como Vault o Conjur te da consistencia, visibilidad y control. Automatizá la rotación, documentá políticas, y auditá accesos en todos lados.

Criptografía para desarrolladores: no la rompas, usala bien

Una de las reglas de oro en seguridad es simple: no escribas tu propia criptografía. Y si podés evitar escribir código criptográfico directamente, mucho mejor. Hoy en día tenemos bibliotecas hechas por criptógrafos reales que conocen todos los detalles oscuros y matices que la mayoría de los desarrolladores no tenemos ni tiempo ni ganas de manejar. Entonces, si vas a hacer cifrado, usá herramientas como Google Tink, libs bien mantenidas, seguras por diseño y que te protegen de los errores más comunes.

Antes de meter una línea de código, entendé esto: la criptografía no sirve de nada si el manejo de claves es deficiente. Podés usar AES-256-GCM con el mejor código, pero si guardás la clave en texto plano o la hardcodeás, estás regalando la seguridad.

Cifrado para almacenamiento

Cuando tenés que cifrar datos en reposo, no se trata solo del algoritmo, sino de cómo gestionás las claves, los nonces, los tags de autenticación y si tu código puede rotar claves sin romper compatibilidad. El stack moderno te da opciones simples: usá algo como Tink.

Tink encapsula todo: el keyset, la rotación, el nonce, el AEAD y la autenticación integrada. En pocas líneas, podés tener cifrado simétrico con AES-GCM, protegido por un keyset bien manejado. No tenés que reinventar el ciclo de vida de la clave ni preocuparte de meter la pata con el padding o la longitud del nonce.

Ahora, si por algún motivo no podés usar Tink y te toca bajar al nivel de JCA/JCE, tené muchísimo cuidado. El código funciona, sí, pero es fácil errarle y dejar un vector abierto. ¿Te olvidaste de rotar la clave? ¿Usaste el mismo nonce dos veces? ¿No validaste el tag? ¿Guardás la clave al lado de los datos cifrados? Ahí tenés cuatro problemas críticos.

Lo mínimo indispensable si vas a usar JCE directamente: usá AES-GCM con nonces únicos por operación, generá claves con KeyGenerator, y jamás repitas IVs. Y no mezcles claves de cifrado con datos que podrían estar en logs o backups.

Cifrado para transmisión

El cifrado en tránsito debería estar resuelto con TLS. Pero cuando necesitás compartir secretos de forma directa entre partes, sin exponer claves simétricas y con control más fino, ahí entran los esquemas híbridos: clave pública para compartir, clave simétrica para cifrar.

Tink de nuevo lo resuelve de forma elegante. Podés generar un par de claves por cada parte (Alice y Bob), y con eso hacer ECDH + AES-GCM sin tener que codificar todo a mano. No necesitás conocer los detalles de cada algoritmo, Tink lo hace bien, por default. Y si algún día hay que cambiar el algoritmo, no tenés que reescribir medio sistema.

Pero si estás en un entorno donde no podés usar Tink, se puede hacer lo mismo a bajo nivel con JCA. El ejemplo clásico: ECDH para derivar un secreto compartido, y AES-GCM para cifrar con ese secreto. Pero ojo, porque todo depende de cómo manejás los nonces, las claves privadas, la rotación y si hacés o no autenticación entre partes.

El código con KeyAgreement y SecretKeySpec puede parecer simple, pero si no validás la clave pública del otro extremo o si no incluís metadatos en el tag de autenticación, podés estar comprometiendo la integridad del mensaje sin darte cuenta. Además, los nonces deben ir siempre separados del ciphertext y nunca generarse a partir del secreto. Y ni hablar de la necesidad de almacenar las claves privadas de forma segura, fuera del código fuente y fuera del repositorio.

Errores comunes (que sigo viendo en 2025)

• Usar ECB “porque funciona”. No, no funciona. Es inseguro desde hace 20 años.
• Usar AES sin autenticación. Si no estás usando algo como AES-GCM o una construcción MAC-then-encrypt bien hecha, podés tener padding oracle attacks o manipulaciones silenciosas.
• Guardar claves en archivos de configuración sin cifrar.
• Repetir IVs porque “nadie va a adivinar”.
• Usar contraseñas como claves de cifrado directamente. Siempre derivá claves con algo como PBKDF2, Argon2 o scrypt.
• No validar la firma de los datos al recibirlos. Cifrado sin autenticación ≠ seguridad.

Consejo de hacker con calle

No te pongas creativo con la criptografía. No es un lugar para experimentar. Escribí código que use librerías probadas, actualizá dependencias, revisá tus pipelines y asegurate de que podés cambiar de algoritmo sin reescribir todo. Usá Tink si podés. Usá JCE con miedo y respeto si no hay alternativa.

Y lo más importante: no importa cuán fuerte sea el cifrado si tus claves están mal gestionadas. Cifrar sin un sistema de gestión de secretos sólido es como poner una puerta blindada con la llave pegada al marco.

La criptografía, bien usada, es una de las herramientas más potentes que tenés para proteger los datos. Pero mal usada, es como andar con una granada sin seguro en el bolsillo. Así que usala con cabeza.

Si llegaste hasta acá, ya entendiste que gestionar secretos no es esconder contraseñas. Es armar un sistema con políticas claras, automatización, trazabilidad, control de accesos y respuesta a incidentes lista para actuar. Es cuidar lo que no puede fallar. Porque cuando lo hace, el daño es invisible… hasta que es demasiado tarde.

Mejores prácticas del ciclo de vida de la gestión de claves

Generación

Las claves deben generarse dentro de módulos criptográficos que, como mínimo, cumplan FIPS 140-2, preferentemente en hardware cuando el riesgo lo justifique. La entropía utilizada ha de provenir del propio módulo, y los generadores de bits aleatorios deben ser apropiados para uso criptográfico.

Distribución

Cuando se transporten claves, debe hacerse por canales seguros y solo hacia módulos compatibles con el nivel de validación requerido. La documentación de NIST SP 800-133 ofrece criterios prácticos para estos procesos, incluyendo el uso de envoltura de claves, autenticación mutua y registro de eventos.

Almacenamiento

Es imprescindible conocer dónde y cómo se almacenan las claves en el sistema —memoria volátil y persistente—, asegurando que nunca residan en texto claro y que permanezcan dentro de bóvedas o servicios criptográficos aislados. Si se exportan para almacenar fuera de línea o en bases de datos, deben viajar encapsuladas con KEK de fortaleza igual o mayor, con integridad protegida (por ejemplo, cifrados autenticados). El código de aplicación no debería manipular claves directamente: en su lugar, debe invocar bibliotecas y APIs de gestión que realicen las operaciones dentro de la bóveda sellada. Para información más detallada, la hoja de referencia de gestión de secretos complementa estas prácticas.

Depósito en garantía y respaldo

La pérdida de claves implica la pérdida definitiva de los datos cifrados. Por eso, el sistema debe incorporar copias de seguridad seguras del material crítico, almacenadas bajo controles y cifrados validados (FIPS 140-2/3) y con acceso restringido. El escrow puede ser útil para investigación o reaprovisionamiento de usuarios, pero nunca debe aplicarse a claves de firma digital. En entornos PKI, parte de este proceso puede delegarse en la CA o en el sistema de gestión de claves, siempre con políticas y APIs bien definidas.

Rendición de cuentas y auditoría

La trazabilidad sobre quién puede ver o usar claves —en claro o cifradas— es un disuasivo y un acelerador de respuesta. Los sistemas maduros registran accesos, uso, cambios de estado y relaciones entre claves (por ejemplo, qué DEK protege qué datos y bajo qué KEK). Además de auditar periódicamente políticas y procedimientos (NIST SP 800-57 Parte 2), es recomendable reevaluar mecanismos de protección a la luz de nuevos ataques o tecnologías, y revisar acciones del personal operador ante eventos inusuales.

Compromiso y recuperación de claves

El compromiso de una clave puede exponer confidencialidad (toda la información cifrada por esa clave), habilitar falsificación de certificados si afecta a una CA, o poner en duda la integridad y procedencia de datos. También puede desviar el uso de una clave hacia propósitos no previstos. Para reducir probabilidad e impacto, deben limitarse las ventanas en que las claves están en claro, evitar que humanos las visualicen, restringirlas a contenedores con protección física, y encapsularlas con controles de integridad de forma que cualquier modificación sea detectable. La confirmación de clave (SP 800-57 Parte 1, 4.2.5.5) ayuda a verificar que se estableció el material correcto. Un sistema robusto mantiene contabilidad de cada acceso a claves privadas o simétricas en claro y emplea marcas de tiempo confiables sobre datos firmados. La destrucción oportuna cuando ya no son necesarias completa el ciclo.

Ante un incidente, un plan de recuperación debe estar previamente documentado: a quién notificar, quién ejecuta acciones, cómo se realiza el cambio de claves, inventario exhaustivo de material y usos, formación del personal, políticas de verificación de revocación y supervisión de las operaciones de recambio. Según la gravedad, puede incluir inspecciones físicas, identificación de datos potencialmente afectados, invalidación de firmas comprometidas y redistribución de material de codificación.

Tiendas de confianza

El almacén de confianza debe protegerse contra la inyección de certificados raíz de terceros mediante controles de acceso por entidad y por aplicación, con mecanismos de integridad sobre los objetos almacenados y prohibición de exportación de claves sin autenticación y autorización adecuadas. Las políticas deben detallar cómo exportar material entre componentes y cómo actualizar el almacén de forma segura, con trazabilidad y aprobación.

Bibliotecas de gestión de claves criptográficas

Por último, la implementación debe apoyarse solo en bibliotecas de cifrado confiables, activamente mantenidas y actualizadas, con validaciones de terceros (p. ej., NIST/FIPS). Esto no solo reduce el riesgo de errores sutiles, sino que facilita el cumplimiento, la portabilidad y la capacidad de respuesta cuando sea necesario rotar algoritmos o parámetros.

Proteger los datos en todas partes

Los datos confidenciales, como contraseñas, números de tarjetas de crédito, registros médicos, información personal y secretos comerciales requieren protección adicional, en particular si esos datos están sujetos a leyes de privacidad (Reglamento General de Protección de Datos de la UE, GDPR), normas de protección de datos financieros como PCI Data Security Standard (PCI DSS) u otras regulaciones.

Los atacantes pueden robar datos de aplicaciones web y de servicios web de diversas maneras. Por ejemplo, si se envía información confidencial por internet sin seguridad de comunicaciones, un atacante en una conexión inalámbrica compartida podría ver y robar los datos de otro usuario. Además, un atacante podría usar la inyección SQL para robar contraseñas y otras credenciales de la base de datos de una aplicación y exponer dicha información al público.

Clasificación de datos

Es fundamental clasificar los datos en su sistema y determinar el nivel de sensibilidad de cada dato. Cada categoría de datos puede asignarse a las reglas de protección necesarias para cada nivel de sensibilidad. Por ejemplo, la información pública de marketing que no es sensible puede clasificarse como datos públicos, cuya publicación en el sitio web público es aceptable. Los números de tarjetas de crédito pueden clasificarse como datos privados del usuario, que podrían requerir cifrado durante su almacenamiento o tránsito.

Cifrado de datos en tránsito

Al transmitir datos confidenciales a través de cualquier red, se debe considerar algún tipo de seguridad de comunicaciones de extremo a extremo (o cifrado en tránsito). TLS es, con diferencia, el protocolo criptográfico más común y con mayor compatibilidad para la seguridad de las comunicaciones. Lo utilizan numerosos tipos de aplicaciones (web, servicios web, móviles) para comunicarse a través de una red de forma segura. TLS debe configurarse correctamente de diversas maneras para garantizar la seguridad de las comunicaciones.

El principal beneficio de la seguridad de la capa de transporte es la protección de los datos de aplicaciones web contra la divulgación y modificación no autorizadas cuando se transmiten entre clientes (navegadores web) y el servidor de aplicaciones web, y entre el servidor de aplicaciones web y el back-end y otros componentes empresariales que no están basados ​​en navegadores.

Cifrado de datos en reposo

La primera regla para la gestión de datos sensibles es evitar almacenarlos siempre que sea posible. Si debe almacenarlos, asegúrese de que estén protegidos criptográficamente para evitar su divulgación y modificación no autorizadas.

La criptografía (o criptografía) es uno de los temas más avanzados de la seguridad de la información, y su comprensión requiere un alto nivel de formación y experiencia. Es difícil acertar, ya que existen numerosos enfoques de cifrado, cada uno con ventajas y desventajas que los arquitectos y desarrolladores de soluciones web deben comprender a fondo. Además, la investigación seria en criptografía suele basarse en matemáticas avanzadas y teoría de números, lo que supone una importante barrera de entrada.

En lugar de crear capacidad criptográfica desde cero, se recomienda enfáticamente utilizar soluciones abiertas y revisadas por pares, como el proyecto Google Tink , Libsodium y la capacidad de almacenamiento seguro incorporada en muchos marcos de software y servicios en la nube.

Aplicación móvil: Almacenamiento local seguro

Las aplicaciones móviles corren un riesgo especial de fuga de datos porque los dispositivos móviles se pierden o son robados con frecuencia y, sin embargo, contienen datos confidenciales.

Como regla general, solo se deben almacenar los datos mínimos necesarios en el dispositivo móvil. Sin embargo, si necesita almacenar datos confidenciales en un dispositivo móvil, estos deben almacenarse en el directorio de almacenamiento de datos específico de cada sistema operativo móvil. En Android, este será el almacén de claves de Android y en iOS, la cadena de llaves de iOS.

Ciclo de vida secreto

Las claves secretas se pueden usar en diversas funciones sensibles. Por ejemplo, se pueden usar para firmar JWT, cifrar tarjetas de crédito, firmar hash, proporcionar diversas formas de autenticación y más. Al gestionar las claves, se deben tener en cuenta diversas precauciones, entre ellas:

• Asegúrese de que cualquier clave secreta esté protegida contra accesos no autorizados
• Almacene las claves en una bóveda de secretos adecuada como se describe en Administración de secretos de aplicaciones
• Utilice claves independientes cuando se requieren varias claves
• Genere soporte para cambiar algoritmos y claves cuando sea necesario
• Desarrollar funciones de aplicación para gestionar una rotación de claves

Tipo de dato secreto

Cuando se utiliza un tipo de dato inmutable, como stringel utilizado para almacenar secretos, estos pueden permanecer en texto plano en la memoria durante mucho tiempo. Incluso si se intenta anular el valor de la cadena, este permanece en la memoria. stringes un tipo inmutable y no se puede modificar. Al modificar una cadena (intentar sobrescribirla), se crea una nueva copia. Esto significa que otra copia del secreto desprotegido permanecerá en la memoria. Además, no hay garantía de cuándo el recolector de elementos no utilizados limpiará el secreto. Esto aumenta la exposición de secretos en texto plano en la memoria.

Si los secretos permanecen desprotegidos en la memoria, pueden divulgarse en el disco o en agregadores de registros externos a través de varios escenarios: registros de fallas del servidor, almacenamiento en caché, serialización o paginación de memoria.

Una forma segura de gestionar secretos es usar el patrón de lectura única . Este patrón de diseño defensivo permite acceder a un valor solo una vez. Tras la primera lectura, el valor se borra de la memoria y no es posible acceder a él posteriormente. Para ver un ejemplo de implementación, consulte esta publicación .

Gestión de secretos de aplicaciones

Las aplicaciones contienen numerosos secretos necesarios para las operaciones de seguridad. Estos incluyen certificados, contraseñas de conexión SQL, credenciales de cuentas de servicio de terceros, contraseñas, claves SSH, claves de cifrado y más. La divulgación o modificación no autorizada de estos secretos podría comprometer por completo el sistema. Al gestionar los secretos de las aplicaciones, tenga en cuenta lo siguiente.

• No guardes secretos en código ni archivos de configuración, ni los pases a través de variables de entorno. Usa herramientas como GitRob o TruffleHog para escanear los repositorios de código en busca de secretos.
• Mantenga las claves y otros secretos de nivel de aplicación en una bóveda de secretos como KeyWhiz o el proyecto Vault de Hashicorp o Amazon KMS para proporcionar almacenamiento seguro y acceso a secretos de nivel de aplicación en tiempo de ejecución.

HTTP Strict Transport Security (HSTS)

HSTS (HTTP Strict Transport Security) es una política de seguridad definida por el servidor a través de un encabezado HTTP:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Cuando un navegador compatible lo recibe, obliga a usar siempre HTTPS para ese dominio durante el tiempo especificado (max-age).

Qué protege

HSTS evita tres ataques principales:

1. Downgrade Attack / SSL Stripping (Moxie Marlinspike, 2009) El atacante intercepta una conexión HTTP y la mantiene sin cifrar, engañando al usuario.
   ➜ HSTS impide esto, forzando HTTPS.
2. Certificados inválidos / MITM con certificado falso HSTS no permite que el usuario “acepte” manualmente un certificado no válido.
   ➜ Si el certificado falla, la conexión simplemente se bloquea.
3. Contenido mixto (HTTP dentro de HTTPS) Si un sitio mezcla recursos HTTP, el navegador los forzará a HTTPS (o los bloqueará).
   ➜ Esto evita fugas de información por canales no cifrados.

Parámetros del encabezado

Directiva	Descripción
max-age	Tiempo en segundos durante el cual el navegador recordará que debe usar HTTPS.
includeSubDomains	Aplica también a todos los subdominios del dominio principal.
preload	Solicita inclusión en la lista HSTS precargada de los navegadores (permanente).

Riesgos y precauciones

• Bloqueo permanente: si habilitás preload, el dominio y sus subdominios quedan bloqueados a HTTPS en todos los navegadores. Si necesitás volver a HTTP, la reversión es compleja.
• Fugas de privacidad: algunos sitios usan HSTS de forma abusiva para fingerprinting de usuarios.
• Configuración parcial (sin includeSubDomains): deja expuestos subdominios donde aún se use HTTP.

Desde el punto de vista del pentester

• Objetivo: comprobar si el encabezado HSTS está presente y correctamente configurado.
• Pruebas típicas:
  • Buscar el encabezado en las respuestas del servidor:
    
    curl -I https://example.com | grep -i strict
  • Ver si includeSubDomains y preload están presentes.
  • Intentar cargar el sitio vía HTTP → debe redirigir automáticamente a HTTPS.
  • Intentar acceder con un certificado inválido → el navegador no debe permitir continuar.
• Herramientas útiles:
  • securityheaders.com
  • Burp Suite (pestaña “Headers”)
  • OWASP ZAP

Buenas prácticas recomendadas

1. Usar max-age de al menos 6 meses o 1 año.
2. Incluir includeSubDomains cuando todo el dominio esté bajo HTTPS.
3. Aplicar preload solo si estás seguro de que nunca volverás a HTTP.
4. Probar primero con un max-age corto (por ejemplo, 86400 = 1 día) antes de hacerlo permanente.

API de seguridad empresarial de OWASP (ESAPI)

ESAPI (API de Seguridad Empresarial de OWASP) es una biblioteca de control de seguridad de aplicaciones web gratuita y de código abierto que facilita a los programadores la creación de aplicaciones de bajo riesgo. Las bibliotecas ESAPI están diseñadas para facilitar la modernización de la seguridad en aplicaciones existentes. Además, sirven como base sólida para nuevos desarrollos.

Teniendo en cuenta las diferencias específicas del idioma, todas las versiones de OWASP ESAPI tienen el mismo diseño básico:

• Existe un conjunto de interfaces de control de seguridad. Estas definen, por ejemplo, los tipos de parámetros que se pasan a los controles de seguridad.
• Existe una implementación de referencia para cada control de seguridad. La lógica no es específica de la organización ni de la aplicación. Un ejemplo: validación de entrada basada en cadenas. (Tenga en cuenta que algunas implementaciones de referencia son simplemente ejemplos para ilustrar cómo implementar una interfaz específica [p. ej., ESAPI para Java org.owasp.esapi.reference.FileBasedAuthenticator], mientras que otras son implementaciones de referencia completas y listas para la empresa [p. ej., org.owasp.esapi.reference.DefaultEncodero org.owasp.esapi.reference.DefaultValidator].)
• Opcionalmente, existen implementaciones propias para cada control de seguridad. Estas clases pueden contener lógica de aplicación, desarrollada por o para su organización. Un ejemplo: autenticación empresarial.

Seguridad de la capa de transporte

Cuando hablamos de seguridad en la capa de transporte, hablamos de TLS. No de SSL, no de palabras lindas, sino de asegurar que lo que viaja por la red no lo vea nadie que no debería. TLS es lo que garantiza que el contenido de las conexiones esté cifrado, que no se pueda modificar en el medio, y que se pueda verificar que el servidor es quien dice ser. Pero, como siempre, todo depende de cómo lo implementes.

La primera cagada común: seguir usando SSL o versiones viejas de TLS. Si tu servidor todavía acepta TLS 1.0 o 1.1, estás pidiendo que te rompan. El mínimo hoy es TLS 1.2, pero lo ideal es ir con TLS 1.3. Y no se trata solo del protocolo, también tenés que controlar los cifrados. Nada de export-grade, nada de RC4, nada de NULL. Solo cifrados fuertes y autenticados, como AES-GCM. Si activás cualquier otra cosa para “compatibilidad”, estás sacrificando seguridad por usuarios que ya deberían haber actualizado su navegador hace 10 años.

Otro punto crítico: los grupos Diffie-Hellman. No es solo usar DHE, es elegir bien los grupos. TLS 1.3 te lo fuerza a hacer bien, pero si estás con 1.2 tenés que asegurarte de usar al menos ffdhe3072 o superior. Nada de grupos de 1024 bits, nada generado al vuelo. Todo fijo, bien configurado y auditado. Apache, NGINX, OpenSSL: todos te permiten hacerlo, no hay excusa.

Desactivar la compresión TLS es obligatorio. CRIME no es nuevo, pero sigue siendo una puerta abierta si la dejás habilitada. Lo mismo con las bibliotecas. Si estás usando OpenSSL o cualquier otra librería vieja, parcheala. Heartbleed fue hace años y todavía hay sistemas con esa porquería abierta al mundo.

Después de configurar, hay que probar. Y no con una conexión en el navegador, sino con herramientas serias. testssl.sh, SSLyze, SSL Labs, OWASP, ImmuniWeb, el observatorio de Mozilla. No hay excusa para no escanear tu servidor y ver qué tan expuesto está.

Sobre certificados: clave privada fuerte (mínimo 2048 bits), algoritmo de firma decente (SHA-256 o mejor), y nada de MD5 o SHA-1. Los certificados tienen que tener el nombre de dominio correcto, bien configurado en el SAN (Subject Alternative Name), y no usar IPs ni nombres internos. Nada de meter wildcard a lo loco. Los comodines son útiles, pero si los usás para todo el dominio, estás multiplicando el riesgo. Una sola fuga y te rompen todos los subdominios.

Let’s Encrypt es más que suficiente para la mayoría. Si tenés un sistema interno, armá tu propia CA y asegurate de que tus sistemas la reconozcan. Y para tener más control, usá registros CAA en DNS para definir qué CA puede emitir certificados para tu dominio. No es mágico, pero ayuda a prevenir emisión no autorizada.

Si usás certificados OV o EV, que sea porque el negocio lo pide, no porque creas que agrega más seguridad. Los navegadores ya ni los muestran diferente, así que si pensás que eso te protege más, estás equivocado.

Ahora bien, todo esto no sirve si después tu sitio carga contenido por HTTP. Nada de mezclar. Si usás HTTPS, TODO debe venir por HTTPS. CSS, JS, APIs, imágenes. Nada puede venir sin cifrar. Marcá todas las cookies como Secure y HttpOnly, y evitá el almacenamiento en caché de datos sensibles con los headers correctos: Cache-Control: no-store, Pragma: no-cache, Expires: 0.

HSTS no es opcional. Es obligatorio. Te asegura que el navegador siempre use HTTPS, incluso después de haber accedido una vez por HTTP. Sin HSTS, cualquier ataque de downgrade puede colarse.

¿Querés ir más allá? Usá TLS mutuo (mTLS). No solo el servidor se autentica, sino también el cliente. ¿Problema? Es más complejo, requiere certificados de cliente, y la mayoría no sabe ni cómo instalarlos. Pero en entornos corporativos o APIs críticas, vale la pena. Eso sí, prepárate para lidiar con proxies rompe-TLS que te pueden cortar el handshake si no está todo bien configurado.

Por último, la fijación de clave pública (PKP) ya no se usa en navegadores, pero sigue teniendo sentido en apps móviles o sistemas cerrados. Si controlás el cliente y el servidor, fijar el fingerprint del certificado agrega una capa más. Pero hacelo bien, porque si te equivocás, te podés bloquear vos solo.

Todo esto no es opcional. Si vas a exponer servicios en internet, asegurá la capa de transporte como corresponde. Una mala configuración de TLS es como poner la alarma de tu casa pero dejar la puerta sin llave. Y te juro que hay muchos esperando encontrar esa puerta.

Protección de la privacidad del usuario

La privacidad no es un feature, es un derecho. Y en esta era donde cada clic se guarda, cada paquete se intercepta y cada sesión se rastrea, proteger a los usuarios es una obligación técnica y ética. Como desarrollador, no podés permitir que tus usuarios queden expuestos por culpa de un mal diseño o una configuración débil. Y si sabés que tu app se va a usar en contextos hostiles —sea por represión política, censura, acoso o simplemente abuso corporativo—, tenés que levantar la vara.

Todo empieza con criptografía fuerte. TLS en tránsito, cifrado en reposo y hash de contraseñas con algoritmos duros como Argon2, bcrypt o scrypt. No alcanza con guardar “hashed passwords”, tenés que entender lo que estás haciendo. Nada de SHA-1 ni de guardar las claves como vienen. Las comunicaciones tienen que ir cifradas, siempre. TLS bien configurado, sin downgrade, sin cifrados rotos, sin compresión, con certificados válidos y claves largas. No te olvides de la parte local: los datos privados se cifran antes de guardarlos, con claves rotadas y control de acceso al nivel del sistema operativo. Lo mismo con tokens y secretos. Nunca en texto plano.

Después tenés que meter HSTS. Y no me refiero a dejar el header ahí tirado. Me refiero a hacerlo bien: max-age largo, preload si podés, y asegurarte de que toda la navegación fuerce HTTPS. Si tu app no lo soporta, que al menos sea una opción para el usuario. No los dejes navegar sin cifrado si se pueden estar jugando la vida.

Otra herramienta que vale oro es la fijación de certificados. Aunque HPKP ya no se usa en navegadores, la idea de que tu cliente confíe solo en un certificado específico o en una clave pública concreta sigue teniendo valor. Sobre todo si estás en entornos donde alguien puede meter una CA falsa por política corporativa o presión estatal. Si tenés control del cliente (como en apps móviles), pinneá los certificados. Es la única forma de asegurarte de que el TLS sea con vos y no con un MITM disfrazado de “inspección”.

Ahora, lo que pocos implementan: modos de pánico. Y esto no es paranoia, es realismo. Hay usuarios que, ante una amenaza física o política, pueden verse obligados a entregar sus credenciales. Si tu sistema no les da una salida para protegerse en esos casos, los dejaste solos. Un modo de pánico puede ser desde una contraseña alternativa que inicia sesión en una versión “falsa” de la cuenta, hasta una que borra datos sensibles o desvía la atención. Y lo más importante: que sea creíble, que no sea rastreable, que no revele que está en modo de pánico. VeraCrypt hace esto con sistemas operativos ocultos. Aprendé de ahí.

Otro punto: invalidación remota de sesiones. Si un usuario pierde su dispositivo o sospecha que le robaron las cookies, debería poder entrar desde otro lugar y cerrar todas las sesiones activas. Es básico. Gmail lo hace desde hace años. ¿Tu app también? Si no, implementalo. No cuesta tanto y puede evitar que alguien tenga acceso prolongado sin que el dueño lo sepa.

Y después está el tema de permitir conexiones desde redes anónimas. Tor, I2P, VPNs. No las bloquees porque “ensucian los logs”. Permitilas porque muchos usuarios las necesitan para sobrevivir en la red. Activistas, periodistas, gente viviendo bajo regímenes autoritarios. Cada vez que bloqueás Tor, estás dejando afuera a alguien que lo necesita más que vos. ¿Querés evitar bots o spam? Filtrá comportamiento, no redes. ¿Tenés problemas con fraude? Mejorá tu detección. Pero no sacrifiques la privacidad de todos por la comodidad de unos pocos.

Relacionado con esto, prevenir la fuga de IPs es clave. ¿Tu app carga imágenes de servidores externos? ¿Los usuarios pueden subir contenido que incluye enlaces a dominios de terceros? ¿Mostrás avatares desde URLs públicas? Entonces tenés una fuga de IP. Y esa IP puede ser usada para geolocalizar, identificar y vigilar usuarios. Solución: proxificá el contenido, bloqueá carga externa por defecto, o dejá que el usuario lo controle. Si lo hacen los clientes de email desde hace años, vos también podés.

Y llegamos al punto que más incomoda: honestidad y transparencia. Si tu app no puede proteger al usuario, decilo. Si estás recolectando logs que podrían ser usados en su contra, advertí. Y Si te llega una orden legal para entregar datos, y no estás legalmente obligado a callarte, notificá. A veces no se puede hacer más, pero al menos se puede ser honesto. Los usuarios tienen derecho a saber a qué se exponen. Sobre todo en partes del mundo donde eso puede costarles la libertad o la vida.

Hoy, más que nunca, ser developer implica entender el contexto donde tu código se ejecuta. Si hacés apps que comunican, que almacenan datos personales, que permiten expresarse, entonces también tenés una responsabilidad. Proteger la privacidad no es optativo, es parte del diseño. Y si sabés cómo hacerlo y no lo hacés, no sos parte de la solución.

almacenamiento de contraseñas y almacenamiento criptográfico

Guardar contraseñas en una base de datos es como dejar dinamita en una caja fuerte: no importa lo robusto del contenedor si no cuidás lo que está adentro con cabeza. Una contraseña es la llave del usuario, y si la protegés mal, un atacante con acceso a tu DB puede barrer con todas las cuentas de tu sistema. No importa cuántos firewalls pongas: si el hash es débil o mal configurado, en el momento en que te extraen la tabla de usuarios ya está todo perdido.

Las contraseñas no se cifran, se hashean. Y hay una diferencia enorme. El hashing es irreversible por definición, mientras que el cifrado puede revertirse si tenés la clave. Si almacenás contraseñas cifradas y te exfiltran la key, regalaste todo. El hashing te da una única posibilidad: verificar. Nada más. Si necesitás recuperar contraseñas en texto plano, el problema es tu arquitectura, no la contraseña.

Usá algoritmos diseñados para eso. Nada de SHA-1, SHA-256, ni MD5, por más que la API te lo permita. Lo que necesitás son algoritmos de hash resistentes a ataques de fuerza bruta y diseñados para ser lentos: Argon2id si podés, scrypt si estás limitado, bcrypt solo si no te queda otra. PBKDF2 es una opción si tenés que cumplir con FIPS, pero sabé que no es el más moderno ni el más lento.

Con Argon2id, configurá al menos 19 MiB de memoria, 2 iteraciones y paralelismo en 1. Si eso no te cierra, scrypt con un costo de CPU/memoria de 2^17, bloque de 1024 bytes y paralelismo 1. Y si estás en un sistema viejo con bcrypt, subí el costo a 10 como mínimo, pero sabé que tenés un límite duro: no acepta contraseñas mayores a 72 bytes. Así que o las truncás, o hacés un pre-hash con HMAC-SHA-384 y base64 antes de meterlas, cuidando no romper el formato y dejarlo vulnerable al «shucking».

Salting es obligatorio. Cada contraseña tiene que tener una sal única y aleatoria. Esto destruye cualquier intento de usar tablas rainbow y fuerza al atacante a romper una por una. Todos los algoritmos modernos (Argon2id, bcrypt, PBKDF2) ya la integran. No hay excusas.

El pepper, en cambio, no viene por defecto. Es una clave secreta que se aplica adicionalmente a todas las contraseñas, compartida entre usuarios pero guardada fuera de la DB, en una vault o HSM. Si alguien te roba la base, sin el pepper no puede calcular el hash final. Idealmente, aplicás HMAC-SHA256 con el pepper después del hashing, o lo usás como input antes del hash. Si te roban el pepper, tenés que invalidar las contraseñas protegidas con él. Por eso el diseño importa.

El factor de trabajo es tu arma de calibración. No pongas un número al azar. Medí el tiempo que tarda en calcular un hash, y tratá de que esté justo por debajo del umbral donde moleste al usuario, pero lo suficientemente alto como para arruinarle el negocio al que ataque con GPUs. Lo ideal es que el login demore entre 200 y 500 ms por intento. Si estás muy por encima, podés sufrir un DoS con muchos intentos de login; si estás por debajo, te van a romper las contraseñas por volumen.

Y no te olvides de subir el factor de trabajo con el tiempo. El hardware mejora, y lo que hoy cuesta romper, mañana será trivial. La forma más limpia de actualizar hashes es cuando el usuario inicia sesión: verificás con el hash viejo, y si pasa, lo rehasheás con la nueva configuración y lo almacenás. También podés expirar hashes viejos y forzar el cambio.

¿Tenés contraseñas almacenadas con SHA-1 o MD5? No tires todo. Podés «encapsular» esos hashes en uno más fuerte: hacés bcrypt(md5(pass)), por ejemplo. No es ideal, pero es un parche útil en migraciones. Lo mejor sigue siendo pedirle al usuario que cambie la contraseña y eliminar los hashes débiles.

Ahora, para los datos confidenciales que sí tienen que recuperarse, no te queda otra que cifrar. Pero el cifrado hay que hacerlo bien. Siempre que puedas, usá AES con al menos 128 bits, y en modo GCM o CCM, que son autenticados. Si no tenés GCM, usá CTR o CBC, pero implementá Encrypt-then-MAC. No uses ECB, a menos que quieras salir en un post de “cómo no cifrar datos”.

Para cifrado asimétrico, preferí ECC con Curve25519. Si usás RSA, 2048 bits como mínimo. Y activá OAEP como relleno. Nunca uses RSA pelado.

El lugar donde cifrás también importa. Podés hacerlo a nivel de aplicación, de base de datos, del sistema de archivos o incluso del hardware (tipo discos con cifrado). Si podés elegir, hacelo lo más cerca posible del código que lo necesita, para tener más control. Pero ojo: si tu amenaza es el robo físico del servidor, el cifrado de disco puede alcanzar. Si es un atacante remoto, necesitás cifrar más arriba en la pila.

Nunca almacenes más datos de los que necesitás. Si podés evitar guardar tarjetas de crédito o documentos, hacelo. Menos superficie, menos problemas. Si los tenés que guardar, usá bóvedas, HSMs o servicios tipo KMS/Azure Vault.

Las claves de cifrado son otro universo. Tenés que generarlas con un CSPRNG, nunca a mano, nunca basadas en contraseñas salvo que uses KDFs bien configuradas. Y las tenés que rotar. Cada cierto tiempo, o cada X GB cifrados, o cuando sospechás que fueron expuestas. La rotación tiene que estar automatizada y planificada desde el inicio.

Separá claves de datos. Si te roban la DB, que no se lleven las claves con ella. Idealmente, la clave de cifrado de datos (DEK) se guarda cifrada con una clave maestra (KEK), y esta última en un sistema aparte. Si necesitás rotar, podés generar una nueva KEK sin tocar la DEK, o al revés.

En entornos donde no tenés KMS ni HSM, al menos respetá lo básico: no metas claves en el código, no las pongas en variables de entorno sin protección, y no las subas a Git. Nunca.

Y por último, los generadores de aleatoriedad. No confíes en Math.random() ni rand() ni variantes baratas. Usá funciones criptográficamente seguras (crypto.randomBytes() en Node.js, SecureRandom en Java, random_bytes() en PHP). Si necesitás UUIDs, que sean v4 y generados con CSPRNG.

La seguridad real está en los detalles. Y si alguna vez te parece exagerado todo esto, recordá que para el atacante es más barato probar millones de hashes en una GPU de alquiler que para vos recuperar la confianza de tus usuarios después de una brecha.

Almacenamiento criptográfico

Idea central

• Datos en reposo ≠ solo cifrado: diseñá desde el modelo de amenazas, minimizá cuánto guardás, y combiná cifrado + control de acceso + gestión de claves.
• Passwords: nunca cifrado reversible. Usá hash de contraseñas con KDF resistente (Argon2id ↑, scrypt, bcrypt, PBKDF2 como último recurso).

Arquitectura (antes de picar código)

1. Modelo de amenazas: ¿Robo físico? ¿Compromiso remoto? ¿Insider?
2. Capas de cifrado (según amenaza):
   • Aplicación (lo más flexible y potente para “field-level encryption”).
   • BD (TDE en SQL Server, MySQL Enterprise TDE, PostgreSQL pgcrypto).
   • FS (BitLocker, LUKS).
   • HW (auto-encrypt SSD/HSM).
3. Gestión de secretos/claves:
   • En cloud, KMS/Vault: AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault.
   • Evitá “.env” y repos; rotación, separación de funciones, auditoría.

 Elección de algoritmos y modos

• Simétrico: AES-GCM (o ChaCha20-Poly1305 en móviles/CPU sin AES). Clave ≥128-bit (ideal 256-bit).
• Asimétrico: ECC (X25519/Curve25519, P-256). Si RSA, ≥2048-bit y OAEP para cifrado.
• Modos:
  • ✅ Autenticados: GCM, CCM (confidencialidad + integridad).
  • ⚠️ Si CTR/CBC, agregá MAC (patrón Encrypt-then-MAC, p. ej. HMAC-SHA-256).
  • 🚫 ECB: no usar.
• Relleno RSA: OAEP (no PKCS#1 v1.5 para cifrado; sí para firmas: PSS).

Minimizar y clasificar datos

• No almacenes si podés tokenizar (ej. PCI DSS → tokenización con PSP).
• Etiquetá datos: Pública / Interna / Sensible / Secreta → aplica políticas por clase.

Aleatoriedad segura (CSPRNG)

Usá CSPRNG para claves, IVs, nonces, tokens. Evitá PRNG “rápidos”.

Lenguaje	Seguro	Inseguro / evitar
Python	secrets, os.urandom(), uuid.uuid4()*	random
Node.js	crypto.randomBytes(), crypto.randomInt(), crypto.randomUUID()	Math.random()
Java	java.security.SecureRandom	Math.random(), java.util.Random
.NET	RandomNumberGenerator.GetBytes() / GetInt32()	System.Random
Go	crypto/rand	math/rand
Ruby	SecureRandom	Random, rand
PHP	random_bytes(), random_int()	mt_rand(), rand(), uniqid()
iOS/macOS	SecRandomCopyBytes	arc4random()**
* uuid4 usa fuente segura pero no reemplaza a un token de sesión robusto.
** Hoy es razonable en Apple, pero Apple recomienda SecRandomCopyBytes.

Gestión de claves (clave del éxito)

• Procesos: generar (CSPRNG), distribuir, rotar, retirar, custodiar, auditar.
• Separación: DEK (data) cifrada con KEK (key-encrypting key).
• Dónde guardar:
  • Preferí HSM/KMS/Vault (centralización, rotación, logging).
  • Si no hay: archivos fuera del repo, permisos mínimos, sin variables de entorno expuestas.
• Rotación:
  • Por compromiso, tiempo (criptoperíodo), volumen cifrado, nueva debilidad.
  • Estrategias: re-encrypt o key-versioning (marcar registros con key_id).

Recetas rápidas

1) Hash seguro de contraseñas

• Argon2id (memoria-duro), o scrypt, o bcrypt (cost alto).
• Parámetros ajustados a tu plataforma (tiempo ~100–250ms por hash en servidor).

Ejemplo (pseudocódigo):

hash = argon2id_hash(password, salt=random(16), memory=256MB, time=3, parallelism=2)
store: {hash, salt, params}

2) Cifrado de campos sensibles (AES-GCM)

• Clave DEK del KMS/Vault o derivada por HKDF de una master key.
• Nonce/IV único (12 bytes) por operación; AAD opcional (ej. metadata).

cipher = AESGCM(key_32)
nonce = CSPRNG(12)
ciphertext = cipher.encrypt(nonce, plaintext, aad)
store: nonce, aad, ciphertext, tag (si no viene embebada)

3) RSA con OAEP (si hay requisito de asimétrico)

cipher = RSAES-OAEP(MGF1=SHA-256, hash=SHA-256)

4) Derivación de claves

• HKDF (KDF simétrica a partir de una master), PBKDF2/scrypt/Argon2 (desde passphrase).

Defensa en profundidad

• Zero-trust sobre parámetros cifrados: autorización y ABAC/RBAC igual aplican.
• Registro seguro (sin volcados de claves/IV/tokens).
• Backups cifrados con otra clave y control de acceso independiente.
• Trazabilidad: quién usa, rota y extrae claves (logs inmutables).

 Errores comunes (y cómo evitarlos)

• ECB / AES-CBC sin MAC → usar GCM/CCM o EtM con HMAC.
• Reusar IV/nonce en GCM/CTR → rompe seguridad. Generá IV único por mensaje.
• Claves hardcodeadas / en repos → Vault/KMS + inyección segura en runtime.
• Confundir “cifrar” con “hashear” para contraseñas → Argon2id/scrypt/bcrypt.
• Tokens con Math.random() → CSPRNG.
• Sin plan de rotación → definí criptoperíodos y tooling desde el día 0.

 En la nube (atajos que suman)

• AWS: KMS + Secrets Manager, S3 SSE-KMS, RDS/TDE, EBS encryption.
• Azure: Key Vault + Managed HSM, Storage Service Encryption, SQL TDE.
• GCP: Cloud KMS + Secret Manager, CMEK/CSEK, CMEK para BigQuery/CloudSQL.

Checklist express (para pegar en el repo)

1. Modelo de amenazas documentado.
2. Datos clasificados y minimizados (¿podemos tokenizar?).
3. AES-GCM / ChaCha20-Poly1305 para datos; RSA-OAEP/ECC para intercambio.
4. KDF: Argon2id/scrypt/bcrypt (passwords); HKDF (derivaciones internas).
5. CSPRNG para claves/IV/tokens.
6. Keystores: KMS/Vault/HSM; separación DEK/KEK; rotación definida.
7. Backups cifrados con clave separada.
8. Logs/auditoría de uso de claves.
9. Pruebas: no-reuse IV, autenticidad, fallos de desencriptado, timing.
10. Plan de rotación/clave comprometida y playbooks.

Mejores prácticas de implementación de SSL y TLS

Cuando hablamos de implementar TLS en serio, lo primero que hay que tener en claro es que no alcanza con que funcione. Cifrar no es igual a estar seguro. La diferencia entre una implementación robusta y una chapucera puede ser la puerta abierta que un atacante estaba esperando. Esto no se trata de activar HTTPS y seguir con tu vida. Se trata de entender qué estás protegiendo, contra quién, y cómo se rompe si lo hacés mal.

Todo arranca con la clave privada. Es el corazón del servidor. Si la pierden, te pueden suplantar. Por eso, 2048 bits RSA como mínimo. Si te interesa rendimiento y seguridad más moderna, usá ECDSA con claves de 256 bits. ¿Compatibilidad? ECDSA funciona con todos los navegadores decentes. Y si querés cubrir todos los frentes, podés tener doble stack: RSA y ECDSA al mismo tiempo. Sí, es más trabajo, pero también es más seguridad.

Nunca uses claves generadas por la CA. Generá vos mismo las claves, en un entorno con buena entropía, sin depender de herramientas web dudosas. Protegelas con contraseña si van a backup, y si tenés la infraestructura, metelas en un HSM. Y por favor, no seas de esos que nunca renuevan certificados. Automatizá la renovación cada 3 meses y cambiá también la clave privada. Más rotación, menos exposición. Si no lo hacés por seguridad, hacelo por respeto a tus usuarios.

El certificado tiene que cubrir todos los nombres posibles del sitio. No alcanza con que funcione para ejemplo.com y después te olvides de www.ejemplo.com. Evitá usar wildcard si eso implica que media empresa va a tener acceso a la misma clave privada. ¿Querés facilitar el control? Usá Subject Alternative Names y emití certificados separados si tenés múltiples apps.

La CA que elijas importa. No todas son iguales. No todas responden igual ante un incidente. Fijate su historial de errores, cómo manejan las revocaciones y si ofrecen OCSP y CRL que realmente funcionen. Y usá registros DNS CAA: limitá qué CA puede emitir para tu dominio. Es fácil de implementar y reduce la posibilidad de que alguien emita un certificado trucho.

Después tenés que ponerte serio con la configuración del servidor. No alcanza con que levante TLS. Tiene que hacerlo con las versiones correctas. Nada de SSL 2.0, 3.0, TLS 1.0 ni 1.1. Ya está, están muertos. Usá solo TLS 1.2 y 1.3. Lo demás es invitar al FREAK, DROWN, POODLE o algún otro fantasma del pasado.

Los cifrados son clave. Nada de suites que incluyan RC4, 3DES, RSA sin forward secrecy o cualquier cosa con NULL, ADH o EXPORT. Preferí AES-GCM, CHACHA20, ECDHE y todo lo que te dé AEAD y PFS. Si estás en TLS 1.3, la cosa es más limpia porque ya no tenés tanto para elegir: está bien diseñado desde el vamos.

Forzá que el servidor elija la suite de cifrado. No dejes que el cliente imponga lo que quiere. Ordená las suites con sentido y testeá cómo responde tu stack con clientes viejos. A veces, tener compatibilidad con todo es abrirle la puerta a lo inseguro.

Hablando de forward secrecy, si no tenés ECDHE o DHE, no lo tenés. RSA como intercambio de clave no sirve más. Logjam te recuerda que si usás grupos DH de 1024 bits o menos, estás al horno. Usá mínimo 2048 bits para DHE, o directamente ECDHE con curvas como secp256r1. Y evitá grupos comunes o predecibles. Lo ideal es que uses configuraciones modernas que ya vengan seguras por defecto. Pero no lo asumas, revisalo.

TLS también tiene impacto en performance. Acá no se trata de apretar todo a 4096 bits y sentirse seguro. Si te pasás, tu servidor va a sufrir. No hay necesidad de usar cifrado más fuerte que AES-128. No hay beneficios prácticos. Reutilizá sesiones TLS con Session Tickets o IDs. Usá HTTP/2 para reducir latencia y meté OCSP stapling para que la revocación no dependa del cliente. Todo eso suma en tiempo real.

Ahora, la parte que casi nadie hace: cifrar todo. Nada de tener el sitio en HTTPS pero cargar el logo por HTTP. Ni hablar de JS o CSS. Una sola carga mixta y chau seguridad. Implementá HSTS y hacelo bien: max-age=31536000; includeSubDomains; preload. Forzá HTTPS desde el primer byte. Y si podés, meté el dominio en la lista de preload.

La CSP también suma, sobre todo si usás terceros. Una buena política evita que se cuele código donde no debe. Combiná eso con integridad de subrecursos (SRI) para asegurar que los archivos de terceros no hayan sido modificados.

Las cookies tienen que estar marcadas como Secure y HttpOnly, y si usás SameSite, mucho mejor. Cualquier cookie no protegida es una invitación al robo de sesión.

¿Compresión? La TLS está prohibida. CRIME y BREACH no son cosas del pasado si vos seguís con malas prácticas. La HTTP tampoco es inocente. Si tenés respuestas sensibles que se comprimen, podés quedar expuesto. Mitigalo como corresponde.

Y por último, validá todo. No toques nada sin correr SSL Labs, testssl.sh, o lo que uses. Revisá tu servidor con cada cambio, parcheo o migración. TLS no es una cosa que configurás una vez y te olvidás. Es una responsabilidad constante.

TLS no es “una capa más” del stack. Es la última frontera entre tus datos y el atacante.

Las comunicaciones hoy no pueden confiar en la infraestructura. Internet está lleno de ojos. Proxies transparentes, ISPs curiosos, middleboxes, atacantes man-in-the-middle… si tu aplicación no usa cifrado extremo a extremo, estás dejando todo servido para que lo intercepten, lo manipulen o lo inyecten. Pero usar TLS “porque hay que usarlo” no alcanza. Hay que usarlo bien. Porque si lo configurás mal, es como poner una cerradura de juguete en una puerta de acero.

El requisito base es claro: todo tiene que estar cifrado con TLS fuerte, sin excepción.

No importa si los datos son sensibles o no. No importa si es una conexión interna o a un microservicio vecino. No importa si es “solo una base de datos en el mismo datacenter”. Hoy, cualquier cosa que no esté cifrada es un riesgo. Si un atacante se mete entre el cliente y el backend, o entre dos servicios, y puede leer o modificar lo que se transmite, ya perdiste.

Pero no es solo usar TLS. Es usar TLS bien. Lo primero: TLS 1.2 o superior. Punto. Todo lo anterior (SSL, TLS 1.0, 1.1) es obsoleto y peligroso. Hoy, la mayoría de los navegadores y motores modernos directamente rechazan conexiones inseguras, así que ni siquiera tenés que pensar mucho: si usás algo viejo, simplemente deja de funcionar.

Cada versión vieja que dejás habilitada, cada suite de cifrado débil que no desactivás, es una ventana que le estás dejando al atacante. Protocolos como SSLv2, SSLv3, y algoritmos como RC4, 3DES, export-grade o NULL cipher tienen más agujeros que queso suizo. Y sin embargo, todavía hoy se ven servicios que los siguen aceptando por «compatibilidad». No existe compatibilidad que justifique comprometer tu seguridad.

¿Cómo se verifica eso?

No a mano. Usá herramientas automáticas. sslyze, testssl.sh, openssl s_client, escáneres de TLS que te digan qué protocolos están habilitados, qué cifrados están activos, y si estás usando configuraciones inseguras. Lo que no se mide, no se controla. Y lo que no se escanea, ya está roto y no lo sabés.

Además, no alcanza con que la conexión «funcione». Tiene que estar correctamente configurada. El servidor tiene que priorizar los algoritmos más fuertes, definir un orden preferido claro, y asegurar que lo que negocia el cliente no baje el nivel de seguridad. Si tu server acepta lo que sea, incluso si configuraste bien el top de la lista, estás igual de expuesto.

Ahora hablemos del otro lado de la historia: el servidor y su comunicación interna. Porque no es solo HTTPS hacia el frontend. ¿Y las conexiones entre microservicios? ¿La base de datos? ¿El acceso remoto al backend? ¿Las APIs internas? ¿Los dashboards de monitoreo? Todo eso también tiene que ir cifrado. Y no con cualquier certificado.

 

Los certificados tienen que ser confiables.

Si usás CA interna, asegurate de que la aplicación está configurada para confiar solo en esas CAs. Nada de “aceptar cualquier autofirmado” porque es más fácil. Eso es abrirle la puerta a cualquier atacante con Wireshark y OpenSSL. Y si usás certificados autofirmados, tienen que estar bien controlados, con verificación estricta. De lo contrario, no tiene sentido ni usar TLS.

Además, el backend tiene que validar y autenticar cada conexión. No alcanza con que esté cifrada. Si no sabés quién está del otro lado, estás en las mismas. Autenticá. Usá mutual TLS si podés. Y habilitá la validación de revocación de certificados (OCSP o CRL), sobre todo en entornos donde podés revocar acceso por compromiso o cambio de permisos. No te sirve tener un sistema que sigue aceptando certificados revocados porque no se molestó en verificar.

Y un detalle clave que muchos olvidan: registrá los errores TLS. Cada intento de conexión fallida, cada handshake rechazado, es señal de que alguien intentó entrar con parámetros viejos, con certificados malos, o directamente que alguien está haciendo un escaneo activo. Esas fallas son tu primer línea de alerta. Si no las logueás, ni siquiera sabés que están pasando.

OWASP lo resume bien en la sección V9: no alcanza con usar TLS, hay que hacerlo bien, con las versiones correctas, los cifrados sólidos, la revocación habilitada, y monitoreo de fallos. Y eso se aplica a todo: clientes, servidores, APIs, bases de datos, y conexiones internas.

Lo que veo en producción es que muchas organizaciones fallan no por no usar TLS, sino por no mantenerlo actualizado. Lo dejan como estaba, y cinco años después tenés un sistema usando TLS 1.0 con RC4, con certificados expirados, sin revocación, y sin logs. ¿La excusa? “Nadie lo tocó porque funcionaba”. Hasta que deja de funcionar, o peor, se convierte en una brecha.

Hay guías como la de Mozilla (“Server Side TLS”) que te dan configuraciones seguras predefinidas. Usalas. No reinventes la rueda. Y hacé escaneos regulares. Agendalos. Convertilo en parte del pipeline. Porque la seguridad no es un estado, es un proceso.

Y como siempre digo: si no estás seguro de qué configuraste, lo más probable es que estés vulnerable.

Referencia de Pinning de OWASP

Qué es el Pinning?

La fijación (pinning) consiste en atar una aplicación o servicio a un certificado o clave pública específicos. Cuando el cliente (por ejemplo, una app móvil) se conecta a un servidor, no solo verifica la validez del certificado mediante la cadena de confianza tradicional, sino que además comprueba que el certificado o clave coincida con los que tiene “anclados” (pinned). En otras palabras: El pinning agrega una segunda capa de verificación sobre TLS, asegurando que la aplicación solo confíe en certificados conocidos y esperados, incluso si una autoridad de certificación (CA) legítima emite un certificado falso.

¿Qué problema intenta resolver?

TLS por sí solo confía en cualquier CA raíz del sistema. Si una CA se ve comprometida o emite un certificado malicioso (como en los casos de DigiNotar o Comodo), un atacante podría ejecutar un ataque Man-in-the-Middle (MITM) válido desde el punto de vista del navegador. El pinning busca reducir esa superficie de ataque:

• Evita certificados falsos emitidos por CAs comprometidas.
• Impide la inyección de CAs maliciosas en el almacén de confianza del cliente.

Tipos de pinning

Tipo	Qué se fija	Ventajas	Desventajas
Certificado (Leaf)	Se compara el certificado del servidor con uno precargado.	Fácil de implementar.	Requiere actualizar la app cada vez que el certificado cambia.
Clave pública (SPKI)	Se extrae y compara la clave pública.	Más flexible, no depende de la expiración del certificado.	Más compleja de implementar, requiere extracción.
Hash (digest)	Se guarda un hash del certificado o clave.	Ligero y rápido.	No se tiene contexto criptográfico (algoritmo, OID, etc.).

En general, se recomienda fijar la clave pública (subjectPublicKeyInfo), porque ofrece equilibrio entre seguridad y flexibilidad.

Cuándo NO usar pinning

El propio documento OWASP es muy claro:

“Prácticamente no hay ninguna situación en la que se deba considerar la fijación.”

Razones:

• Riesgo alto de romper la app si cambia el certificado.
• Dificultad para actualizar los pines de forma segura.
• Incompatibilidad con proxies corporativos, firewalls o sistemas DLP que inspeccionan TLS.
• No es adecuado para aplicaciones web (solo móviles o clientes nativos con control total).

En resumen: Pinning es útil pero frágil. Una mala gestión de certificados puede bloquear completamente el acceso de los usuarios.

Implementaciones por plataforma

Plataforma	Método recomendado	Comentario
Android	network_security_config.xml con <pin-set>	Nativo desde Android N. Evita hacerlo por código (riesgo de error).
iOS/macOS	Configuración en Info.plist o uso de TrustKit	TrustKit simplifica la gestión y validación del pinning.
.NET	A través de ServicePointManager	OWASP MSTG incluye ejemplos.
OpenSSL	Validación manual con verify_callback o SSL_get_peer_certificate	Complejo, pero totalmente controlable.
Electron	Usar la librería electron-ssl-pinning	Implementación sencilla para apps de escritorio.

Diferencia entre HSTS y Pinning

Característica	HSTS	Pinning
Capa	HTTP / navegador	TLS / aplicación
Alcance	Fuerza uso de HTTPS	Verifica que el certificado sea el esperado
Aplicación	Web (servidores y navegadores)	Aplicaciones nativas o controladas
Riesgo	Bajo (solo redirección HTTPS)	Alto (puede bloquear toda comunicación)
Persistencia	Temporal (definida por max-age)	Requiere actualización o recompilación
Control	Servidor (cabecera HTTP)	Cliente (código o configuración local)

En resumen:

• HSTS = fuerza HTTPS.
• Pinning = fuerza la identidad del servidor.

Buenas prácticas si decides usar pinning

1. 🔁 Incluí pines de respaldo (backup pins).
   → Evita bloqueos cuando el certificado principal caduque o cambie.
2. ⚙️ Mantené un mecanismo de actualización de pines.
   → Puede ser por API segura o actualización forzada de la app.
3. 🧩 Preferí fijar claves públicas y no certificados.
4. 🧪 Testeá en entornos de staging antes de aplicar en producción.
5. 🚫 No uses pinning en aplicaciones web ni APIs públicas sin control total.

El NIST publicó los primeros estándares de cifrado postcuántico.

Después de 8 años de trabajo, el NIST cerró la primera fase del proceso de estandarización de criptografía resistente a computadoras cuánticas (PQC). Los algoritmos seleccionados están diseñados para reemplazar a los actuales sistemas de cifrado asimétrico (como RSA y ECC), que una computadora cuántica suficientemente poderosa podría romper sin mucho esfuerzo. El cambio no es opcional. Es inevitable.

¿Qué se publicó?

Los tres primeros estándares finales:

• FIPS 203 – ML-KEM (basado en CRYSTALS-Kyber): cifrado general / intercambio de claves.
• FIPS 204 – ML-DSA (basado en CRYSTALS-Dilithium): firma digital principal.
• FIPS 205 – SLH-DSA (basado en SPHINCS+): firma digital alternativa basada en hash, sin estado.

En camino: FIPS 206 – FN-DSA (basado en FALCON): se espera para 2024, será otra opción de firma digital, pero más eficiente (usa transformadas de Fourier). Todos estos estándares ya vienen con código, documentación y detalles listos para implementación. No es teoría. Es producción.

La computación cuántica no es hype: es una amenaza real. Cuando alguien consiga un computador cuántico suficientemente potente, los sistemas actuales de cifrado asimétrico colapsan. No sabemos si será en 5, 10 o 15 años, pero cuando pase, todo el tráfico interceptado durante años podrá ser descifrado si no usaste cifrado resistente. Este modelo se llama harvest now, decrypt later.

¿Qué cubren los nuevos algoritmos?

• Cifrado general: para proteger datos en tránsito.
• Firmas digitales: para autenticación, integridad y no repudio.
• Fueron seleccionados por su seguridad, eficiencia, tamaño de clave y compatibilidad con distintos escenarios de uso.

Los algoritmos están basados en matemáticas que no se ven afectadas por los algoritmos cuánticos actuales (Shor/Grover). No usan factorización ni logaritmos discretos. En su lugar: retículas, hash, códigos, etc.

La UE ya publicó una hoja de ruta oficial para la migración a criptografía postcuántica. No es solo una sugerencia, es una directiva estratégica que apunta a que todos los Estados miembros comiencen una transición sincronizada, con fechas claras y acciones coordinadas. Este no es solo un tema para bancos o gobiernos. Cualquier organización que quiera seguir protegiendo datos a largo plazo tiene que adaptarse. El NIST lo dijo claro: no esperes a que aparezca el ataque. La transición lleva tiempo y deberías empezar ayer.

A04:2025 – Fallos Criptográficos (Cryptographic Failures)

Antes llamado “Sensitive Data Exposure”.

En 2025 baja al puesto #4, pero sigue siendo una de las categorías con mayor impacto real, especialmente por fugas de claves, algoritmos débiles, entropía insuficiente y errores en TLS o almacenamiento.

Abarca todo error donde la criptografía se usa mal, no se usa, se configura incorrectamente o se implementa de forma insegura.

🧩 Ejemplos típicos modernos (2025)

• Uso de algoritmos débiles: MD5, SHA1, DES, RC4, RSA < 2048.
• Tokens JWT sin firma, con alg=none, o usando HS256 con claves débiles.
• Insuficiente entropía en generadores de tokens o reset links.
• Claves criptográficas en código fuente o .env.
• TLS mal configurado: TLS 1.0/1.1, curvas inseguras, cipher suites débiles.
• Falta de encriptación en reposo en bases de datos o buckets.
• Contraseñas almacenadas con hashing débil (MD5, SHA1, bcrypt con cost bajo).
• Reutilización de IV o nonces incorrectos.
• PRNG no criptográfico (Math.random, pseudo-randoms de librerías).
• Exposición de claves privadas en repos públicos.
• Envío de datos sensibles sin TLS (o downgrades permitidos).
• Certificados caducados o autofirmados sin validación estricta.

🔍 Mini-guía de explotación (pentesting 2025)

1. Enumerar algoritmos usados en hashing, cifrado y TLS.
2. Probar fuerza bruta sobre hashes débiles (MD5, SHA1).
3. Revisar configuraciones TLS: versiones, cipher suites, curva elíptica.
4. Inspeccionar JWTs con jwt.io → verificar firma, algoritmo y kid.
5. Buscar claves expuestas en:
   • repositorios
   • archivos .env
   • frontends o móviles
   • responses de API
6. Evaluar entropía de tokens de sesión o reset de contraseña.
7. Analizar storage para verificar cifrado en reposo.
8. Intentar downgrade TLS si soporta versiones viejas.
9. Intentar manipular nonces, IV o padding.
10. Verificar uso de PRNG inseguro (Math.random, Random() sin seed seguro).

🎯 Consecuencias

• Robo de cuentas.
• Toma de sesión mediante predicción de tokens.
• Lectura de datos cifrados por implementación insegura.
• Suplantación de usuario mediante JWT inválidos o falsificados.
• Intercepción MITM por TLS débil o downgrade.
• Compromiso de API keys o claves privadas → hack total.
• Exposición masiva de PII, tarjetas, credenciales.
• Firmas digitales falsificadas por claves insuficientes.

🛡 Defensas modernas (2025)

• TLS 1.2+ obligatorio, preferible TLS 1.3.
• Cifrado fuerte:
  • AES-256-GCM
  • RSA >= 3072 bits
  • ECDSA/ECDH con curvas modernas (secp256r1, X25519)
• Hashing de contraseñas:
  • Argon2id (ideal)
  • bcrypt con cost alto (>= 12)
  • PBKDF2 con suficientes iteraciones
• Encriptación en reposo en DB, S3, logs y backups.
• Validación estricta de certificados (no permitir autofirmados).
• JWT con RS256/ES256, nunca HS256 con clave débil.
• Rotación automática de claves (cada 60–90 días).
• PRNG criptográfico (CSPRNG): /dev/urandom, crypto.randomBytes.
• No exponer claves: usar vaults (AWS KMS, GCP KMS, Hashicorp Vault).
• Evitar cifrado casero (“homebrew crypto”).
• Revisiones y pruebas automáticas de criptografía en CI/CD.

📚 Subtipos / patrones modernos (2025)

(siguiendo tu mismo formato tabular)

Subtipo / patrón	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
Algoritmos débiles	Criptografía obsoleta	SHA1 en firma de token	Verificar algoritmos	Colisión MD5/SHA1	Falsificación	AES-GCM/ECDSA	“MD5/SHA1 = inseguro”
Hashing débil	Contraseñas mal protegidas	MD5 con salt fijo	Revisar almacenamiento	Cracking rápido	Robo de cuentas	Argon2/bcrypt	Buscar “hash débil”
JWT inseguro	alg=none, HS256 débil	Token sin firma	Decodificar y verificar firma	Forjar token admin	Escalada total	RS256/ES256	“alg=none” = crítico
Entropía insuficiente	Tokens predecibles	Reset links cortos	Medir entropía	Predecir token	Robo cuenta	CSPRNG	Si tokens cortos = fallo
Claves expuestas	Secretos en código/db	API keys en .env público	Buscar en repos	Usar clave expuesta	Compromiso APIs	KMS/Vault	“API key pública”
TLS débil	Versiones viejas, malos ciphers	TLS 1.0 activo	Inspección SSL	MITM/downgrade	Intercepción	TLS1.3	“TLS viejo = vulnerabilidad”
Falta de cifrado en reposo	Datos plaintext	DB de tarjetas sin cifrar	Revisar storage	Acceso directo a DB	Fuga masiva	AES256 en reposo	Preguntas sobre “at rest”
PRNG no seguro	Random no criptográfico	Math.random()	Revisar código	Predecir tokens	Toma sesión	crypto RNG	“Random malo = inseguro”
IV/Nonce incorrecto	Reutilización de IV	GCM con IV repetido	Revisar implementación	Decrifrado	Acceso datos	GCM con IV aleatorio	Keywords: «nonce reuse»
Certificados inválidos	Autofirmados o vencidos	Cert caducado en banca	Revisar chain	MITM	Robo tráfico	Validación estricta	“Cert autofirmado” red flag

🧪 Checklist rápida de pentesting A04:2025

• Revisar configuración de TLS.
• Decodificar JWTs y verificar firma/algoritmo.
• Buscar claves privadas en repositorios.
• Revisar hashing de contraseñas.
• Analizar entropía de tokens.
• Verificar cifrado en reposo en DB/storage.
• Buscar uso de MD5/SHA1/RC4.
• Revisar PRNG (si es criptográfico o no).
• Revisar certificados y fechas de expiración.
• Revisar IV/nonce usage.
• Auditar configuración de KMS o secreto.

🧾 Resumen ejecutivo para cursos

A04:2025 Fallos Criptográficos se centra en la protección de datos mediante el uso adecuado de algoritmos, claves, protocolos y mecanismos criptográficos. Incluye algoritmos débiles, falta de entropía, tokens mal firmados, claves expuestas, TLS inseguro, certificados inválidos, hashing insuficiente y ausencia de cifrado en reposo. Las consecuencias son severas: robo de cuentas, fugas masivas, intercepción MITM, falsificación de tokens y compromisos completos. La mitigación requiere cifrado fuerte, TLS moderno, gestión segura de claves, hashing seguro de contraseñas, CSPRNG para generación de tokens y verificación de firmas y configuraciones criptográficas como parte del pipeline automatizado. Es una de las categorías con mayor impacto real y uno de los pilares del AppSec.

Preguntas típicas en multiple choice

• “El banco guarda contraseñas con MD5” → Cryptographic Failures (hash inseguro).
• “La aplicación permite login por HTTP” → Cryptographic Failures (datos sin cifrar en tránsito).
• “Desarrollador crea su propio algoritmo” → Cryptographic Failures.
• “Solución adecuada” → menciona TLS 1.3, hashing fuerte (bcrypt/Argon2), gestión de claves segura, cifrado AES-256, nunca “crear algoritmo propio”.

¿Qué vulnerabilidad existe si un portal bancario permite el login a través de HTTP en lugar de HTTPS? Cryptographic Failures (exposición de credenciales en tránsito).

¿Qué ocurre si el banco guarda las contraseñas con MD5 sin sal? Las contraseñas son fácilmente crackeables con diccionarios y rainbow tables.

¿Cuál es el método correcto para almacenar contraseñas de clientes? Usar hashing adaptativo con bcrypt, Argon2 o scrypt, siempre con una sal única por usuario.

¿Qué riesgo implica usar TLS 1.0 o algoritmos débiles como RC4 en un sitio bancario? Cryptographic Failures: el tráfico puede ser descifrado o manipulado mediante ataques de downgrade o MITM.

¿Qué problema hay si las tarjetas de crédito se guardan en texto plano en la base de datos? Exposición directa de datos sensibles en caso de brecha (data exposure).

¿Qué pasa si el banco no cifra los números de cuenta cuando los exporta en un archivo descargable? Se produce exposición de datos sensibles por falta de cifrado en reposo o en tránsito.

¿Qué tipo de vulnerabilidad se produce cuando un atacante obtiene claves privadas TLS de un repositorio público? Cryptographic Failures por mala gestión de claves y secretos.

¿Cuál es el error de diseño si una aplicación usa su propio algoritmo de cifrado en lugar de estándares conocidos?  Uso de criptografía casera insegura → Cryptographic Failures.

¿Qué consecuencia tiene usar un cifrado simétrico reversible para almacenar contraseñas en lugar de hashing? Si se filtra la clave de cifrado, todas las contraseñas quedan expuestas en texto claro.

¿Por qué es un fallo criptográfico no rotar claves de cifrado o certificados vencidos? Porque se aumenta la ventana de ataque y se expone el sistema a compromisos prolongados.

¿Qué controles debe implementar un banco para evitar fallos criptográficos en tránsito? Uso de TLS 1.2/1.3, certificados válidos, HSTS y deshabilitación de protocolos/algoritmos débiles.

¿Qué controles debe implementar un banco para evitar fallos criptográficos en reposo? Cifrado AES-256 o equivalente, gestión segura de claves, control de acceso estricto y protección de backups.

¿Qué falla ocurre si la aplicación escribe contraseñas en logs sin enmascararlas? Exposición de datos sensibles por mala gestión criptográfica y de logging.

¿Qué significa «sal» en el hashing de contraseñas y por qué es importante? Es un valor aleatorio único por usuario que evita ataques con rainbow tables y dificulta el crackeo masivo.

¿Cuál es la diferencia entre cifrado y hashing en el manejo de contraseñas? El cifrado es reversible (si se conoce la clave), mientras que el hashing es unidireccional e ideal para almacenar contraseñas.

¿Qué error de configuración puede llevar a exposición de datos en navegadores o proxies? Permitir Cache-Control: public en respuestas con datos sensibles.

¿Por qué es inseguro usar SHA1 o SHA256 simples para contraseñas? Porque son algoritmos rápidos y fáciles de crackear con GPUs; deben usarse hashes adaptativos y lentos (bcrypt, Argon2).

¿Qué medida de defensa debe aplicar un banco para garantizar la integridad de datos sensibles? Usar firmas digitales o HMAC para validar que los datos no fueron modificados.

¿Qué riesgo existe si los certificados digitales del banco están caducados o autofirmados? Los usuarios no pueden verificar la autenticidad del sitio, lo que habilita ataques de phishing y MITM.

¿Qué estándar o guía recomienda prácticas para la protección criptográfica de datos? OWASP ASVS y normativas PCI DSS (en caso de datos de tarjetas).

¡Felicitaciones por completar este capítulo!

Ahora comprendes a fondo cómo funcionan los fallos criptográficos, por qué son tan peligrosos y cómo evitarlos en sistemas reales.

Has aprendido a:

• Identificar configuraciones inseguras y algoritmos obsoletos
• Proteger datos en tránsito y en reposo con criptografía moderna
• Diseñar un sistema robusto de almacenamiento de contraseñas
• Gestionar claves y secretos durante todo su ciclo de vida
• Configurar TLS de forma profesional y sin vulnerabilidades
• Implementar controles de privacidad que protegen realmente al usuario
• Prepararte para la llegada de la criptografía post-cuántica

Todo este conocimiento te convierte en un profesional capaz de reconocer los errores que comprometen sistemas en el mundo real y aplicar soluciones sólidas, actuales y alineadas con estándares internacionales.

Sigamos avanzando hacia un dominio completo de la seguridad web.