Warum char[] besser als String für Passwörter ist? Leitfaden mit Code

Einleitung: Warum ist diese Frage immer noch aktuell?

Stellen Sie sich folgende Situation vor: Sie schreiben eine Anwendung für die Anmeldung. Der Benutzer gibt ein Passwort ein, und Sie müssen es überprüfen. Es scheint am einfachsten, es als String zu speichern. Aber erfahrene Java-Entwickler werden Ihnen sagen: "Verwenden Sie niemals String für Passwörter! Verwenden Sie char[]!". Warum?

Diese Frage ist eine der beliebtesten auf Stack Overflow (über 100.000 Aufrufe). Und es geht nicht darum, dass String keine Zeichen speichern kann. Das Problem ist tiefer: Es betrifft Sicherheit, Speicherverwaltung und Datenlecks. In diesem Artikel werden wir untersuchen, warum char[] für Passwörter der Sicherheitsstandard ist, und anhand von Codebeispielen zeigen, wie man diese Praxis in Java richtig umsetzt.

Wenn Sie gerade erst anfangen, Java zu lernen, oder die Sicherheit Ihrer Anwendungen verbessern möchten, ist dieser Artikel für Sie.

Problem Nr. 1: Unveränderlichkeit von String (Immutability)

Die Klasse String in Java ist unveränderlich (immutable). Das bedeutet, dass nach der Erstellung eines String-Objekts sein Wert nicht mehr geändert werden kann. Jede Operation, die den String "ändert" (z. B. toUpperCase() oder replace()), erstellt tatsächlich ein neues String-Objekt im Speicher.

Warum ist das schlecht für ein Passwort? Schauen wir uns ein Beispiel an:

String password = "MySecret123";// ... Passwort zur Überprüfung verwenden ...// Wir sind mit dem Passwort fertigpassword = null; // "Löschen" der Referenz

Sie denken, Sie hätten den Speicher bereinigt? Nein! Das Objekt "MySecret123" hängt immer noch im Speicher, im sogenannten String Pool. Der Garbage Collector (GC) wird es nicht sofort entfernen. Es wird dort bis zur nächsten Garbage Collection gespeichert, genauer gesagt, solange es Referenzen darauf gibt. Und selbst nach password = null kann das Objekt für unbestimmte Zeit im Speicher verbleiben.

Was ist, wenn ein Angreifer einen Heap-Dump Ihrer Anwendung erhält? Er kann das Passwort im Klartext lesen. Die Unveränderlichkeit von String macht es unmöglich, das Passwort sofort aus dem Speicher zu entfernen.

Problem Nr. 2: String Pool und Passwortlecks

Java optimiert die Arbeit mit Strings durch den String Pool. Wenn Sie einen String mit einem Literal erstellen (z. B. "password"), wird er in den Pool gelegt. Wenn ein anderer Teil des Programms denselben String verwendet, verweist er einfach auf das vorhandene Objekt.

Stellen Sie sich nun vor, Ihr Passwort ist "admin123". Dasselbe Passwort könnte versehentlich irgendwo anders im System verwendet werden (z. B. in Logs, in einem Dateinamen oder in der Konfiguration). Der String "admin123" lebt ewig im Pool (zumindest bis zum Ende der JVM). Dies vergrößert die Angriffsfläche.

// Code, der zu einem Leck führen kannString password = "admin123";System.out.println("Passwort: " + password); // Passwort gelangt in die Logs// Selbst wenn später password = null gesetzt wird, bleibt der String "admin123" in den Logs und im Pool

Mit einem char[]-Array gibt es dieses Problem nicht: Sie können jedes Element des Arrays nach der Verwendung explizit überschreiben.

Lösung: char[]-Array und manuelle Speicherverwaltung

Das Zeichen-Array char[] ist ein veränderliches Objekt. Sie können seinen Inhalt jederzeit ändern. Der Hauptvorteil: Sie können das Array sofort löschen, nachdem das Passwort nicht mehr benötigt wird.

So sieht das in der Praxis aus:

import java.util.Arrays;

public class PasswordExample {    public static void main(String[] args) {        // Falsch: String        String passwordString = "MySecret123";        // ... Überprüfung ...        passwordString = null; // Passwort kann immer noch im Speicher sein                // Richtig: char[]        char[] passwordChars = { 'M', 'y', 'S', 'e', 'c', 'r', 'e',