Los codificadores 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.


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.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.


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 siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
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. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Recursos para empezar
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.