SCW-Symbole
Held-Hintergrund ohne Trennlinie
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.
Veröffentlicht Mai 18, 2020
Zuletzt aktualisiert am 08. März 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.


Ressource anzeigen
Ressource anzeigen

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.

Möchten Sie mehr erfahren?

Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

mehr erfahren

Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Demo buchen
Teilen auf:
LinkedIn-MarkenSozialx Logo
Autor
Matias Madou, Ph.D.
Veröffentlicht Mai 18, 2020

Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.

Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.

Teilen auf:
LinkedIn-MarkenSozialx 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.


Ressource anzeigen
Ressource anzeigen

Füllen Sie das untenstehende Formular aus, um den Bericht herunterzuladen.

Wir möchten Ihre Einwilligung einholen, um Ihnen Informationen zu unseren Produkten und/oder zu Themen im Zusammenhang mit sicherer Verschlüsselung zuzusenden. Wir werden Ihre personenbezogenen Daten stets mit größter Sorgfalt behandeln und niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Einreichen
scw Erfolgssymbol
scw-Fehlersymbol
Um das Formular zu senden, aktivieren Sie bitte die „Analytics“-Cookies. Sie können diese nach Abschluss des Vorgangs wieder deaktivieren.

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.


Webinar anzeigen
Beginnen Sie
mehr erfahren

Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.

Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Bericht anzeigenDemo buchen
PDF herunterladen
Ressource anzeigen
Teilen auf:
LinkedIn-MarkenSozialx Logo
Möchten Sie mehr erfahren?

Teilen auf:
LinkedIn-MarkenSozialx Logo
Autor
Matias Madou, Ph.D.
Veröffentlicht Mai 18, 2020

Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.

Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.

Teilen auf:
LinkedIn-MarkenSozialx 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.


Inhaltsverzeichnis

PDF herunterladen
Ressource anzeigen
Möchten Sie mehr erfahren?

Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

mehr erfahren

Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Demo buchenHerunterladen
Teilen auf:
LinkedIn-MarkenSozialx Logo
Ressourcenzentrum

Ressourcen, die Ihnen den Einstieg erleichtern

Weitere Beiträge
Ressourcenzentrum

Ressourcen, die Ihnen den Einstieg erleichtern

Weitere Beiträge