
Los programadores conquistan la infraestructura de seguridad con la serie Code: almacenamiento de contraseñas en texto plano
Cuando se trata de implementar una infraestructura segura como código en su propia organización, ¿cómo le va? Puede que sea una especie de curva de aprendizaje, pero aprender los entresijos será una gran oportunidad para mejorar tus habilidades y destacar entre tus compañeros, y mantenga seguros más datos de los usuarios finales.
Antes de comenzar con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarlos a jugar un desafío gamificado sobre la vulnerabilidad del almacenamiento de datos confidenciales; juegue ahora y elija entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan algo de trabajo, sigue leyendo:
La clave de la mayoría de la seguridad informática en estos días son 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 un elemento de su protección. Para muchas empresas, las contraseñas se utilizan exclusivamente.
Usamos 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 conjeturas descabelladas. Por supuesto, algunas personas todavía usan contraseñas débiles, como lo demuestra un reciente informe de NordPass. Cuesta creer que en 2020 la gente siga usando 12345, así como un montón de otras palabras que se pueden adivinar, como chocolate, contraseña y Dios, para proteger sus activos más confidenciales.
Siempre habrá quienes no quieran usar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a crear sus palabras o frases de acceso de ciertas maneras. Ya todos conocemos las reglas según las cuales 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 respetan las reglas para crear contraseñas más seguras, es posible que no sirva de nada si todas se almacenan en texto plano. ¡La contraseña 12345 es tan mala como la de Nuts53! Spike&dog12 si un hacker puede 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. Evidentemente, conseguir que un pirata informático pueda encontrar y leer todas y cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar a un usuario con credenciales de administrador y comprometer todo el sistema o el sitio. Y dado que utilizarían nombres de usuario y contraseñas correctos, es posible que la seguridad interna no detecte la intrusión o no la detecte mucho después de que se haya producido el daño.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, ya que muchas personas reutilizan las contraseñas. Debido a que hemos hecho que sea tan difícil crear contraseñas, muchas personas recurren a reutilizar las que pueden recordar en varios sitios. Si un atacante pone en peligro un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas con el mismo nombre y contraseña, lo que expone a los usuarios a un gran riesgo de cometer delitos secundarios.
Es relativamente fácil almacenar accidentalmente contraseñas en texto plano o no darse cuenta de que esto podría causar problemas importantes en el futuro. Por ejemplo, el siguiente código es un método común que se emplea para almacenar contraseñas al definir un recurso de AWS mediante plantillas de Terraform:
recurso «aws_db_instance» «predeterminado» {
motor = «mysql»
almacenamiento_asignado = 10
clase_instancia = «db.t2.micro»
nombre de usuario = «admin»
contraseña = «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 administrar la instancia de base de datos MySQL en AWS se almacena en texto sin formato. Esto significa que cualquier persona con acceso al repositorio de código fuente puede leerlo o incluso copiarlo.
La protección de las contraseñas varía según el marco, pero existen métodos de protección para todas las plataformas. Por ejemplo, la contraseña de MySQL se puede almacenar en un almacenamiento seguro como AWS Secrets Manager:
recurso «aws_db_instance» «predeterminado» {
motor = «mysql»
almacenamiento_asignado = 10
clase_instancia = «db.t2.micro»
nombre de usuario = «admin»
contraseña = «$ {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 plantilla.
Proteger las contraseñas evitando el almacenamiento de texto sin formato
Las contraseñas son las claves de tu reino y nunca deben guardarse en texto plano. Ni siquiera las personas que forman parte de una organización deberían tener acceso a un repositorio de contraseñas grande y desprotegido, ni tampoco debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡sin excusas!). También existe el peligro de que personas con información privilegiada malintencionadas husmeen los archivos y accedan a sitios donde no deberían.
Y con un ataque externo, imagínese el golpe por partida doble que sería posible si se descubre una puerta trasera a su base de datos mediante algo tan simple como una vulnerabilidad de inyección de SQL, y ellos también obtienen acceso al directorio donde están almacenadas las contraseñas. ¿Cree que son demasiados pasos plagados de errores como para llevarlos a buen puerto? Lamentablemente, este escenario exacto ocurrió en La violación de Sony en 2011. Más de un millón de contraseñas de clientes se almacenaron en texto plano, y el grupo de hackers de Lulzsec accedió a ellas y a muchas más mediante un ataque común de inyección de SQL.
Todas las contraseñas deben estar protegidas por las defensas disponibles en el marco de soporte. Para 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, según el proveedor de infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también debes hacer tu parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto sin formato contribuirá en gran medida a proteger a los usuarios y los sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el deficiente control de acceso; básicamente, cualquiera puede verlas. Es imprescindible (especialmente en un entorno de iAC, en el que, de repente, más personas tienen acceso a la información confidencial) que se controlen adecuadamente y que solo se conceda el acceso a aquellos que absolutamente lo necesitan.
Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas y vulnerabilidades de seguridad. También puedes prueba un desafío iAC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.


La clave de la mayoría de la seguridad informática en estos días son 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 un elemento de su protección.
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.


Cuando se trata de implementar una infraestructura segura como código en su propia organización, ¿cómo le va? Puede que sea una especie de curva de aprendizaje, pero aprender los entresijos será una gran oportunidad para mejorar tus habilidades y destacar entre tus compañeros, y mantenga seguros más datos de los usuarios finales.
Antes de comenzar con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarlos a jugar un desafío gamificado sobre la vulnerabilidad del almacenamiento de datos confidenciales; juegue ahora y elija entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan algo de trabajo, sigue leyendo:
La clave de la mayoría de la seguridad informática en estos días son 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 un elemento de su protección. Para muchas empresas, las contraseñas se utilizan exclusivamente.
Usamos 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 conjeturas descabelladas. Por supuesto, algunas personas todavía usan contraseñas débiles, como lo demuestra un reciente informe de NordPass. Cuesta creer que en 2020 la gente siga usando 12345, así como un montón de otras palabras que se pueden adivinar, como chocolate, contraseña y Dios, para proteger sus activos más confidenciales.
Siempre habrá quienes no quieran usar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a crear sus palabras o frases de acceso de ciertas maneras. Ya todos conocemos las reglas según las cuales 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 respetan las reglas para crear contraseñas más seguras, es posible que no sirva de nada si todas se almacenan en texto plano. ¡La contraseña 12345 es tan mala como la de Nuts53! Spike&dog12 si un hacker puede 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. Evidentemente, conseguir que un pirata informático pueda encontrar y leer todas y cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar a un usuario con credenciales de administrador y comprometer todo el sistema o el sitio. Y dado que utilizarían nombres de usuario y contraseñas correctos, es posible que la seguridad interna no detecte la intrusión o no la detecte mucho después de que se haya producido el daño.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, ya que muchas personas reutilizan las contraseñas. Debido a que hemos hecho que sea tan difícil crear contraseñas, muchas personas recurren a reutilizar las que pueden recordar en varios sitios. Si un atacante pone en peligro un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas con el mismo nombre y contraseña, lo que expone a los usuarios a un gran riesgo de cometer delitos secundarios.
Es relativamente fácil almacenar accidentalmente contraseñas en texto plano o no darse cuenta de que esto podría causar problemas importantes en el futuro. Por ejemplo, el siguiente código es un método común que se emplea para almacenar contraseñas al definir un recurso de AWS mediante plantillas de Terraform:
recurso «aws_db_instance» «predeterminado» {
motor = «mysql»
almacenamiento_asignado = 10
clase_instancia = «db.t2.micro»
nombre de usuario = «admin»
contraseña = «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 administrar la instancia de base de datos MySQL en AWS se almacena en texto sin formato. Esto significa que cualquier persona con acceso al repositorio de código fuente puede leerlo o incluso copiarlo.
La protección de las contraseñas varía según el marco, pero existen métodos de protección para todas las plataformas. Por ejemplo, la contraseña de MySQL se puede almacenar en un almacenamiento seguro como AWS Secrets Manager:
recurso «aws_db_instance» «predeterminado» {
motor = «mysql»
almacenamiento_asignado = 10
clase_instancia = «db.t2.micro»
nombre de usuario = «admin»
contraseña = «$ {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 plantilla.
Proteger las contraseñas evitando el almacenamiento de texto sin formato
Las contraseñas son las claves de tu reino y nunca deben guardarse en texto plano. Ni siquiera las personas que forman parte de una organización deberían tener acceso a un repositorio de contraseñas grande y desprotegido, ni tampoco debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡sin excusas!). También existe el peligro de que personas con información privilegiada malintencionadas husmeen los archivos y accedan a sitios donde no deberían.
Y con un ataque externo, imagínese el golpe por partida doble que sería posible si se descubre una puerta trasera a su base de datos mediante algo tan simple como una vulnerabilidad de inyección de SQL, y ellos también obtienen acceso al directorio donde están almacenadas las contraseñas. ¿Cree que son demasiados pasos plagados de errores como para llevarlos a buen puerto? Lamentablemente, este escenario exacto ocurrió en La violación de Sony en 2011. Más de un millón de contraseñas de clientes se almacenaron en texto plano, y el grupo de hackers de Lulzsec accedió a ellas y a muchas más mediante un ataque común de inyección de SQL.
Todas las contraseñas deben estar protegidas por las defensas disponibles en el marco de soporte. Para 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, según el proveedor de infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también debes hacer tu parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto sin formato contribuirá en gran medida a proteger a los usuarios y los sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el deficiente control de acceso; básicamente, cualquiera puede verlas. Es imprescindible (especialmente en un entorno de iAC, en el que, de repente, más personas tienen acceso a la información confidencial) que se controlen adecuadamente y que solo se conceda el acceso a aquellos que absolutamente lo necesitan.
Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas y vulnerabilidades de seguridad. También puedes prueba un desafío iAC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

Cuando se trata de implementar una infraestructura segura como código en su propia organización, ¿cómo le va? Puede que sea una especie de curva de aprendizaje, pero aprender los entresijos será una gran oportunidad para mejorar tus habilidades y destacar entre tus compañeros, y mantenga seguros más datos de los usuarios finales.
Antes de comenzar con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarlos a jugar un desafío gamificado sobre la vulnerabilidad del almacenamiento de datos confidenciales; juegue ahora y elija entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan algo de trabajo, sigue leyendo:
La clave de la mayoría de la seguridad informática en estos días son 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 un elemento de su protección. Para muchas empresas, las contraseñas se utilizan exclusivamente.
Usamos 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 conjeturas descabelladas. Por supuesto, algunas personas todavía usan contraseñas débiles, como lo demuestra un reciente informe de NordPass. Cuesta creer que en 2020 la gente siga usando 12345, así como un montón de otras palabras que se pueden adivinar, como chocolate, contraseña y Dios, para proteger sus activos más confidenciales.
Siempre habrá quienes no quieran usar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a crear sus palabras o frases de acceso de ciertas maneras. Ya todos conocemos las reglas según las cuales 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 respetan las reglas para crear contraseñas más seguras, es posible que no sirva de nada si todas se almacenan en texto plano. ¡La contraseña 12345 es tan mala como la de Nuts53! Spike&dog12 si un hacker puede 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. Evidentemente, conseguir que un pirata informático pueda encontrar y leer todas y cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar a un usuario con credenciales de administrador y comprometer todo el sistema o el sitio. Y dado que utilizarían nombres de usuario y contraseñas correctos, es posible que la seguridad interna no detecte la intrusión o no la detecte mucho después de que se haya producido el daño.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, ya que muchas personas reutilizan las contraseñas. Debido a que hemos hecho que sea tan difícil crear contraseñas, muchas personas recurren a reutilizar las que pueden recordar en varios sitios. Si un atacante pone en peligro un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas con el mismo nombre y contraseña, lo que expone a los usuarios a un gran riesgo de cometer delitos secundarios.
Es relativamente fácil almacenar accidentalmente contraseñas en texto plano o no darse cuenta de que esto podría causar problemas importantes en el futuro. Por ejemplo, el siguiente código es un método común que se emplea para almacenar contraseñas al definir un recurso de AWS mediante plantillas de Terraform:
recurso «aws_db_instance» «predeterminado» {
motor = «mysql»
almacenamiento_asignado = 10
clase_instancia = «db.t2.micro»
nombre de usuario = «admin»
contraseña = «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 administrar la instancia de base de datos MySQL en AWS se almacena en texto sin formato. Esto significa que cualquier persona con acceso al repositorio de código fuente puede leerlo o incluso copiarlo.
La protección de las contraseñas varía según el marco, pero existen métodos de protección para todas las plataformas. Por ejemplo, la contraseña de MySQL se puede almacenar en un almacenamiento seguro como AWS Secrets Manager:
recurso «aws_db_instance» «predeterminado» {
motor = «mysql»
almacenamiento_asignado = 10
clase_instancia = «db.t2.micro»
nombre de usuario = «admin»
contraseña = «$ {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 plantilla.
Proteger las contraseñas evitando el almacenamiento de texto sin formato
Las contraseñas son las claves de tu reino y nunca deben guardarse en texto plano. Ni siquiera las personas que forman parte de una organización deberían tener acceso a un repositorio de contraseñas grande y desprotegido, ni tampoco debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡sin excusas!). También existe el peligro de que personas con información privilegiada malintencionadas husmeen los archivos y accedan a sitios donde no deberían.
Y con un ataque externo, imagínese el golpe por partida doble que sería posible si se descubre una puerta trasera a su base de datos mediante algo tan simple como una vulnerabilidad de inyección de SQL, y ellos también obtienen acceso al directorio donde están almacenadas las contraseñas. ¿Cree que son demasiados pasos plagados de errores como para llevarlos a buen puerto? Lamentablemente, este escenario exacto ocurrió en La violación de Sony en 2011. Más de un millón de contraseñas de clientes se almacenaron en texto plano, y el grupo de hackers de Lulzsec accedió a ellas y a muchas más mediante un ataque común de inyección de SQL.
Todas las contraseñas deben estar protegidas por las defensas disponibles en el marco de soporte. Para 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, según el proveedor de infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también debes hacer tu parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto sin formato contribuirá en gran medida a proteger a los usuarios y los sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el deficiente control de acceso; básicamente, cualquiera puede verlas. Es imprescindible (especialmente en un entorno de iAC, en el que, de repente, más personas tienen acceso a la información confidencial) que se controlen adecuadamente y que solo se conceda el acceso a aquellos que absolutamente lo necesitan.
Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas y vulnerabilidades de seguridad. También puedes prueba un desafío iAC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez consulter le rapportVeuillez réserver une démonstration.Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
Cuando se trata de implementar una infraestructura segura como código en su propia organización, ¿cómo le va? Puede que sea una especie de curva de aprendizaje, pero aprender los entresijos será una gran oportunidad para mejorar tus habilidades y destacar entre tus compañeros, y mantenga seguros más datos de los usuarios finales.
Antes de comenzar con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarlos a jugar un desafío gamificado sobre la vulnerabilidad del almacenamiento de datos confidenciales; juegue ahora y elija entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan algo de trabajo, sigue leyendo:
La clave de la mayoría de la seguridad informática en estos días son 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 un elemento de su protección. Para muchas empresas, las contraseñas se utilizan exclusivamente.
Usamos 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 conjeturas descabelladas. Por supuesto, algunas personas todavía usan contraseñas débiles, como lo demuestra un reciente informe de NordPass. Cuesta creer que en 2020 la gente siga usando 12345, así como un montón de otras palabras que se pueden adivinar, como chocolate, contraseña y Dios, para proteger sus activos más confidenciales.
Siempre habrá quienes no quieran usar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a crear sus palabras o frases de acceso de ciertas maneras. Ya todos conocemos las reglas según las cuales 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 respetan las reglas para crear contraseñas más seguras, es posible que no sirva de nada si todas se almacenan en texto plano. ¡La contraseña 12345 es tan mala como la de Nuts53! Spike&dog12 si un hacker puede 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. Evidentemente, conseguir que un pirata informático pueda encontrar y leer todas y cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar a un usuario con credenciales de administrador y comprometer todo el sistema o el sitio. Y dado que utilizarían nombres de usuario y contraseñas correctos, es posible que la seguridad interna no detecte la intrusión o no la detecte mucho después de que se haya producido el daño.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, ya que muchas personas reutilizan las contraseñas. Debido a que hemos hecho que sea tan difícil crear contraseñas, muchas personas recurren a reutilizar las que pueden recordar en varios sitios. Si un atacante pone en peligro un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas con el mismo nombre y contraseña, lo que expone a los usuarios a un gran riesgo de cometer delitos secundarios.
Es relativamente fácil almacenar accidentalmente contraseñas en texto plano o no darse cuenta de que esto podría causar problemas importantes en el futuro. Por ejemplo, el siguiente código es un método común que se emplea para almacenar contraseñas al definir un recurso de AWS mediante plantillas de Terraform:
recurso «aws_db_instance» «predeterminado» {
motor = «mysql»
almacenamiento_asignado = 10
clase_instancia = «db.t2.micro»
nombre de usuario = «admin»
contraseña = «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 administrar la instancia de base de datos MySQL en AWS se almacena en texto sin formato. Esto significa que cualquier persona con acceso al repositorio de código fuente puede leerlo o incluso copiarlo.
La protección de las contraseñas varía según el marco, pero existen métodos de protección para todas las plataformas. Por ejemplo, la contraseña de MySQL se puede almacenar en un almacenamiento seguro como AWS Secrets Manager:
recurso «aws_db_instance» «predeterminado» {
motor = «mysql»
almacenamiento_asignado = 10
clase_instancia = «db.t2.micro»
nombre de usuario = «admin»
contraseña = «$ {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 plantilla.
Proteger las contraseñas evitando el almacenamiento de texto sin formato
Las contraseñas son las claves de tu reino y nunca deben guardarse en texto plano. Ni siquiera las personas que forman parte de una organización deberían tener acceso a un repositorio de contraseñas grande y desprotegido, ni tampoco debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡sin excusas!). También existe el peligro de que personas con información privilegiada malintencionadas husmeen los archivos y accedan a sitios donde no deberían.
Y con un ataque externo, imagínese el golpe por partida doble que sería posible si se descubre una puerta trasera a su base de datos mediante algo tan simple como una vulnerabilidad de inyección de SQL, y ellos también obtienen acceso al directorio donde están almacenadas las contraseñas. ¿Cree que son demasiados pasos plagados de errores como para llevarlos a buen puerto? Lamentablemente, este escenario exacto ocurrió en La violación de Sony en 2011. Más de un millón de contraseñas de clientes se almacenaron en texto plano, y el grupo de hackers de Lulzsec accedió a ellas y a muchas más mediante un ataque común de inyección de SQL.
Todas las contraseñas deben estar protegidas por las defensas disponibles en el marco de soporte. Para 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, según el proveedor de infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también debes hacer tu parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto sin formato contribuirá en gran medida a proteger a los usuarios y los sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el deficiente control de acceso; básicamente, cualquiera puede verlas. Es imprescindible (especialmente en un entorno de iAC, en el que, de repente, más personas tienen acceso a la información confidencial) que se controlen adecuadamente y que solo se conceda el acceso a aquellos que absolutamente lo necesitan.
Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas y vulnerabilidades de seguridad. También puedes prueba un desafío iAC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
Table des matières
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour débuter
Thèmes et contenu de la formation sur le code sécurisé
Notre contenu de pointe évolue constamment afin de s'adapter au paysage changeant du développement logiciel, en tenant compte de votre rôle. Nous proposons des thèmes allant de l'IA à l'injection XQuery pour différents postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par thème et par fonction.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions IA de Beat the Boss sont désormais disponibles à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année chez SCW. Mettez en œuvre des défis de sécurité avancés basés sur l'IA et le LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer grâce à des pratiques de conception sécurisées, à la prévention des vulnérabilités et au développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en 10 parties intitulée « Les catalyseurs de la réussite », qui montre comment relier la codification sécurisée aux résultats commerciaux, tels que la réduction des risques et la rapidité d'atteinte de la maturité du programme à long terme.




%20(1).avif)
.avif)
