Coders Conquer Security Infrastruktur als Code-Serie: Klartextspeicherung von Passwörtern
Wie sieht es mit der Bereitstellung von sicherer Infrastruktur als Code in Ihrem eigenen Unternehmen aus? Es könnte eine gewisse Lernkurve sein, aber das Erlernen der Grundlagen ist eine großartige Chance, Ihre Fähigkeiten zu verbessern, sich von Ihren Kollegen abzuheben und mehr Endbenutzerdaten sicher zu halten.
Bevor wir mit dem nächsten Kapitel unserer aktuellen "Coders Conquer Security"-Serie beginnen, möchte ich Sie einladen, eine gamifizierte Herausforderung zur Schwachstelle bei der Speicherung sensibler Daten zu spielen; spielen Sie jetzt und wählen Sie zwischen Kubernetes, Terraform, Ansible, Docker oder CloudFormation:
Wie war das? Wenn Ihr Wissen etwas Arbeit braucht, lesen Sie weiter:
Der Schlüssel zu den meisten Computersicherheiten liegt heutzutage in Passwörtern. Selbst wenn andere Sicherheitsmethoden eingesetzt werden, wie z. B. Zwei-Faktor-Authentifizierung oder Biometrie, verwenden die meisten Unternehmen immer noch passwortbasierte Sicherheit als ein Element ihres Schutzes. In vielen Unternehmen werden ausschließlich Passwörter verwendet.
Wir verwenden Passwörter so oft, dass wir sogar Regeln haben, wie sie zu erstellen sind. Dies soll sie weniger anfällig für Brute-Force-Angriffe oder sogar wildes Raten machen. Natürlich verwenden einige Leute immer noch schwache Passwörter, wie ein aktueller Bericht von NordPass zeigt. Es ist schwer zu glauben, dass Menschen im Jahr 2020 immer noch 12345 sowie einen Haufen anderer erratbarer Wörter wie Schokolade, Passwort und Gott verwenden, um ihre sensibelsten Daten zu schützen.
Es wird immer diejenigen geben, denen es egal ist, starke Passwörter zu verwenden, aber die meisten professionellen Organisationen zwingen die Benutzer, ihre Zugangswörter oder -phrasen auf bestimmte Weise zu gestalten. Wir alle kennen inzwischen die Regeln: Passwörter müssen mindestens acht Zeichen lang sein und aus Groß- und Kleinbuchstaben bestehen, wobei mindestens eine Zahl und ein Sonderzeichen erforderlich sind.
Das Schlimme daran ist, dass selbst wenn Benutzer die Regeln für die Erstellung der stärksten Arten von Kennwörtern einhalten, es möglicherweise nichts nützt, wenn sie alle im Klartext gespeichert sind. Das Passwort 12345 ist genauso schlecht wie Nuts53!SpiKe&Dog12, wenn ein Hacker die gesamte Passwortdatei lesen kann.
Warum ist das Speichern von Kennwörtern im Klartext gefährlich?
Das Speichern von Passwörtern im Klartext ist schlecht, weil es sowohl das System als auch die Benutzer gefährdet. Wenn ein Hacker in der Lage wäre, jedes einzelne Kennwort für den Zugriff auf ein System zu finden und zu lesen, wäre das natürlich eine Katastrophe. Er könnte einfach einen Benutzer mit Administrator-Zugangsdaten finden und das gesamte System oder die Website gefährden. Und da sie korrekte Benutzernamen und Passwörter verwenden würden, kann es sein, dass die interne Sicherheit das Eindringen nicht oder erst lange nachdem der Schaden entstanden ist, bemerkt.
Die Tatsache, dass es Angreifern leicht gemacht wird, im Klartext gespeicherte Passwörter zu stehlen, schadet auch den Benutzern, da viele Leute Passwörter wiederverwenden. Weil wir das Erstellen von Passwörtern so schwierig gemacht haben, greifen viele Leute auf die Wiederverwendung von Passwörtern zurück, die sie sich für mehrere Websites merken können. Wenn ein Angreifer eine Kennwortdatei kompromittiert, wird er mit ziemlicher Sicherheit versuchen, mit demselben Namen und Kennwort auf andere Systeme zuzugreifen, was die Benutzer einem großen Risiko von Folgedelikten aussetzt.
Es ist relativ einfach, Passwörter versehentlich im Klartext zu speichern oder nicht zu erkennen, dass dies später zu großen Problemen führen kann. Der folgende Code ist zum Beispiel eine gängige Methode zum Speichern von Passwörtern bei der Definition einer AWS-Ressource mit Terraform-Vorlagen:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
In diesem Beispiel wird das Passwort, das zur Verwaltung der MySQL-Datenbankinstanz in AWS verwendet wird, im Klartext gespeichert. Das bedeutet, dass jeder mit Zugriff auf das Quellcode-Repository es lesen oder sogar kopieren könnte.
Der Schutz von Passwörtern variiert je nach Framework, aber es gibt Schutzmethoden für jede Plattform. Zum Beispiel kann das MySQL-Passwort in einem sicheren Speicher wie AWS Secrets Manager gespeichert werden:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
In diesem Beispiel erhält die Terraform-Vorlage das Passwort vom AWS Secrets Manager Service und es wird niemals im Klartext in Vorlagendateien gespeichert.
Schutz von Passwörtern durch Vermeidung von Klartextspeicherung
Passwörter sind die Schlüssel zu Ihrem Königreich und sollten niemals im Klartext gespeichert werden. Selbst die internen Mitarbeiter einer Organisation sollten keinen Zugriff auf ein großes, ungeschütztes Repository von Passwörtern haben, und dies sollte auch kein akzeptiertes Geschäftsprotokoll sein (es gibt heutzutage viele Passwort-Manager, die eine verschlüsselte Freigabe von Zugangsdaten ermöglichen - keine Ausreden!) Es besteht auch die Gefahr, dass böswillige Insider Dateien ausspähen und sich Zugang verschaffen, wo sie nicht hingehören.
Und bei einem Angriff von außen, stellen Sie sich nur den doppelten Hammer vor, der möglich ist, wenn eine Hintertür zu Ihrer Datenbank durch etwas so einfaches wie eine SQL-Injection-Schwachstelle gefunden wird, und sie auch noch Zugriff auf das Verzeichnis erhalten, in dem die Passwörter gespeichert sind. Denken Sie, dass dies zu viele fehlerbehaftete Schritte sind, um zum Erfolg zu führen? Traurigerweise passierte genau dieses Szenario bei Sonys Einbruch 2011. Über eine Million Kundenpasswörter wurden im Klartext gespeichert, und die Hackergruppe Lulzsec erlangte durch einen gewöhnlichen SQL-Injection-Angriff Zugriff auf diese und noch viel mehr.
Alle Passwörter sollten durch die im unterstützenden Framework verfügbaren Schutzmechanismen geschützt werden. Für Terraform sollten Passwörter niemals in Vorlagendateien gespeichert werden. Es wird empfohlen, einen sicheren Speicher wie AWS Secrets Manager oder Azure Key Vault zu verwenden, je nach Infrastrukturanbieter.
Benutzer zu zwingen, sichere Passwörter zu erstellen, ist eine gute Idee, aber dann müssen Sie auch Ihren Teil am Backend tun. Wenn Sie Passwörter nicht im Klartext speichern, tragen Sie viel zum Schutz Ihrer Benutzer und Ihrer Systeme bei. Die Hauptgefahr bei der Speicherung von Klartext-Passwörtern ist die schlechte Zugriffskontrolle; im Grunde kann jeder sie sehen. Es ist zwingend erforderlich (besonders in einer IaC-Umgebung, wo plötzlich mehr Leute Zugang zu sensiblen Informationen haben), dass sie angemessen gehasht werden und nur diejenigen, die unbedingt Zugang benötigen, diesen auch erhalten.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken und Schwachstellen schützen können. Sie können auch eine Demo-IaC-Herausforderung innerhalb der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.


Der Schlüssel zu den meisten Computersicherheiten liegt heutzutage in Passwörtern. Selbst wenn andere Sicherheitsmethoden eingesetzt werden, wie z. B. Zwei-Faktor-Authentifizierung oder Biometrie, verwenden die meisten Organisationen immer noch passwortbasierte Sicherheit als ein Element ihres Schutzes.
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.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenMatias 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.


Wie sieht es mit der Bereitstellung von sicherer Infrastruktur als Code in Ihrem eigenen Unternehmen aus? Es könnte eine gewisse Lernkurve sein, aber das Erlernen der Grundlagen ist eine großartige Chance, Ihre Fähigkeiten zu verbessern, sich von Ihren Kollegen abzuheben und mehr Endbenutzerdaten sicher zu halten.
Bevor wir mit dem nächsten Kapitel unserer aktuellen "Coders Conquer Security"-Serie beginnen, möchte ich Sie einladen, eine gamifizierte Herausforderung zur Schwachstelle bei der Speicherung sensibler Daten zu spielen; spielen Sie jetzt und wählen Sie zwischen Kubernetes, Terraform, Ansible, Docker oder CloudFormation:
Wie war das? Wenn Ihr Wissen etwas Arbeit braucht, lesen Sie weiter:
Der Schlüssel zu den meisten Computersicherheiten liegt heutzutage in Passwörtern. Selbst wenn andere Sicherheitsmethoden eingesetzt werden, wie z. B. Zwei-Faktor-Authentifizierung oder Biometrie, verwenden die meisten Unternehmen immer noch passwortbasierte Sicherheit als ein Element ihres Schutzes. In vielen Unternehmen werden ausschließlich Passwörter verwendet.
Wir verwenden Passwörter so oft, dass wir sogar Regeln haben, wie sie zu erstellen sind. Dies soll sie weniger anfällig für Brute-Force-Angriffe oder sogar wildes Raten machen. Natürlich verwenden einige Leute immer noch schwache Passwörter, wie ein aktueller Bericht von NordPass zeigt. Es ist schwer zu glauben, dass Menschen im Jahr 2020 immer noch 12345 sowie einen Haufen anderer erratbarer Wörter wie Schokolade, Passwort und Gott verwenden, um ihre sensibelsten Daten zu schützen.
Es wird immer diejenigen geben, denen es egal ist, starke Passwörter zu verwenden, aber die meisten professionellen Organisationen zwingen die Benutzer, ihre Zugangswörter oder -phrasen auf bestimmte Weise zu gestalten. Wir alle kennen inzwischen die Regeln: Passwörter müssen mindestens acht Zeichen lang sein und aus Groß- und Kleinbuchstaben bestehen, wobei mindestens eine Zahl und ein Sonderzeichen erforderlich sind.
Das Schlimme daran ist, dass selbst wenn Benutzer die Regeln für die Erstellung der stärksten Arten von Kennwörtern einhalten, es möglicherweise nichts nützt, wenn sie alle im Klartext gespeichert sind. Das Passwort 12345 ist genauso schlecht wie Nuts53!SpiKe&Dog12, wenn ein Hacker die gesamte Passwortdatei lesen kann.
Warum ist das Speichern von Kennwörtern im Klartext gefährlich?
Das Speichern von Passwörtern im Klartext ist schlecht, weil es sowohl das System als auch die Benutzer gefährdet. Wenn ein Hacker in der Lage wäre, jedes einzelne Kennwort für den Zugriff auf ein System zu finden und zu lesen, wäre das natürlich eine Katastrophe. Er könnte einfach einen Benutzer mit Administrator-Zugangsdaten finden und das gesamte System oder die Website gefährden. Und da sie korrekte Benutzernamen und Passwörter verwenden würden, kann es sein, dass die interne Sicherheit das Eindringen nicht oder erst lange nachdem der Schaden entstanden ist, bemerkt.
Die Tatsache, dass es Angreifern leicht gemacht wird, im Klartext gespeicherte Passwörter zu stehlen, schadet auch den Benutzern, da viele Leute Passwörter wiederverwenden. Weil wir das Erstellen von Passwörtern so schwierig gemacht haben, greifen viele Leute auf die Wiederverwendung von Passwörtern zurück, die sie sich für mehrere Websites merken können. Wenn ein Angreifer eine Kennwortdatei kompromittiert, wird er mit ziemlicher Sicherheit versuchen, mit demselben Namen und Kennwort auf andere Systeme zuzugreifen, was die Benutzer einem großen Risiko von Folgedelikten aussetzt.
Es ist relativ einfach, Passwörter versehentlich im Klartext zu speichern oder nicht zu erkennen, dass dies später zu großen Problemen führen kann. Der folgende Code ist zum Beispiel eine gängige Methode zum Speichern von Passwörtern bei der Definition einer AWS-Ressource mit Terraform-Vorlagen:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
In diesem Beispiel wird das Passwort, das zur Verwaltung der MySQL-Datenbankinstanz in AWS verwendet wird, im Klartext gespeichert. Das bedeutet, dass jeder mit Zugriff auf das Quellcode-Repository es lesen oder sogar kopieren könnte.
Der Schutz von Passwörtern variiert je nach Framework, aber es gibt Schutzmethoden für jede Plattform. Zum Beispiel kann das MySQL-Passwort in einem sicheren Speicher wie AWS Secrets Manager gespeichert werden:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
In diesem Beispiel erhält die Terraform-Vorlage das Passwort vom AWS Secrets Manager Service und es wird niemals im Klartext in Vorlagendateien gespeichert.
Schutz von Passwörtern durch Vermeidung von Klartextspeicherung
Passwörter sind die Schlüssel zu Ihrem Königreich und sollten niemals im Klartext gespeichert werden. Selbst die internen Mitarbeiter einer Organisation sollten keinen Zugriff auf ein großes, ungeschütztes Repository von Passwörtern haben, und dies sollte auch kein akzeptiertes Geschäftsprotokoll sein (es gibt heutzutage viele Passwort-Manager, die eine verschlüsselte Freigabe von Zugangsdaten ermöglichen - keine Ausreden!) Es besteht auch die Gefahr, dass böswillige Insider Dateien ausspähen und sich Zugang verschaffen, wo sie nicht hingehören.
Und bei einem Angriff von außen, stellen Sie sich nur den doppelten Hammer vor, der möglich ist, wenn eine Hintertür zu Ihrer Datenbank durch etwas so einfaches wie eine SQL-Injection-Schwachstelle gefunden wird, und sie auch noch Zugriff auf das Verzeichnis erhalten, in dem die Passwörter gespeichert sind. Denken Sie, dass dies zu viele fehlerbehaftete Schritte sind, um zum Erfolg zu führen? Traurigerweise passierte genau dieses Szenario bei Sonys Einbruch 2011. Über eine Million Kundenpasswörter wurden im Klartext gespeichert, und die Hackergruppe Lulzsec erlangte durch einen gewöhnlichen SQL-Injection-Angriff Zugriff auf diese und noch viel mehr.
Alle Passwörter sollten durch die im unterstützenden Framework verfügbaren Schutzmechanismen geschützt werden. Für Terraform sollten Passwörter niemals in Vorlagendateien gespeichert werden. Es wird empfohlen, einen sicheren Speicher wie AWS Secrets Manager oder Azure Key Vault zu verwenden, je nach Infrastrukturanbieter.
Benutzer zu zwingen, sichere Passwörter zu erstellen, ist eine gute Idee, aber dann müssen Sie auch Ihren Teil am Backend tun. Wenn Sie Passwörter nicht im Klartext speichern, tragen Sie viel zum Schutz Ihrer Benutzer und Ihrer Systeme bei. Die Hauptgefahr bei der Speicherung von Klartext-Passwörtern ist die schlechte Zugriffskontrolle; im Grunde kann jeder sie sehen. Es ist zwingend erforderlich (besonders in einer IaC-Umgebung, wo plötzlich mehr Leute Zugang zu sensiblen Informationen haben), dass sie angemessen gehasht werden und nur diejenigen, die unbedingt Zugang benötigen, diesen auch erhalten.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken und Schwachstellen schützen können. Sie können auch eine Demo-IaC-Herausforderung innerhalb der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.

Wie sieht es mit der Bereitstellung von sicherer Infrastruktur als Code in Ihrem eigenen Unternehmen aus? Es könnte eine gewisse Lernkurve sein, aber das Erlernen der Grundlagen ist eine großartige Chance, Ihre Fähigkeiten zu verbessern, sich von Ihren Kollegen abzuheben und mehr Endbenutzerdaten sicher zu halten.
Bevor wir mit dem nächsten Kapitel unserer aktuellen "Coders Conquer Security"-Serie beginnen, möchte ich Sie einladen, eine gamifizierte Herausforderung zur Schwachstelle bei der Speicherung sensibler Daten zu spielen; spielen Sie jetzt und wählen Sie zwischen Kubernetes, Terraform, Ansible, Docker oder CloudFormation:
Wie war das? Wenn Ihr Wissen etwas Arbeit braucht, lesen Sie weiter:
Der Schlüssel zu den meisten Computersicherheiten liegt heutzutage in Passwörtern. Selbst wenn andere Sicherheitsmethoden eingesetzt werden, wie z. B. Zwei-Faktor-Authentifizierung oder Biometrie, verwenden die meisten Unternehmen immer noch passwortbasierte Sicherheit als ein Element ihres Schutzes. In vielen Unternehmen werden ausschließlich Passwörter verwendet.
Wir verwenden Passwörter so oft, dass wir sogar Regeln haben, wie sie zu erstellen sind. Dies soll sie weniger anfällig für Brute-Force-Angriffe oder sogar wildes Raten machen. Natürlich verwenden einige Leute immer noch schwache Passwörter, wie ein aktueller Bericht von NordPass zeigt. Es ist schwer zu glauben, dass Menschen im Jahr 2020 immer noch 12345 sowie einen Haufen anderer erratbarer Wörter wie Schokolade, Passwort und Gott verwenden, um ihre sensibelsten Daten zu schützen.
Es wird immer diejenigen geben, denen es egal ist, starke Passwörter zu verwenden, aber die meisten professionellen Organisationen zwingen die Benutzer, ihre Zugangswörter oder -phrasen auf bestimmte Weise zu gestalten. Wir alle kennen inzwischen die Regeln: Passwörter müssen mindestens acht Zeichen lang sein und aus Groß- und Kleinbuchstaben bestehen, wobei mindestens eine Zahl und ein Sonderzeichen erforderlich sind.
Das Schlimme daran ist, dass selbst wenn Benutzer die Regeln für die Erstellung der stärksten Arten von Kennwörtern einhalten, es möglicherweise nichts nützt, wenn sie alle im Klartext gespeichert sind. Das Passwort 12345 ist genauso schlecht wie Nuts53!SpiKe&Dog12, wenn ein Hacker die gesamte Passwortdatei lesen kann.
Warum ist das Speichern von Kennwörtern im Klartext gefährlich?
Das Speichern von Passwörtern im Klartext ist schlecht, weil es sowohl das System als auch die Benutzer gefährdet. Wenn ein Hacker in der Lage wäre, jedes einzelne Kennwort für den Zugriff auf ein System zu finden und zu lesen, wäre das natürlich eine Katastrophe. Er könnte einfach einen Benutzer mit Administrator-Zugangsdaten finden und das gesamte System oder die Website gefährden. Und da sie korrekte Benutzernamen und Passwörter verwenden würden, kann es sein, dass die interne Sicherheit das Eindringen nicht oder erst lange nachdem der Schaden entstanden ist, bemerkt.
Die Tatsache, dass es Angreifern leicht gemacht wird, im Klartext gespeicherte Passwörter zu stehlen, schadet auch den Benutzern, da viele Leute Passwörter wiederverwenden. Weil wir das Erstellen von Passwörtern so schwierig gemacht haben, greifen viele Leute auf die Wiederverwendung von Passwörtern zurück, die sie sich für mehrere Websites merken können. Wenn ein Angreifer eine Kennwortdatei kompromittiert, wird er mit ziemlicher Sicherheit versuchen, mit demselben Namen und Kennwort auf andere Systeme zuzugreifen, was die Benutzer einem großen Risiko von Folgedelikten aussetzt.
Es ist relativ einfach, Passwörter versehentlich im Klartext zu speichern oder nicht zu erkennen, dass dies später zu großen Problemen führen kann. Der folgende Code ist zum Beispiel eine gängige Methode zum Speichern von Passwörtern bei der Definition einer AWS-Ressource mit Terraform-Vorlagen:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
In diesem Beispiel wird das Passwort, das zur Verwaltung der MySQL-Datenbankinstanz in AWS verwendet wird, im Klartext gespeichert. Das bedeutet, dass jeder mit Zugriff auf das Quellcode-Repository es lesen oder sogar kopieren könnte.
Der Schutz von Passwörtern variiert je nach Framework, aber es gibt Schutzmethoden für jede Plattform. Zum Beispiel kann das MySQL-Passwort in einem sicheren Speicher wie AWS Secrets Manager gespeichert werden:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
In diesem Beispiel erhält die Terraform-Vorlage das Passwort vom AWS Secrets Manager Service und es wird niemals im Klartext in Vorlagendateien gespeichert.
Schutz von Passwörtern durch Vermeidung von Klartextspeicherung
Passwörter sind die Schlüssel zu Ihrem Königreich und sollten niemals im Klartext gespeichert werden. Selbst die internen Mitarbeiter einer Organisation sollten keinen Zugriff auf ein großes, ungeschütztes Repository von Passwörtern haben, und dies sollte auch kein akzeptiertes Geschäftsprotokoll sein (es gibt heutzutage viele Passwort-Manager, die eine verschlüsselte Freigabe von Zugangsdaten ermöglichen - keine Ausreden!) Es besteht auch die Gefahr, dass böswillige Insider Dateien ausspähen und sich Zugang verschaffen, wo sie nicht hingehören.
Und bei einem Angriff von außen, stellen Sie sich nur den doppelten Hammer vor, der möglich ist, wenn eine Hintertür zu Ihrer Datenbank durch etwas so einfaches wie eine SQL-Injection-Schwachstelle gefunden wird, und sie auch noch Zugriff auf das Verzeichnis erhalten, in dem die Passwörter gespeichert sind. Denken Sie, dass dies zu viele fehlerbehaftete Schritte sind, um zum Erfolg zu führen? Traurigerweise passierte genau dieses Szenario bei Sonys Einbruch 2011. Über eine Million Kundenpasswörter wurden im Klartext gespeichert, und die Hackergruppe Lulzsec erlangte durch einen gewöhnlichen SQL-Injection-Angriff Zugriff auf diese und noch viel mehr.
Alle Passwörter sollten durch die im unterstützenden Framework verfügbaren Schutzmechanismen geschützt werden. Für Terraform sollten Passwörter niemals in Vorlagendateien gespeichert werden. Es wird empfohlen, einen sicheren Speicher wie AWS Secrets Manager oder Azure Key Vault zu verwenden, je nach Infrastrukturanbieter.
Benutzer zu zwingen, sichere Passwörter zu erstellen, ist eine gute Idee, aber dann müssen Sie auch Ihren Teil am Backend tun. Wenn Sie Passwörter nicht im Klartext speichern, tragen Sie viel zum Schutz Ihrer Benutzer und Ihrer Systeme bei. Die Hauptgefahr bei der Speicherung von Klartext-Passwörtern ist die schlechte Zugriffskontrolle; im Grunde kann jeder sie sehen. Es ist zwingend erforderlich (besonders in einer IaC-Umgebung, wo plötzlich mehr Leute Zugang zu sensiblen Informationen haben), dass sie angemessen gehasht werden und nur diejenigen, die unbedingt Zugang benötigen, diesen auch erhalten.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken und Schwachstellen schützen können. Sie können auch eine Demo-IaC-Herausforderung innerhalb der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.

Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchenMatias 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.
Wie sieht es mit der Bereitstellung von sicherer Infrastruktur als Code in Ihrem eigenen Unternehmen aus? Es könnte eine gewisse Lernkurve sein, aber das Erlernen der Grundlagen ist eine großartige Chance, Ihre Fähigkeiten zu verbessern, sich von Ihren Kollegen abzuheben und mehr Endbenutzerdaten sicher zu halten.
Bevor wir mit dem nächsten Kapitel unserer aktuellen "Coders Conquer Security"-Serie beginnen, möchte ich Sie einladen, eine gamifizierte Herausforderung zur Schwachstelle bei der Speicherung sensibler Daten zu spielen; spielen Sie jetzt und wählen Sie zwischen Kubernetes, Terraform, Ansible, Docker oder CloudFormation:
Wie war das? Wenn Ihr Wissen etwas Arbeit braucht, lesen Sie weiter:
Der Schlüssel zu den meisten Computersicherheiten liegt heutzutage in Passwörtern. Selbst wenn andere Sicherheitsmethoden eingesetzt werden, wie z. B. Zwei-Faktor-Authentifizierung oder Biometrie, verwenden die meisten Unternehmen immer noch passwortbasierte Sicherheit als ein Element ihres Schutzes. In vielen Unternehmen werden ausschließlich Passwörter verwendet.
Wir verwenden Passwörter so oft, dass wir sogar Regeln haben, wie sie zu erstellen sind. Dies soll sie weniger anfällig für Brute-Force-Angriffe oder sogar wildes Raten machen. Natürlich verwenden einige Leute immer noch schwache Passwörter, wie ein aktueller Bericht von NordPass zeigt. Es ist schwer zu glauben, dass Menschen im Jahr 2020 immer noch 12345 sowie einen Haufen anderer erratbarer Wörter wie Schokolade, Passwort und Gott verwenden, um ihre sensibelsten Daten zu schützen.
Es wird immer diejenigen geben, denen es egal ist, starke Passwörter zu verwenden, aber die meisten professionellen Organisationen zwingen die Benutzer, ihre Zugangswörter oder -phrasen auf bestimmte Weise zu gestalten. Wir alle kennen inzwischen die Regeln: Passwörter müssen mindestens acht Zeichen lang sein und aus Groß- und Kleinbuchstaben bestehen, wobei mindestens eine Zahl und ein Sonderzeichen erforderlich sind.
Das Schlimme daran ist, dass selbst wenn Benutzer die Regeln für die Erstellung der stärksten Arten von Kennwörtern einhalten, es möglicherweise nichts nützt, wenn sie alle im Klartext gespeichert sind. Das Passwort 12345 ist genauso schlecht wie Nuts53!SpiKe&Dog12, wenn ein Hacker die gesamte Passwortdatei lesen kann.
Warum ist das Speichern von Kennwörtern im Klartext gefährlich?
Das Speichern von Passwörtern im Klartext ist schlecht, weil es sowohl das System als auch die Benutzer gefährdet. Wenn ein Hacker in der Lage wäre, jedes einzelne Kennwort für den Zugriff auf ein System zu finden und zu lesen, wäre das natürlich eine Katastrophe. Er könnte einfach einen Benutzer mit Administrator-Zugangsdaten finden und das gesamte System oder die Website gefährden. Und da sie korrekte Benutzernamen und Passwörter verwenden würden, kann es sein, dass die interne Sicherheit das Eindringen nicht oder erst lange nachdem der Schaden entstanden ist, bemerkt.
Die Tatsache, dass es Angreifern leicht gemacht wird, im Klartext gespeicherte Passwörter zu stehlen, schadet auch den Benutzern, da viele Leute Passwörter wiederverwenden. Weil wir das Erstellen von Passwörtern so schwierig gemacht haben, greifen viele Leute auf die Wiederverwendung von Passwörtern zurück, die sie sich für mehrere Websites merken können. Wenn ein Angreifer eine Kennwortdatei kompromittiert, wird er mit ziemlicher Sicherheit versuchen, mit demselben Namen und Kennwort auf andere Systeme zuzugreifen, was die Benutzer einem großen Risiko von Folgedelikten aussetzt.
Es ist relativ einfach, Passwörter versehentlich im Klartext zu speichern oder nicht zu erkennen, dass dies später zu großen Problemen führen kann. Der folgende Code ist zum Beispiel eine gängige Methode zum Speichern von Passwörtern bei der Definition einer AWS-Ressource mit Terraform-Vorlagen:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
In diesem Beispiel wird das Passwort, das zur Verwaltung der MySQL-Datenbankinstanz in AWS verwendet wird, im Klartext gespeichert. Das bedeutet, dass jeder mit Zugriff auf das Quellcode-Repository es lesen oder sogar kopieren könnte.
Der Schutz von Passwörtern variiert je nach Framework, aber es gibt Schutzmethoden für jede Plattform. Zum Beispiel kann das MySQL-Passwort in einem sicheren Speicher wie AWS Secrets Manager gespeichert werden:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
In diesem Beispiel erhält die Terraform-Vorlage das Passwort vom AWS Secrets Manager Service und es wird niemals im Klartext in Vorlagendateien gespeichert.
Schutz von Passwörtern durch Vermeidung von Klartextspeicherung
Passwörter sind die Schlüssel zu Ihrem Königreich und sollten niemals im Klartext gespeichert werden. Selbst die internen Mitarbeiter einer Organisation sollten keinen Zugriff auf ein großes, ungeschütztes Repository von Passwörtern haben, und dies sollte auch kein akzeptiertes Geschäftsprotokoll sein (es gibt heutzutage viele Passwort-Manager, die eine verschlüsselte Freigabe von Zugangsdaten ermöglichen - keine Ausreden!) Es besteht auch die Gefahr, dass böswillige Insider Dateien ausspähen und sich Zugang verschaffen, wo sie nicht hingehören.
Und bei einem Angriff von außen, stellen Sie sich nur den doppelten Hammer vor, der möglich ist, wenn eine Hintertür zu Ihrer Datenbank durch etwas so einfaches wie eine SQL-Injection-Schwachstelle gefunden wird, und sie auch noch Zugriff auf das Verzeichnis erhalten, in dem die Passwörter gespeichert sind. Denken Sie, dass dies zu viele fehlerbehaftete Schritte sind, um zum Erfolg zu führen? Traurigerweise passierte genau dieses Szenario bei Sonys Einbruch 2011. Über eine Million Kundenpasswörter wurden im Klartext gespeichert, und die Hackergruppe Lulzsec erlangte durch einen gewöhnlichen SQL-Injection-Angriff Zugriff auf diese und noch viel mehr.
Alle Passwörter sollten durch die im unterstützenden Framework verfügbaren Schutzmechanismen geschützt werden. Für Terraform sollten Passwörter niemals in Vorlagendateien gespeichert werden. Es wird empfohlen, einen sicheren Speicher wie AWS Secrets Manager oder Azure Key Vault zu verwenden, je nach Infrastrukturanbieter.
Benutzer zu zwingen, sichere Passwörter zu erstellen, ist eine gute Idee, aber dann müssen Sie auch Ihren Teil am Backend tun. Wenn Sie Passwörter nicht im Klartext speichern, tragen Sie viel zum Schutz Ihrer Benutzer und Ihrer Systeme bei. Die Hauptgefahr bei der Speicherung von Klartext-Passwörtern ist die schlechte Zugriffskontrolle; im Grunde kann jeder sie sehen. Es ist zwingend erforderlich (besonders in einer IaC-Umgebung, wo plötzlich mehr Leute Zugang zu sensiblen Informationen haben), dass sie angemessen gehasht werden und nur diejenigen, die unbedingt Zugang benötigen, diesen auch erhalten.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken und Schwachstellen schützen können. Sie können auch eine Demo-IaC-Herausforderung innerhalb der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.
Inhaltsübersicht
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.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Sicher durch Design: Definition von Best Practices, Befähigung von Entwicklern und Benchmarking von präventiven Sicherheitsergebnissen
In diesem Forschungspapier werden die Mitbegründer von Secure Code Warrior , Pieter Danhieux und Dr. Matias Madou, Ph.D., zusammen mit den Experten Chris Inglis, ehemaliger US National Cyber Director (jetzt strategischer Berater der Paladin Capital Group), und Devin Lynch, Senior Director, Paladin Global Institute, die wichtigsten Erkenntnisse aus mehr als zwanzig ausführlichen Interviews mit Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, ein VP of Application Security und Software-Sicherheitsexperten, offenlegen.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Ressourcen für den Einstieg
Aufgedeckt: Wie die Cyber-Industrie "Secure by Design" definiert
In unserem neuesten Whitepaper haben sich unsere Mitbegründer Pieter Danhieux und Dr. Matias Madou, Ph.D., mit über zwanzig Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, AppSec-Leiter und Sicherheitsexperten, zusammengesetzt, um die wichtigsten Teile dieses Puzzles herauszufinden und die Realität hinter der Secure by Design-Bewegung aufzudecken. Die Sicherheitsteams haben ein gemeinsames Ziel, aber kein gemeinsames Regelwerk.
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.