SCW Icons
hero bg no divider
Blog

Les codeurs conquièrent l'infrastructure de sécurité sous forme de séries de codes : stockage des mots de passe en clair

Matias Madou, Ph.D.
Published May 18, 2020
Last updated on Mar 08, 2026

En ce qui concerne le déploiement d'une infrastructure sécurisée sous forme de code dans votre propre organisation, comment vous en sortez-vous ? Cela peut être un peu une courbe d'apprentissage, mais apprendre les ficelles du métier sera une excellente occasion d'améliorer vos compétences, de vous démarquer de vos pairs, et protégez davantage les données des utilisateurs finaux.

Avant de commencer ce prochain chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à relever un défi ludique sur la vulnérabilité du stockage de données sensibles ; jouez dès maintenant et choisissez parmi Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment c'était ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, les mots de passe constituent la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, telles que l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.

Nous utilisons tellement de mots de passe que nous avons même des règles sur la façon de les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou même aux devinettes. Bien entendu, certaines personnes utilisent encore des mots de passe faibles, comme en témoigne une récente rapport de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi que tout un tas d'autres mots faciles à deviner comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.

Il y aura toujours ceux qui n'aimeront pas utiliser des mots de passe complexes, mais la plupart des organisations professionnelles obligeront les utilisateurs à créer leurs mots d'accès ou leurs phrases d'une certaine manière. Nous connaissons tous les règles maintenant, les mots de passe devant comporter au moins huit caractères, composés de majuscules et de minuscules, avec au moins un chiffre et un caractère spécial requis.

Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des types de mots de passe les plus sûrs, il se peut qu'ils ne soient pas utiles s'ils sont tous stockés en texte brut. Le mot de passe 12345 est aussi mauvais que Nuts53 ! Spike&Dog12 si un pirate informatique est capable de lire l'intégralité du fichier de mot de passe.

Pourquoi est-il dangereux de stocker des mots de passe en clair ?

Le stockage des mots de passe en texte brut est une mauvaise chose car cela met en danger à la fois le système et les utilisateurs. De toute évidence, le fait qu'un pirate informatique soit capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait une catastrophe. Ils pourraient simplement trouver un utilisateur possédant des informations d'identification d'administrateur et compromettre l'ensemble du système ou du site. Et comme ils utiliseraient des noms d'utilisateur et des mots de passe appropriés, la sécurité interne risque de ne pas détecter l'intrusion ou de la détecter longtemps après que les dommages aient été causés.

Le fait de permettre aux attaquants de voler facilement les mots de passe stockés en texte clair nuit également aux utilisateurs, car de nombreuses personnes réutilisent les mots de passe. Parce que nous avons rendu la création de mots de passe si difficile, de nombreuses personnes ont recours à la réutilisation de mots de passe dont elles peuvent se souvenir sur plusieurs sites. Si un attaquant compromet un fichier de mots de passe, il essaiera certainement d'accéder à d'autres systèmes en utilisant le même nom et le même mot de passe, ce qui expose les utilisateurs à un risque élevé de crimes secondaires.

Il est relativement facile de stocker accidentellement des mots de passe en texte brut ou de ne pas se rendre compte que cela pourrait entraîner des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode couramment utilisée pour stocker les mots de passe lors de la définition d'une ressource AWS à l'aide de modèles Terraform :

ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « s3.cr3t.admin.p2ss »
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le mot de passe utilisé pour gérer l'instance de base de données MySQL dans AWS est stocké en texte brut. Cela signifie que toute personne ayant accès au référentiel de code source peut le lire, voire le copier.

La protection des mots de passe varie en fonction du framework, mais des méthodes de protection existent pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :

ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « $ {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]
}

Dans cet exemple, le modèle Terraform obtiendra le mot de passe du service AWS Secrets Manager et il ne sera jamais stocké en texte brut dans les fichiers modèles.

Protéger les mots de passe en évitant le stockage en texte brut

Les mots de passe sont les clés de votre royaume et ne doivent jamais être stockés en texte clair. Même les personnes internes d'une organisation ne devraient pas avoir accès à un vaste référentiel de mots de passe non protégé, et ce protocole commercial ne devrait pas non plus être accepté (il existe de nombreux gestionnaires de mots de passe qui autorisent le partage d'informations d'identification cryptées de nos jours, aucune excuse !). Il existe également le risque que des initiés malveillants espionnent des fichiers et y accèdent là où ils ne devraient pas.

Et en cas d'attaque extérieure, imaginez le double inconvénient qui pourrait survenir si une porte dérobée vers votre base de données est découverte grâce à une simple faille d'injection SQL, et si l'utilisateur accède au répertoire dans lequel les mots de passe sont également stockés. Vous pensez qu'il s'agit d'un trop grand nombre d'étapes truffées d'erreurs pour porter leurs fruits ? Malheureusement, ce scénario exact s'est produit en L'infraction commise par Sony en 2011. Plus d'un million de mots de passe clients ont été stockés en texte clair, et le groupe de hackers Lulzsec a accédé à ces mots de passe et à bien d'autres encore grâce à une attaque par injection SQL courante.

Tous les mots de passe doivent être protégés par toutes les défenses disponibles dans le cadre de support. Pour Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers modèles. Il est recommandé d'utiliser un stockage sécurisé comme AWS Secrets Manager ou Azure Key Vault, selon le fournisseur d'infrastructure.

Forcer les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part sur le backend. Garder les mots de passe hors du stockage en texte brut contribuera grandement à protéger vos utilisateurs et vos systèmes. Le principal danger du stockage des mots de passe en clair est le mauvais contrôle d'accès ; en fait, tout le monde peut les voir. Il est impératif (en particulier dans un environnement IaC où soudainement de plus en plus de personnes ont accès à des informations sensibles) que celles-ci soient correctement hachées et que seules les personnes qui en ont absolument besoin y aient accès y soient autorisées.

Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayez une démo IaC challenge au sein de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.


Afficher la ressource
Afficher la ressource

De nos jours, les mots de passe constituent la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, telles que l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme élément de leur protection.

Vous souhaitez en savoir plus ?

Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

learn more

Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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é.

Réservez une démo
Partagez sur :
linkedin brandsSocialx logo
Auteur
Matias Madou, Ph.D.
Published May 18, 2020

Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.

Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.

Partagez sur :
linkedin brandsSocialx logo

En ce qui concerne le déploiement d'une infrastructure sécurisée sous forme de code dans votre propre organisation, comment vous en sortez-vous ? Cela peut être un peu une courbe d'apprentissage, mais apprendre les ficelles du métier sera une excellente occasion d'améliorer vos compétences, de vous démarquer de vos pairs, et protégez davantage les données des utilisateurs finaux.

Avant de commencer ce prochain chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à relever un défi ludique sur la vulnérabilité du stockage de données sensibles ; jouez dès maintenant et choisissez parmi Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment c'était ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, les mots de passe constituent la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, telles que l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.

Nous utilisons tellement de mots de passe que nous avons même des règles sur la façon de les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou même aux devinettes. Bien entendu, certaines personnes utilisent encore des mots de passe faibles, comme en témoigne une récente rapport de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi que tout un tas d'autres mots faciles à deviner comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.

Il y aura toujours ceux qui n'aimeront pas utiliser des mots de passe complexes, mais la plupart des organisations professionnelles obligeront les utilisateurs à créer leurs mots d'accès ou leurs phrases d'une certaine manière. Nous connaissons tous les règles maintenant, les mots de passe devant comporter au moins huit caractères, composés de majuscules et de minuscules, avec au moins un chiffre et un caractère spécial requis.

Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des types de mots de passe les plus sûrs, il se peut qu'ils ne soient pas utiles s'ils sont tous stockés en texte brut. Le mot de passe 12345 est aussi mauvais que Nuts53 ! Spike&Dog12 si un pirate informatique est capable de lire l'intégralité du fichier de mot de passe.

Pourquoi est-il dangereux de stocker des mots de passe en clair ?

Le stockage des mots de passe en texte brut est une mauvaise chose car cela met en danger à la fois le système et les utilisateurs. De toute évidence, le fait qu'un pirate informatique soit capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait une catastrophe. Ils pourraient simplement trouver un utilisateur possédant des informations d'identification d'administrateur et compromettre l'ensemble du système ou du site. Et comme ils utiliseraient des noms d'utilisateur et des mots de passe appropriés, la sécurité interne risque de ne pas détecter l'intrusion ou de la détecter longtemps après que les dommages aient été causés.

Le fait de permettre aux attaquants de voler facilement les mots de passe stockés en texte clair nuit également aux utilisateurs, car de nombreuses personnes réutilisent les mots de passe. Parce que nous avons rendu la création de mots de passe si difficile, de nombreuses personnes ont recours à la réutilisation de mots de passe dont elles peuvent se souvenir sur plusieurs sites. Si un attaquant compromet un fichier de mots de passe, il essaiera certainement d'accéder à d'autres systèmes en utilisant le même nom et le même mot de passe, ce qui expose les utilisateurs à un risque élevé de crimes secondaires.

Il est relativement facile de stocker accidentellement des mots de passe en texte brut ou de ne pas se rendre compte que cela pourrait entraîner des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode couramment utilisée pour stocker les mots de passe lors de la définition d'une ressource AWS à l'aide de modèles Terraform :

ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « s3.cr3t.admin.p2ss »
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le mot de passe utilisé pour gérer l'instance de base de données MySQL dans AWS est stocké en texte brut. Cela signifie que toute personne ayant accès au référentiel de code source peut le lire, voire le copier.

La protection des mots de passe varie en fonction du framework, mais des méthodes de protection existent pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :

ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « $ {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]
}

Dans cet exemple, le modèle Terraform obtiendra le mot de passe du service AWS Secrets Manager et il ne sera jamais stocké en texte brut dans les fichiers modèles.

Protéger les mots de passe en évitant le stockage en texte brut

Les mots de passe sont les clés de votre royaume et ne doivent jamais être stockés en texte clair. Même les personnes internes d'une organisation ne devraient pas avoir accès à un vaste référentiel de mots de passe non protégé, et ce protocole commercial ne devrait pas non plus être accepté (il existe de nombreux gestionnaires de mots de passe qui autorisent le partage d'informations d'identification cryptées de nos jours, aucune excuse !). Il existe également le risque que des initiés malveillants espionnent des fichiers et y accèdent là où ils ne devraient pas.

Et en cas d'attaque extérieure, imaginez le double inconvénient qui pourrait survenir si une porte dérobée vers votre base de données est découverte grâce à une simple faille d'injection SQL, et si l'utilisateur accède au répertoire dans lequel les mots de passe sont également stockés. Vous pensez qu'il s'agit d'un trop grand nombre d'étapes truffées d'erreurs pour porter leurs fruits ? Malheureusement, ce scénario exact s'est produit en L'infraction commise par Sony en 2011. Plus d'un million de mots de passe clients ont été stockés en texte clair, et le groupe de hackers Lulzsec a accédé à ces mots de passe et à bien d'autres encore grâce à une attaque par injection SQL courante.

Tous les mots de passe doivent être protégés par toutes les défenses disponibles dans le cadre de support. Pour Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers modèles. Il est recommandé d'utiliser un stockage sécurisé comme AWS Secrets Manager ou Azure Key Vault, selon le fournisseur d'infrastructure.

Forcer les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part sur le backend. Garder les mots de passe hors du stockage en texte brut contribuera grandement à protéger vos utilisateurs et vos systèmes. Le principal danger du stockage des mots de passe en clair est le mauvais contrôle d'accès ; en fait, tout le monde peut les voir. Il est impératif (en particulier dans un environnement IaC où soudainement de plus en plus de personnes ont accès à des informations sensibles) que celles-ci soient correctement hachées et que seules les personnes qui en ont absolument besoin y aient accès y soient autorisées.

Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayez une démo IaC challenge au sein de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.


Afficher la ressource
Afficher la ressource

Remplissez le formulaire ci-dessous pour télécharger le rapport

Nous aimerions avoir votre autorisation pour vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
scw success icon
scw error icon
Pour soumettre le formulaire, veuillez activer les cookies « Analytics ». N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

En ce qui concerne le déploiement d'une infrastructure sécurisée sous forme de code dans votre propre organisation, comment vous en sortez-vous ? Cela peut être un peu une courbe d'apprentissage, mais apprendre les ficelles du métier sera une excellente occasion d'améliorer vos compétences, de vous démarquer de vos pairs, et protégez davantage les données des utilisateurs finaux.

Avant de commencer ce prochain chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à relever un défi ludique sur la vulnérabilité du stockage de données sensibles ; jouez dès maintenant et choisissez parmi Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment c'était ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, les mots de passe constituent la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, telles que l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.

Nous utilisons tellement de mots de passe que nous avons même des règles sur la façon de les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou même aux devinettes. Bien entendu, certaines personnes utilisent encore des mots de passe faibles, comme en témoigne une récente rapport de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi que tout un tas d'autres mots faciles à deviner comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.

Il y aura toujours ceux qui n'aimeront pas utiliser des mots de passe complexes, mais la plupart des organisations professionnelles obligeront les utilisateurs à créer leurs mots d'accès ou leurs phrases d'une certaine manière. Nous connaissons tous les règles maintenant, les mots de passe devant comporter au moins huit caractères, composés de majuscules et de minuscules, avec au moins un chiffre et un caractère spécial requis.

Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des types de mots de passe les plus sûrs, il se peut qu'ils ne soient pas utiles s'ils sont tous stockés en texte brut. Le mot de passe 12345 est aussi mauvais que Nuts53 ! Spike&Dog12 si un pirate informatique est capable de lire l'intégralité du fichier de mot de passe.

Pourquoi est-il dangereux de stocker des mots de passe en clair ?

Le stockage des mots de passe en texte brut est une mauvaise chose car cela met en danger à la fois le système et les utilisateurs. De toute évidence, le fait qu'un pirate informatique soit capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait une catastrophe. Ils pourraient simplement trouver un utilisateur possédant des informations d'identification d'administrateur et compromettre l'ensemble du système ou du site. Et comme ils utiliseraient des noms d'utilisateur et des mots de passe appropriés, la sécurité interne risque de ne pas détecter l'intrusion ou de la détecter longtemps après que les dommages aient été causés.

Le fait de permettre aux attaquants de voler facilement les mots de passe stockés en texte clair nuit également aux utilisateurs, car de nombreuses personnes réutilisent les mots de passe. Parce que nous avons rendu la création de mots de passe si difficile, de nombreuses personnes ont recours à la réutilisation de mots de passe dont elles peuvent se souvenir sur plusieurs sites. Si un attaquant compromet un fichier de mots de passe, il essaiera certainement d'accéder à d'autres systèmes en utilisant le même nom et le même mot de passe, ce qui expose les utilisateurs à un risque élevé de crimes secondaires.

Il est relativement facile de stocker accidentellement des mots de passe en texte brut ou de ne pas se rendre compte que cela pourrait entraîner des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode couramment utilisée pour stocker les mots de passe lors de la définition d'une ressource AWS à l'aide de modèles Terraform :

ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « s3.cr3t.admin.p2ss »
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le mot de passe utilisé pour gérer l'instance de base de données MySQL dans AWS est stocké en texte brut. Cela signifie que toute personne ayant accès au référentiel de code source peut le lire, voire le copier.

La protection des mots de passe varie en fonction du framework, mais des méthodes de protection existent pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :

ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « $ {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]
}

Dans cet exemple, le modèle Terraform obtiendra le mot de passe du service AWS Secrets Manager et il ne sera jamais stocké en texte brut dans les fichiers modèles.

Protéger les mots de passe en évitant le stockage en texte brut

Les mots de passe sont les clés de votre royaume et ne doivent jamais être stockés en texte clair. Même les personnes internes d'une organisation ne devraient pas avoir accès à un vaste référentiel de mots de passe non protégé, et ce protocole commercial ne devrait pas non plus être accepté (il existe de nombreux gestionnaires de mots de passe qui autorisent le partage d'informations d'identification cryptées de nos jours, aucune excuse !). Il existe également le risque que des initiés malveillants espionnent des fichiers et y accèdent là où ils ne devraient pas.

Et en cas d'attaque extérieure, imaginez le double inconvénient qui pourrait survenir si une porte dérobée vers votre base de données est découverte grâce à une simple faille d'injection SQL, et si l'utilisateur accède au répertoire dans lequel les mots de passe sont également stockés. Vous pensez qu'il s'agit d'un trop grand nombre d'étapes truffées d'erreurs pour porter leurs fruits ? Malheureusement, ce scénario exact s'est produit en L'infraction commise par Sony en 2011. Plus d'un million de mots de passe clients ont été stockés en texte clair, et le groupe de hackers Lulzsec a accédé à ces mots de passe et à bien d'autres encore grâce à une attaque par injection SQL courante.

Tous les mots de passe doivent être protégés par toutes les défenses disponibles dans le cadre de support. Pour Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers modèles. Il est recommandé d'utiliser un stockage sécurisé comme AWS Secrets Manager ou Azure Key Vault, selon le fournisseur d'infrastructure.

Forcer les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part sur le backend. Garder les mots de passe hors du stockage en texte brut contribuera grandement à protéger vos utilisateurs et vos systèmes. Le principal danger du stockage des mots de passe en clair est le mauvais contrôle d'accès ; en fait, tout le monde peut les voir. Il est impératif (en particulier dans un environnement IaC où soudainement de plus en plus de personnes ont accès à des informations sensibles) que celles-ci soient correctement hachées et que seules les personnes qui en ont absolument besoin y aient accès y soient autorisées.

Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayez une démo IaC challenge au sein de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.


Afficher le webinaire
Commencez
learn more

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.

Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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é.

Afficher le rapportRéservez une démo
Télécharger le PDF
Afficher la ressource
Partagez sur :
linkedin brandsSocialx logo
Vous souhaitez en savoir plus ?

Partagez sur :
linkedin brandsSocialx logo
Auteur
Matias Madou, Ph.D.
Published May 18, 2020

Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.

Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.

Partagez sur :
linkedin brandsSocialx logo

En ce qui concerne le déploiement d'une infrastructure sécurisée sous forme de code dans votre propre organisation, comment vous en sortez-vous ? Cela peut être un peu une courbe d'apprentissage, mais apprendre les ficelles du métier sera une excellente occasion d'améliorer vos compétences, de vous démarquer de vos pairs, et protégez davantage les données des utilisateurs finaux.

Avant de commencer ce prochain chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à relever un défi ludique sur la vulnérabilité du stockage de données sensibles ; jouez dès maintenant et choisissez parmi Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment c'était ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, les mots de passe constituent la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, telles que l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.

Nous utilisons tellement de mots de passe que nous avons même des règles sur la façon de les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou même aux devinettes. Bien entendu, certaines personnes utilisent encore des mots de passe faibles, comme en témoigne une récente rapport de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi que tout un tas d'autres mots faciles à deviner comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.

Il y aura toujours ceux qui n'aimeront pas utiliser des mots de passe complexes, mais la plupart des organisations professionnelles obligeront les utilisateurs à créer leurs mots d'accès ou leurs phrases d'une certaine manière. Nous connaissons tous les règles maintenant, les mots de passe devant comporter au moins huit caractères, composés de majuscules et de minuscules, avec au moins un chiffre et un caractère spécial requis.

Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des types de mots de passe les plus sûrs, il se peut qu'ils ne soient pas utiles s'ils sont tous stockés en texte brut. Le mot de passe 12345 est aussi mauvais que Nuts53 ! Spike&Dog12 si un pirate informatique est capable de lire l'intégralité du fichier de mot de passe.

Pourquoi est-il dangereux de stocker des mots de passe en clair ?

Le stockage des mots de passe en texte brut est une mauvaise chose car cela met en danger à la fois le système et les utilisateurs. De toute évidence, le fait qu'un pirate informatique soit capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait une catastrophe. Ils pourraient simplement trouver un utilisateur possédant des informations d'identification d'administrateur et compromettre l'ensemble du système ou du site. Et comme ils utiliseraient des noms d'utilisateur et des mots de passe appropriés, la sécurité interne risque de ne pas détecter l'intrusion ou de la détecter longtemps après que les dommages aient été causés.

Le fait de permettre aux attaquants de voler facilement les mots de passe stockés en texte clair nuit également aux utilisateurs, car de nombreuses personnes réutilisent les mots de passe. Parce que nous avons rendu la création de mots de passe si difficile, de nombreuses personnes ont recours à la réutilisation de mots de passe dont elles peuvent se souvenir sur plusieurs sites. Si un attaquant compromet un fichier de mots de passe, il essaiera certainement d'accéder à d'autres systèmes en utilisant le même nom et le même mot de passe, ce qui expose les utilisateurs à un risque élevé de crimes secondaires.

Il est relativement facile de stocker accidentellement des mots de passe en texte brut ou de ne pas se rendre compte que cela pourrait entraîner des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode couramment utilisée pour stocker les mots de passe lors de la définition d'une ressource AWS à l'aide de modèles Terraform :

ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « s3.cr3t.admin.p2ss »
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le mot de passe utilisé pour gérer l'instance de base de données MySQL dans AWS est stocké en texte brut. Cela signifie que toute personne ayant accès au référentiel de code source peut le lire, voire le copier.

La protection des mots de passe varie en fonction du framework, mais des méthodes de protection existent pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :

ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « $ {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]
}

Dans cet exemple, le modèle Terraform obtiendra le mot de passe du service AWS Secrets Manager et il ne sera jamais stocké en texte brut dans les fichiers modèles.

Protéger les mots de passe en évitant le stockage en texte brut

Les mots de passe sont les clés de votre royaume et ne doivent jamais être stockés en texte clair. Même les personnes internes d'une organisation ne devraient pas avoir accès à un vaste référentiel de mots de passe non protégé, et ce protocole commercial ne devrait pas non plus être accepté (il existe de nombreux gestionnaires de mots de passe qui autorisent le partage d'informations d'identification cryptées de nos jours, aucune excuse !). Il existe également le risque que des initiés malveillants espionnent des fichiers et y accèdent là où ils ne devraient pas.

Et en cas d'attaque extérieure, imaginez le double inconvénient qui pourrait survenir si une porte dérobée vers votre base de données est découverte grâce à une simple faille d'injection SQL, et si l'utilisateur accède au répertoire dans lequel les mots de passe sont également stockés. Vous pensez qu'il s'agit d'un trop grand nombre d'étapes truffées d'erreurs pour porter leurs fruits ? Malheureusement, ce scénario exact s'est produit en L'infraction commise par Sony en 2011. Plus d'un million de mots de passe clients ont été stockés en texte clair, et le groupe de hackers Lulzsec a accédé à ces mots de passe et à bien d'autres encore grâce à une attaque par injection SQL courante.

Tous les mots de passe doivent être protégés par toutes les défenses disponibles dans le cadre de support. Pour Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers modèles. Il est recommandé d'utiliser un stockage sécurisé comme AWS Secrets Manager ou Azure Key Vault, selon le fournisseur d'infrastructure.

Forcer les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part sur le backend. Garder les mots de passe hors du stockage en texte brut contribuera grandement à protéger vos utilisateurs et vos systèmes. Le principal danger du stockage des mots de passe en clair est le mauvais contrôle d'accès ; en fait, tout le monde peut les voir. Il est impératif (en particulier dans un environnement IaC où soudainement de plus en plus de personnes ont accès à des informations sensibles) que celles-ci soient correctement hachées et que seules les personnes qui en ont absolument besoin y aient accès y soient autorisées.

Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayez une démo IaC challenge au sein de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.


Table des matières

Télécharger le PDF
Afficher la ressource
Vous souhaitez en savoir plus ?

Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

learn more

Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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é.

Réservez une démoTélécharger
Partagez sur :
linkedin brandsSocialx logo
Centre de ressources

Ressources pour vous aider à démarrer

Plus de posts
Centre de ressources

Ressources pour vous aider à démarrer

Plus de posts