
Los programadores conquistan la infraestructura de seguridad como serie de códigos: almacenamiento de contraseñas en texto plano.
Cuando se trata de desplegar una infraestructura segura como código en su propia organización, ¿cómo lo está haciendo? Puede que sea una curva de aprendizaje, pero aprender a hacerlo será una gran oportunidad para mejorar tus habilidades, destacar entre tus compañeros y mantener más datos de los usuarios finales a salvo.
Antes de que empecemos con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarte a jugar un desafío gamificado de la vulnerabilidad del almacenamiento de datos sensibles; juega ahora y elige entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan un poco de trabajo, sigue leyendo:
La clave de la mayor parte de la seguridad informática hoy en día tiene que ver con las contraseñas. Incluso si se emplean otros métodos de seguridad, como la autenticación de dos factores o la biometría, la mayoría de las organizaciones siguen empleando la seguridad basada en contraseñas como uno de los elementos de su protección. Para muchas empresas, las contraseñas son de uso exclusivo.
Utilizamos tanto las contraseñas que incluso tenemos reglas sobre cómo crearlas. Se supone que esto las hace menos vulnerables a los ataques de fuerza bruta o incluso a las adivinanzas. Por supuesto, algunas personas siguen utilizando contraseñas débiles, como demuestra un reciente informe de NordPass. Es difícil de creer que en 2020 la gente siga usando 12345 y un montón de otras palabras adivinables como chocolate, contraseña y Dios para proteger sus activos más sensibles.
Siempre habrá quien no se preocupe por utilizar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a elaborar sus palabras o frases de acceso de determinadas maneras. Todos conocemos ya las reglas: las contraseñas deben tener al menos ocho caracteres y estar compuestas por letras mayúsculas y minúsculas, con al menos un número y un carácter especial.
Lo malo es que incluso si los usuarios se adhieren a las reglas para hacer los tipos de contraseñas más fuertes, puede que no sirva de nada si todas están almacenadas en texto plano. La contraseña 12345 es tan mala como Nuts53!SpiKe&Dog12 si un hacker es capaz de leer todo el archivo de contraseñas.
¿Por qué es peligroso almacenar contraseñas en texto plano?
Almacenar las contraseñas en texto plano es malo porque pone en riesgo tanto al sistema como a los usuarios. Obviamente, tener un hacker capaz de encontrar y leer cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar un usuario con credenciales de administrador y comprometer todo el sistema o sitio. Y como estarían utilizando nombres de usuario y contraseñas adecuadas, la seguridad interna podría no detectar la intrusión o detectarla mucho después de que el daño esté hecho.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, porque mucha gente reutiliza las contraseñas. Como hemos hecho que las contraseñas sean tan difíciles de crear, mucha gente recurre a reutilizar las que puede recordar en varios sitios. Si un atacante compromete un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas utilizando el mismo nombre y la misma contraseña, lo que pone a los usuarios en gran riesgo de delitos secundarios.
Es relativamente fácil almacenar accidentalmente las contraseñas en texto plano o no darse cuenta de que esto podría causar grandes problemas en el futuro. Por ejemplo, el siguiente código es un método común empleado para almacenar contraseñas al definir un recurso de AWS utilizando plantillas de Terraform:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la contraseña utilizada para gestionar la instancia de la base de datos MySQL en AWS se está almacenando en texto plano. Eso significa que cualquiera con acceso al repositorio de código fuente podría leerla, o incluso copiarla.
La protección de las contraseñas varía según el marco de trabajo, pero existen métodos de protección para cada plataforma. Por ejemplo, la contraseña de MySQL puede guardarse en un almacenamiento seguro como AWS Secrets Manager:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la plantilla de Terraform obtendrá la contraseña del servicio AWS Secrets Manager y nunca se almacenará en texto plano en los archivos de la plantilla.
Proteger las contraseñas evitando el almacenamiento en texto plano
Las contraseñas son las llaves de tu reino y nunca deberían almacenarse en texto plano. Ni siquiera las personas internas de una organización deberían tener acceso a un gran repositorio de contraseñas sin protección, ni debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡no hay excusas!) También existe el peligro de que personas malintencionadas de dentro fisgoneen los archivos y obtengan acceso donde no deben.
Y en el caso de un ataque externo, imagínate el doble golpe que se puede dar si se encuentra una puerta trasera a tu base de datos a través de algo tan simple como una vulnerabilidad de inyección SQL, y además consiguen acceder al directorio donde se almacenan las contraseñas. ¿Crees que son demasiados pasos cargados de errores para llegar a buen puerto? Lamentablemente, este escenario exacto ocurrió en la brecha de Sony de 2011. Más de un millón de contraseñas de clientes estaban almacenadas en texto plano, y el grupo de hackers Lulzsec accedió a ellas y a muchas más a través de un ataque común de inyección SQL.
Todas las contraseñas deben ser protegidas por cualquier defensa disponible dentro del marco de apoyo. En el caso de Terraform, las contraseñas nunca deben almacenarse en archivos de plantilla. Se recomienda utilizar un almacenamiento seguro como AWS Secrets Manager o Azure Key Vault, dependiendo del proveedor de la infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también hay que poner de su parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto plano contribuirá en gran medida a proteger a sus usuarios y sus sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el escaso control de acceso; básicamente, cualquiera puede verlas. Es imperativo (especialmente en un entorno de IaC donde de repente, más personas tienen acceso a la información sensible) que se les aplique un hash adecuado y que sólo se les conceda acceso a aquellos que absolutamente lo necesitan.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos y vulnerabilidades de seguridad. También puedes probar un reto IaC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.


Hoy en día, las contraseñas son la clave de la mayoría de las medidas de seguridad informática. Incluso cuando se utilizan otros métodos de seguridad, como la autenticación de dos factores o la biometría, la mayoría de las empresas siguen utilizando la seguridad basada en contraseñas como parte de su protección.
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Reservar una demostraciónMatias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung in der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und verfügt über mehr als 10 Patente. Wenn er nicht an seinem Schreibtisch ist, war Matias als Ausbilder für fortgeschrittene Schulungen zur Anwendungssicherheit tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat an der Universität Gent in Computertechnik promoviert, wo er Anwendungssicherheit durch Programmverschleierung studierte, um das Innenleben einer Anwendung zu verbergen.


Cuando se trata de desplegar una infraestructura segura como código en su propia organización, ¿cómo lo está haciendo? Puede que sea una curva de aprendizaje, pero aprender a hacerlo será una gran oportunidad para mejorar tus habilidades, destacar entre tus compañeros y mantener más datos de los usuarios finales a salvo.
Antes de que empecemos con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarte a jugar un desafío gamificado de la vulnerabilidad del almacenamiento de datos sensibles; juega ahora y elige entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan un poco de trabajo, sigue leyendo:
La clave de la mayor parte de la seguridad informática hoy en día tiene que ver con las contraseñas. Incluso si se emplean otros métodos de seguridad, como la autenticación de dos factores o la biometría, la mayoría de las organizaciones siguen empleando la seguridad basada en contraseñas como uno de los elementos de su protección. Para muchas empresas, las contraseñas son de uso exclusivo.
Utilizamos tanto las contraseñas que incluso tenemos reglas sobre cómo crearlas. Se supone que esto las hace menos vulnerables a los ataques de fuerza bruta o incluso a las adivinanzas. Por supuesto, algunas personas siguen utilizando contraseñas débiles, como demuestra un reciente informe de NordPass. Es difícil de creer que en 2020 la gente siga usando 12345 y un montón de otras palabras adivinables como chocolate, contraseña y Dios para proteger sus activos más sensibles.
Siempre habrá quien no se preocupe por utilizar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a elaborar sus palabras o frases de acceso de determinadas maneras. Todos conocemos ya las reglas: las contraseñas deben tener al menos ocho caracteres y estar compuestas por letras mayúsculas y minúsculas, con al menos un número y un carácter especial.
Lo malo es que incluso si los usuarios se adhieren a las reglas para hacer los tipos de contraseñas más fuertes, puede que no sirva de nada si todas están almacenadas en texto plano. La contraseña 12345 es tan mala como Nuts53!SpiKe&Dog12 si un hacker es capaz de leer todo el archivo de contraseñas.
¿Por qué es peligroso almacenar contraseñas en texto plano?
Almacenar las contraseñas en texto plano es malo porque pone en riesgo tanto al sistema como a los usuarios. Obviamente, tener un hacker capaz de encontrar y leer cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar un usuario con credenciales de administrador y comprometer todo el sistema o sitio. Y como estarían utilizando nombres de usuario y contraseñas adecuadas, la seguridad interna podría no detectar la intrusión o detectarla mucho después de que el daño esté hecho.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, porque mucha gente reutiliza las contraseñas. Como hemos hecho que las contraseñas sean tan difíciles de crear, mucha gente recurre a reutilizar las que puede recordar en varios sitios. Si un atacante compromete un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas utilizando el mismo nombre y la misma contraseña, lo que pone a los usuarios en gran riesgo de delitos secundarios.
Es relativamente fácil almacenar accidentalmente las contraseñas en texto plano o no darse cuenta de que esto podría causar grandes problemas en el futuro. Por ejemplo, el siguiente código es un método común empleado para almacenar contraseñas al definir un recurso de AWS utilizando plantillas de Terraform:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la contraseña utilizada para gestionar la instancia de la base de datos MySQL en AWS se está almacenando en texto plano. Eso significa que cualquiera con acceso al repositorio de código fuente podría leerla, o incluso copiarla.
La protección de las contraseñas varía según el marco de trabajo, pero existen métodos de protección para cada plataforma. Por ejemplo, la contraseña de MySQL puede guardarse en un almacenamiento seguro como AWS Secrets Manager:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la plantilla de Terraform obtendrá la contraseña del servicio AWS Secrets Manager y nunca se almacenará en texto plano en los archivos de la plantilla.
Proteger las contraseñas evitando el almacenamiento en texto plano
Las contraseñas son las llaves de tu reino y nunca deberían almacenarse en texto plano. Ni siquiera las personas internas de una organización deberían tener acceso a un gran repositorio de contraseñas sin protección, ni debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡no hay excusas!) También existe el peligro de que personas malintencionadas de dentro fisgoneen los archivos y obtengan acceso donde no deben.
Y en el caso de un ataque externo, imagínate el doble golpe que se puede dar si se encuentra una puerta trasera a tu base de datos a través de algo tan simple como una vulnerabilidad de inyección SQL, y además consiguen acceder al directorio donde se almacenan las contraseñas. ¿Crees que son demasiados pasos cargados de errores para llegar a buen puerto? Lamentablemente, este escenario exacto ocurrió en la brecha de Sony de 2011. Más de un millón de contraseñas de clientes estaban almacenadas en texto plano, y el grupo de hackers Lulzsec accedió a ellas y a muchas más a través de un ataque común de inyección SQL.
Todas las contraseñas deben ser protegidas por cualquier defensa disponible dentro del marco de apoyo. En el caso de Terraform, las contraseñas nunca deben almacenarse en archivos de plantilla. Se recomienda utilizar un almacenamiento seguro como AWS Secrets Manager o Azure Key Vault, dependiendo del proveedor de la infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también hay que poner de su parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto plano contribuirá en gran medida a proteger a sus usuarios y sus sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el escaso control de acceso; básicamente, cualquiera puede verlas. Es imperativo (especialmente en un entorno de IaC donde de repente, más personas tienen acceso a la información sensible) que se les aplique un hash adecuado y que sólo se les conceda acceso a aquellos que absolutamente lo necesitan.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos y vulnerabilidades de seguridad. También puedes probar un reto IaC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.

Cuando se trata de desplegar una infraestructura segura como código en su propia organización, ¿cómo lo está haciendo? Puede que sea una curva de aprendizaje, pero aprender a hacerlo será una gran oportunidad para mejorar tus habilidades, destacar entre tus compañeros y mantener más datos de los usuarios finales a salvo.
Antes de que empecemos con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarte a jugar un desafío gamificado de la vulnerabilidad del almacenamiento de datos sensibles; juega ahora y elige entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan un poco de trabajo, sigue leyendo:
La clave de la mayor parte de la seguridad informática hoy en día tiene que ver con las contraseñas. Incluso si se emplean otros métodos de seguridad, como la autenticación de dos factores o la biometría, la mayoría de las organizaciones siguen empleando la seguridad basada en contraseñas como uno de los elementos de su protección. Para muchas empresas, las contraseñas son de uso exclusivo.
Utilizamos tanto las contraseñas que incluso tenemos reglas sobre cómo crearlas. Se supone que esto las hace menos vulnerables a los ataques de fuerza bruta o incluso a las adivinanzas. Por supuesto, algunas personas siguen utilizando contraseñas débiles, como demuestra un reciente informe de NordPass. Es difícil de creer que en 2020 la gente siga usando 12345 y un montón de otras palabras adivinables como chocolate, contraseña y Dios para proteger sus activos más sensibles.
Siempre habrá quien no se preocupe por utilizar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a elaborar sus palabras o frases de acceso de determinadas maneras. Todos conocemos ya las reglas: las contraseñas deben tener al menos ocho caracteres y estar compuestas por letras mayúsculas y minúsculas, con al menos un número y un carácter especial.
Lo malo es que incluso si los usuarios se adhieren a las reglas para hacer los tipos de contraseñas más fuertes, puede que no sirva de nada si todas están almacenadas en texto plano. La contraseña 12345 es tan mala como Nuts53!SpiKe&Dog12 si un hacker es capaz de leer todo el archivo de contraseñas.
¿Por qué es peligroso almacenar contraseñas en texto plano?
Almacenar las contraseñas en texto plano es malo porque pone en riesgo tanto al sistema como a los usuarios. Obviamente, tener un hacker capaz de encontrar y leer cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar un usuario con credenciales de administrador y comprometer todo el sistema o sitio. Y como estarían utilizando nombres de usuario y contraseñas adecuadas, la seguridad interna podría no detectar la intrusión o detectarla mucho después de que el daño esté hecho.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, porque mucha gente reutiliza las contraseñas. Como hemos hecho que las contraseñas sean tan difíciles de crear, mucha gente recurre a reutilizar las que puede recordar en varios sitios. Si un atacante compromete un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas utilizando el mismo nombre y la misma contraseña, lo que pone a los usuarios en gran riesgo de delitos secundarios.
Es relativamente fácil almacenar accidentalmente las contraseñas en texto plano o no darse cuenta de que esto podría causar grandes problemas en el futuro. Por ejemplo, el siguiente código es un método común empleado para almacenar contraseñas al definir un recurso de AWS utilizando plantillas de Terraform:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la contraseña utilizada para gestionar la instancia de la base de datos MySQL en AWS se está almacenando en texto plano. Eso significa que cualquiera con acceso al repositorio de código fuente podría leerla, o incluso copiarla.
La protección de las contraseñas varía según el marco de trabajo, pero existen métodos de protección para cada plataforma. Por ejemplo, la contraseña de MySQL puede guardarse en un almacenamiento seguro como AWS Secrets Manager:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la plantilla de Terraform obtendrá la contraseña del servicio AWS Secrets Manager y nunca se almacenará en texto plano en los archivos de la plantilla.
Proteger las contraseñas evitando el almacenamiento en texto plano
Las contraseñas son las llaves de tu reino y nunca deberían almacenarse en texto plano. Ni siquiera las personas internas de una organización deberían tener acceso a un gran repositorio de contraseñas sin protección, ni debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡no hay excusas!) También existe el peligro de que personas malintencionadas de dentro fisgoneen los archivos y obtengan acceso donde no deben.
Y en el caso de un ataque externo, imagínate el doble golpe que se puede dar si se encuentra una puerta trasera a tu base de datos a través de algo tan simple como una vulnerabilidad de inyección SQL, y además consiguen acceder al directorio donde se almacenan las contraseñas. ¿Crees que son demasiados pasos cargados de errores para llegar a buen puerto? Lamentablemente, este escenario exacto ocurrió en la brecha de Sony de 2011. Más de un millón de contraseñas de clientes estaban almacenadas en texto plano, y el grupo de hackers Lulzsec accedió a ellas y a muchas más a través de un ataque común de inyección SQL.
Todas las contraseñas deben ser protegidas por cualquier defensa disponible dentro del marco de apoyo. En el caso de Terraform, las contraseñas nunca deben almacenarse en archivos de plantilla. Se recomienda utilizar un almacenamiento seguro como AWS Secrets Manager o Azure Key Vault, dependiendo del proveedor de la infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también hay que poner de su parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto plano contribuirá en gran medida a proteger a sus usuarios y sus sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el escaso control de acceso; básicamente, cualquiera puede verlas. Es imperativo (especialmente en un entorno de IaC donde de repente, más personas tienen acceso a la información sensible) que se les aplique un hash adecuado y que sólo se les conceda acceso a aquellos que absolutamente lo necesitan.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos y vulnerabilidades de seguridad. También puedes probar un reto IaC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.

Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Ver informeReservar una demostraciónMatias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung in der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und verfügt über mehr als 10 Patente. Wenn er nicht an seinem Schreibtisch ist, war Matias als Ausbilder für fortgeschrittene Schulungen zur Anwendungssicherheit tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat an der Universität Gent in Computertechnik promoviert, wo er Anwendungssicherheit durch Programmverschleierung studierte, um das Innenleben einer Anwendung zu verbergen.
Cuando se trata de desplegar una infraestructura segura como código en su propia organización, ¿cómo lo está haciendo? Puede que sea una curva de aprendizaje, pero aprender a hacerlo será una gran oportunidad para mejorar tus habilidades, destacar entre tus compañeros y mantener más datos de los usuarios finales a salvo.
Antes de que empecemos con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarte a jugar un desafío gamificado de la vulnerabilidad del almacenamiento de datos sensibles; juega ahora y elige entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan un poco de trabajo, sigue leyendo:
La clave de la mayor parte de la seguridad informática hoy en día tiene que ver con las contraseñas. Incluso si se emplean otros métodos de seguridad, como la autenticación de dos factores o la biometría, la mayoría de las organizaciones siguen empleando la seguridad basada en contraseñas como uno de los elementos de su protección. Para muchas empresas, las contraseñas son de uso exclusivo.
Utilizamos tanto las contraseñas que incluso tenemos reglas sobre cómo crearlas. Se supone que esto las hace menos vulnerables a los ataques de fuerza bruta o incluso a las adivinanzas. Por supuesto, algunas personas siguen utilizando contraseñas débiles, como demuestra un reciente informe de NordPass. Es difícil de creer que en 2020 la gente siga usando 12345 y un montón de otras palabras adivinables como chocolate, contraseña y Dios para proteger sus activos más sensibles.
Siempre habrá quien no se preocupe por utilizar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a elaborar sus palabras o frases de acceso de determinadas maneras. Todos conocemos ya las reglas: las contraseñas deben tener al menos ocho caracteres y estar compuestas por letras mayúsculas y minúsculas, con al menos un número y un carácter especial.
Lo malo es que incluso si los usuarios se adhieren a las reglas para hacer los tipos de contraseñas más fuertes, puede que no sirva de nada si todas están almacenadas en texto plano. La contraseña 12345 es tan mala como Nuts53!SpiKe&Dog12 si un hacker es capaz de leer todo el archivo de contraseñas.
¿Por qué es peligroso almacenar contraseñas en texto plano?
Almacenar las contraseñas en texto plano es malo porque pone en riesgo tanto al sistema como a los usuarios. Obviamente, tener un hacker capaz de encontrar y leer cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar un usuario con credenciales de administrador y comprometer todo el sistema o sitio. Y como estarían utilizando nombres de usuario y contraseñas adecuadas, la seguridad interna podría no detectar la intrusión o detectarla mucho después de que el daño esté hecho.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, porque mucha gente reutiliza las contraseñas. Como hemos hecho que las contraseñas sean tan difíciles de crear, mucha gente recurre a reutilizar las que puede recordar en varios sitios. Si un atacante compromete un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas utilizando el mismo nombre y la misma contraseña, lo que pone a los usuarios en gran riesgo de delitos secundarios.
Es relativamente fácil almacenar accidentalmente las contraseñas en texto plano o no darse cuenta de que esto podría causar grandes problemas en el futuro. Por ejemplo, el siguiente código es un método común empleado para almacenar contraseñas al definir un recurso de AWS utilizando plantillas de Terraform:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la contraseña utilizada para gestionar la instancia de la base de datos MySQL en AWS se está almacenando en texto plano. Eso significa que cualquiera con acceso al repositorio de código fuente podría leerla, o incluso copiarla.
La protección de las contraseñas varía según el marco de trabajo, pero existen métodos de protección para cada plataforma. Por ejemplo, la contraseña de MySQL puede guardarse en un almacenamiento seguro como AWS Secrets Manager:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la plantilla de Terraform obtendrá la contraseña del servicio AWS Secrets Manager y nunca se almacenará en texto plano en los archivos de la plantilla.
Proteger las contraseñas evitando el almacenamiento en texto plano
Las contraseñas son las llaves de tu reino y nunca deberían almacenarse en texto plano. Ni siquiera las personas internas de una organización deberían tener acceso a un gran repositorio de contraseñas sin protección, ni debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡no hay excusas!) También existe el peligro de que personas malintencionadas de dentro fisgoneen los archivos y obtengan acceso donde no deben.
Y en el caso de un ataque externo, imagínate el doble golpe que se puede dar si se encuentra una puerta trasera a tu base de datos a través de algo tan simple como una vulnerabilidad de inyección SQL, y además consiguen acceder al directorio donde se almacenan las contraseñas. ¿Crees que son demasiados pasos cargados de errores para llegar a buen puerto? Lamentablemente, este escenario exacto ocurrió en la brecha de Sony de 2011. Más de un millón de contraseñas de clientes estaban almacenadas en texto plano, y el grupo de hackers Lulzsec accedió a ellas y a muchas más a través de un ataque común de inyección SQL.
Todas las contraseñas deben ser protegidas por cualquier defensa disponible dentro del marco de apoyo. En el caso de Terraform, las contraseñas nunca deben almacenarse en archivos de plantilla. Se recomienda utilizar un almacenamiento seguro como AWS Secrets Manager o Azure Key Vault, dependiendo del proveedor de la infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también hay que poner de su parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto plano contribuirá en gran medida a proteger a sus usuarios y sus sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el escaso control de acceso; básicamente, cualquiera puede verlas. Es imperativo (especialmente en un entorno de IaC donde de repente, más personas tienen acceso a la información sensible) que se les aplique un hash adecuado y que sólo se les conceda acceso a aquellos que absolutamente lo necesitan.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos y vulnerabilidades de seguridad. También puedes probar un reto IaC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
Índice
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
El poder de la seguridad de aplicaciones OpenText + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
Temas y contenidos de la formación Securecode
Nuestros contenidos líderes en el sector se desarrollan continuamente para adaptarse al cambiante panorama del desarrollo de software, teniendo en cuenta su función. Temas que abarcan desde la inteligencia artificial hasta la inyección XQuery y que se ofrecen para una amplia variedad de funciones, desde arquitectos e ingenieros hasta gestores de productos y control de calidad. Eche un vistazo a nuestro catálogo de contenidos por temas y funciones.





.png)