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
Die Leistungsfähigkeit von OpenText Fortify + Secure Code Warrior
OpenText Fortify und Secure Code Warrior bündeln ihre Kräfte, um Unternehmen dabei zu helfen, Risiken zu reduzieren, Entwickler zu Sicherheits-Champions zu machen und Kundenvertrauen aufzubauen. Lesen Sie hier mehr darüber.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Die Secure-by-Design-Bewegung ist die Zukunft der sicheren Softwareentwicklung. Erfahren Sie mehr über die wichtigsten Elemente, die Unternehmen berücksichtigen müssen, wenn sie über eine Secure-by-Design-Initiative nachdenken.
Ressourcen für den Einstieg
10 wichtige Vorhersagen: Secure Code Warrior über den Einfluss von KI und Secure-by-Design im Jahr 2025
Unternehmen stehen vor schwierigen Entscheidungen über den Einsatz von KI, um die langfristige Produktivität, Nachhaltigkeit und den Sicherheits-ROI zu unterstützen. In den letzten Jahren ist uns klar geworden, dass KI die Rolle des Entwicklers niemals vollständig ersetzen wird. Von KI + Entwicklerpartnerschaften bis hin zum zunehmenden Druck (und der Verwirrung) rund um die Secure-by-Design-Erwartungen - lassen Sie uns einen genaueren Blick darauf werfen, was wir im nächsten Jahr erwarten können.
OWASP Top 10 für LLM-Bewerbungen: Was ist neu, was hat sich geändert, und wie bleibt man sicher?
Bleiben Sie bei der Absicherung von LLM-Anwendungen mit den neuesten OWASP Top 10 Updates immer einen Schritt voraus. Entdecken Sie, was neu ist, was sich geändert hat und wie Secure Code Warrior Sie mit aktuellen Lernressourcen ausstattet, um Risiken in der generativen KI zu minimieren.
Trust Score zeigt den Wert von Secure-by-Design-Upskilling-Initiativen
Unsere Forschung hat gezeigt, dass Schulungen für sicheren Code funktionieren. Trust Score verwendet einen Algorithmus, der auf mehr als 20 Millionen Lerndaten aus der Arbeit von mehr als 250.000 Lernenden in über 600 Organisationen basiert, und zeigt, wie effektiv die Initiative ist, um Schwachstellen zu beseitigen und wie man sie noch effektiver gestalten kann.
Reaktive versus präventive Sicherheit: Prävention ist das bessere Heilmittel
Der Gedanke, Legacy-Code und -Systeme zur gleichen Zeit wie neuere Anwendungen mit präventiver Sicherheit auszustatten, kann entmutigend erscheinen, aber ein Secure-by-Design-Ansatz, der durch die Weiterbildung von Entwicklern durchgesetzt wird, kann die besten Sicherheitsverfahren auf diese Systeme anwenden. Dies ist für viele Unternehmen die beste Chance, ihre Sicherheitslage zu verbessern.