コーダーがセキュリティインフラを征服するコードシリーズ:パスワードのプレーンテキスト保存

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.