Blog

Coders Conquer Security Infrastruktur als Code-Serie: Klartextspeicherung von Passwörtern

Matias Madou, Ph.D.
Veröffentlicht Mai 18, 2020

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.


Ressource anzeigen
Ressource anzeigen

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.

Interessiert an mehr?

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 buchen
Weitergeben:
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.

Weitergeben:

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.


Ressource anzeigen
Ressource anzeigen

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

Wir bitten Sie um Ihre Erlaubnis, Ihnen Informationen über unsere Produkte und/oder verwandte Themen der sicheren Codierung zuzusenden. Wir werden Ihre persönlichen Daten immer mit äußerster Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Senden
Um das Formular abzuschicken, aktivieren Sie bitte "Analytics"-Cookies. Sie können die Cookies wieder deaktivieren, sobald Sie fertig sind.

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.


Auf Ressource zugreifen

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 buchen
PDF herunterladen
Ressource anzeigen
Weitergeben:
Interessiert an mehr?

Weitergeben:
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.

Weitergeben:

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

PDF herunterladen
Ressource anzeigen
Interessiert an mehr?

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 buchenHerunterladen
Weitergeben:
Ressourcendrehscheibe

Ressourcen für den Einstieg

Mehr Beiträge
Ressourcendrehscheibe

Ressourcen für den Einstieg

Mehr Beiträge