Warum wird char [] für Passwörter String vorgezogen?

In Swing verfügt das Kennwortfeld über eine getPassword()(Rückgabe- char[]) Methode anstelle der üblichen getText()(Rückgabe- String) Methode. Ebenso bin ich auf einen Vorschlag gestoßen, nicht Stringmit Passwörtern umzugehen.

Warum ist die StringSicherheit bei Passwörtern eine Bedrohung? Es fühlt sich unpraktisch an, es zu benutzen char[].

Saiten sind unveränderlich . Das bedeutet , dass , sobald Sie die erstellten String, wenn ein anderer Prozess Speicherabbild kann, gibt es keine Möglichkeit (abgesehen von Reflexion ) Sie loszuwerden, die Daten , bevor bekommen können Garbage Collection in Kicks.

Mit einem Array können Sie die Daten explizit löschen, nachdem Sie damit fertig sind. Sie können das Array mit einem beliebigen Element überschreiben, und das Kennwort ist auch vor der Speicherbereinigung nirgendwo im System vorhanden.

Ja, dies ist ein Sicherheitsrisiko - aber selbst die Verwendung char[]verringert nur das Zeitfenster für einen Angreifer und nur für diese bestimmte Art von Angriff.

Wie in den Kommentaren erwähnt, können Arrays, die vom Garbage Collector verschoben werden, Streukopien der Daten im Speicher belassen. Ich glaube, dies ist implementierungsspezifisch - der Garbage Collector löscht möglicherweise den gesamten Speicher, um dies zu vermeiden. Selbst wenn dies der Fall ist, gibt es immer noch die Zeit, in der das char[]die tatsächlichen Charaktere als Angriffsfenster enthält.

Während andere Vorschläge hier gültig erscheinen, gibt es einen anderen guten Grund. Mit plain haben StringSie eine viel höhere Wahrscheinlichkeit, das Kennwort versehentlich auf Protokolle , Monitore oder einen anderen unsicheren Ort zu drucken . char[]ist weniger anfällig.

Bedenken Sie:

public static void main(String[] args) {
    Object pw = "Password";
    System.out.println("String: " + pw);

    pw = "Password".toCharArray();
    System.out.println("Array: " + pw);
}

Drucke:

String: Password
Array: [C@5829428e

Um ein offizielles Dokument zu zitieren, der Java Cryptography Architecture Guide sagt über char[]vs. StringPasswörter (über Passwort-basierte Verschlüsselung, aber dies ist im Allgemeinen über Passwörter natürlich):

Es erscheint logisch, das Passwort in einem Objekt vom Typ zu sammeln und zu speichern java.lang.String. Hier ist jedoch die Einschränkung: Objects vom Typ Stringsind unveränderlich, dh es sind keine Methoden definiert, mit denen Sie den Inhalt einer String Nachverwendung ändern (überschreiben) oder auf Null setzen können . Diese Funktion macht StringObjekte ungeeignet zum Speichern sicherheitsrelevanter Informationen wie Benutzerkennwörter. Sie sollten charstattdessen immer sicherheitsrelevante Informationen in einem Array sammeln und speichern .

Die Richtlinie 2-2 der Secure Coding Guidelines für die Java-Programmiersprache, Version 4.0, sagt ebenfalls etwas Ähnliches aus (obwohl dies ursprünglich im Zusammenhang mit der Protokollierung steht):

Richtlinie 2-2: Protokollieren Sie keine hochsensiblen Informationen

Einige Informationen, wie z. B. Sozialversicherungsnummern (SSNs) und Kennwörter, sind sehr sensibel. Diese Informationen sollten nicht länger als nötig aufbewahrt werden und auch nicht von Administratoren angezeigt werden. Beispielsweise sollte es nicht an Protokolldateien gesendet werden und sein Vorhandensein sollte nicht durch Suchen erkennbar sein. Einige vorübergehende Daten können in veränderlichen Datenstrukturen wie Char-Arrays gespeichert und unmittelbar nach der Verwendung gelöscht werden. Das Löschen von Datenstrukturen hat die Effektivität auf typischen Java-Laufzeitsystemen verringert, da Objekte transparent in den Speicher für den Programmierer verschoben werden.

Diese Richtlinie hat auch Auswirkungen auf die Implementierung und Verwendung von Bibliotheken auf niedrigerer Ebene, die keine semantischen Kenntnisse über die Daten haben, mit denen sie sich befassen. Beispielsweise kann eine Low-Level-String-Parsing-Bibliothek den Text protokollieren, mit dem sie arbeitet. Eine Anwendung kann eine SSN mit der Bibliothek analysieren. Dies führt zu einer Situation, in der die SSNs Administratoren mit Zugriff auf die Protokolldateien zur Verfügung stehen.

Zeichenarrays ( char[]) können nach der Verwendung gelöscht werden, indem jedes Zeichen auf Null und Zeichenfolgen nicht gesetzt wird. Wenn jemand das Speicherbild irgendwie sehen kann, kann er ein Kennwort im Klartext sehen, wenn Zeichenfolgen verwendet werden. Wenn char[]es jedoch verwendet wird, ist das Kennwort nach dem Löschen von Daten mit Nullen sicher.

Einige Leute glauben, dass Sie den Speicher, der zum Speichern des Passworts verwendet wird, überschreiben müssen, sobald Sie es nicht mehr benötigen. Dies verkürzt das Zeitfenster, in dem ein Angreifer das Kennwort von Ihrem System lesen muss, und ignoriert vollständig die Tatsache, dass der Angreifer bereits genügend Zugriff benötigt, um den JVM-Speicher zu entführen, um dies zu tun. Ein Angreifer mit so viel Zugriff kann Ihre Schlüsselereignisse abfangen, was dies völlig unbrauchbar macht (AFAIK, bitte korrigieren Sie mich, wenn ich falsch liege).

Aktualisieren

Dank der Kommentare muss ich meine Antwort aktualisieren. Anscheinend gibt es zwei Fälle, in denen dies zu einer (sehr) geringfügigen Sicherheitsverbesserung führen kann, da dadurch die Zeit verkürzt wird, die ein Kennwort auf der Festplatte landen könnte. Trotzdem denke ich, dass es für die meisten Anwendungsfälle übertrieben ist.

• Ihr Zielsystem ist möglicherweise schlecht konfiguriert oder Sie müssen davon ausgehen, dass dies der Fall ist, und Sie müssen paranoid gegenüber Core Dumps sein (kann gültig sein, wenn die Systeme nicht von einem Administrator verwaltet werden).
• Ihre Software muss übermäßig paranoid sein, um zu verhindern, dass Datenlecks auftreten, wenn der Angreifer Zugriff auf die Hardware erhält - beispielsweise mit TrueCrypt (nicht mehr verfügbar ), VeraCrypt oder CipherShed .

Wenn möglich, würden beide Probleme durch Deaktivieren der Core-Dumps und der Auslagerungsdatei behoben. Sie würden jedoch Administratorrechte erfordern und könnten die Funktionalität reduzieren (weniger Arbeitsspeicher), und das Abrufen von RAM von einem laufenden System wäre weiterhin ein berechtigtes Anliegen.

Ich denke nicht, dass dies ein gültiger Vorschlag ist, aber ich kann zumindest den Grund erraten.

Ich denke, die Motivation besteht darin, sicherzustellen, dass Sie alle Spuren des Passworts im Speicher sofort und mit Sicherheit löschen können, nachdem es verwendet wurde. Mit a können char[]Sie jedes Element des Arrays mit einem Leerzeichen oder etwas sicherem überschreiben. Sie können den internen Wert von a auf Stringdiese Weise nicht bearbeiten .

Aber das allein ist keine gute Antwort. warum nicht einfach sicherstellen, dass ein Verweis auf die char[]oder Stringnicht entkommt? Dann gibt es kein Sicherheitsproblem. Aber die Sache ist, dass StringObjekte intern()theoretisch bearbeitet und im konstanten Pool am Leben erhalten werden können. Ich nehme an, die Verwendung char[]verbietet diese Möglichkeit.

Die Antwort wurde bereits gegeben, aber ich möchte ein Problem, das ich kürzlich entdeckt habe, mit Java-Standardbibliotheken teilen. Während sie jetzt sehr darauf achten, Kennwortzeichenfolgen char[]überall zu ersetzen (was natürlich eine gute Sache ist), scheinen andere sicherheitskritische Daten beim Löschen aus dem Speicher übersehen zu werden.

Ich denke zB an die PrivateKey- Klasse. Stellen Sie sich ein Szenario vor, in dem Sie einen privaten RSA-Schlüssel aus einer PKCS # 12-Datei laden und damit einen Vorgang ausführen. In diesem Fall würde es Ihnen nicht viel helfen, nur das Kennwort zu schnüffeln, solange der physische Zugriff auf die Schlüsseldatei ordnungsgemäß eingeschränkt ist. Als Angreifer wären Sie viel besser dran, wenn Sie den Schlüssel direkt anstelle des Passworts erhalten würden. Die gewünschten Informationen können vielfältig durchgesickert sein, Core-Dumps, eine Debugger-Sitzung oder Auslagerungsdateien sind nur einige Beispiele.

Und wie sich herausstellt, gibt es nichts, mit dem Sie die privaten Informationen PrivateKeyaus dem Speicher löschen können, da es keine API gibt, mit der Sie die Bytes löschen können, die die entsprechenden Informationen bilden.

Dies ist eine schlechte Situation, da in diesem Dokument beschrieben wird, wie dieser Umstand möglicherweise ausgenutzt werden kann.

Die OpenSSL-Bibliothek überschreibt beispielsweise kritische Speicherabschnitte, bevor private Schlüssel freigegeben werden. Da Java durch Müll gesammelt wird, benötigen wir explizite Methoden zum Löschen und Ungültigmachen privater Informationen für Java-Schlüssel, die unmittelbar nach Verwendung des Schlüssels angewendet werden sollen.

Wie Jon Skeet feststellt, gibt es keinen anderen Weg als die Verwendung von Reflexion.

Wenn Reflexion jedoch eine Option für Sie ist, können Sie dies tun.

public static void main(String[] args) {
    System.out.println("please enter a password");
    // don't actually do this, this is an example only.
    Scanner in = new Scanner(System.in);
    String password = in.nextLine();
    usePassword(password);

    clearString(password);

    System.out.println("password: '" + password + "'");
}

private static void usePassword(String password) {

}

private static void clearString(String password) {
    try {
        Field value = String.class.getDeclaredField("value");
        value.setAccessible(true);
        char[] chars = (char[]) value.get(password);
        Arrays.fill(chars, '*');
    } catch (Exception e) {
        throw new AssertionError(e);
    }
}

wenn ausgeführt

please enter a password
hello world
password: '***********'

Hinweis: Wenn das Zeichen [] des Strings als Teil eines GC-Zyklus kopiert wurde, besteht die Möglichkeit, dass sich die vorherige Kopie irgendwo im Speicher befindet.

Diese alte Kopie würde nicht in einem Heap-Dump angezeigt, aber wenn Sie direkten Zugriff auf den Rohspeicher des Prozesses haben, können Sie ihn sehen. Im Allgemeinen sollten Sie vermeiden, dass jemand einen solchen Zugang hat.

Dies sind alle Gründe, warum man für ein Passwort ein char [] Array anstelle von String wählen sollte .

1. Da Strings in Java unveränderlich sind, bleibt das Kennwort, wenn Sie es als einfachen Text speichern, im Speicher verfügbar, bis der Garbage Collector es löscht. Da String zur Wiederverwendbarkeit im String-Pool verwendet wird, besteht eine ziemlich hohe Wahrscheinlichkeit, dass dies der Fall ist bleiben lange im Gedächtnis, was eine Sicherheitsbedrohung darstellt.

Da jeder, der Zugriff auf den Speicherauszug hat, das Kennwort im Klartext finden kann, sollten Sie aus diesem Grund immer ein verschlüsseltes Kennwort anstelle von einfachem Text verwenden. Da Strings unveränderlich sind, kann der Inhalt von Strings auf keinen Fall geändert werden, da bei jeder Änderung ein neuer String erzeugt wird. Wenn Sie jedoch ein char [] verwenden, können Sie dennoch alle Elemente als leer oder null festlegen. Durch das Speichern eines Kennworts in einem Zeichenarray wird das Sicherheitsrisiko beim Diebstahl eines Kennworts deutlich verringert.

2. Java selbst empfiehlt die Verwendung der Methode getPassword () von JPasswordField, die ein char [] zurückgibt, anstelle der veralteten Methode getText (), die Kennwörter im Klartext unter Angabe von Sicherheitsgründen zurückgibt. Es ist gut, den Ratschlägen des Java-Teams zu folgen und sich an Standards zu halten, anstatt gegen diese zu verstoßen.

3. Bei String besteht immer das Risiko, dass einfacher Text in einer Protokolldatei oder Konsole gedruckt wird. Wenn Sie jedoch ein Array verwenden, wird der Inhalt eines Arrays nicht gedruckt, sondern der Speicherort wird gedruckt. Obwohl dies kein wirklicher Grund ist, macht es dennoch Sinn.

String strPassword="Unknown";
char[] charPassword= new char[]{'U','n','k','w','o','n'};
System.out.println("String password: " + strPassword);
System.out.println("Character password: " + charPassword);

String password: Unknown
Character password: [C@110b053

Referenziert von diesem Blog . Ich hoffe das hilft.

Bearbeiten: Wenn ich nach einem Jahr Sicherheitsforschung auf diese Antwort zurückkomme, stelle ich fest, dass dies die unglückliche Folgerung ist, dass Sie jemals Klartext-Passwörter vergleichen würden. Bitte nicht. Verwenden Sie einen sicheren Einweg-Hash mit einem Salz und einer angemessenen Anzahl von Iterationen . Erwägen Sie die Verwendung einer Bibliothek: Dieses Zeug ist schwer richtig zu machen!

Ursprüngliche Antwort: Was ist mit der Tatsache, dass String.equals () eine Kurzschlussauswertung verwendet und daher für einen Timing-Angriff anfällig ist? Es mag unwahrscheinlich sein, aber Sie könnten theoretisch den Passwortvergleich zeitlich festlegen, um die richtige Zeichenfolge zu bestimmen.

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = value.length;
        // Quits here if Strings are different lengths.
        if (n == anotherString.value.length) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = 0;
            // Quits here at first different character.
            while (n-- != 0) {
                if (v1[i] != v2[i])
                    return false;
                i++;
            }
            return true;
        }
    }
    return false;
}

Weitere Ressourcen zum Timing von Angriffen:

• Eine Lektion in Timing-Angriffen
• Eine Diskussion über das Timing von Angriffen auf Information Security Stack Exchange
• Und natürlich die Wikipedia-Seite Timing Attack

Es gibt nichts, was Ihnen das char-Array gegen String gibt, es sei denn, Sie bereinigen es nach der Verwendung manuell, und ich habe noch niemanden gesehen, der das tatsächlich tut. Für mich ist die Präferenz von char [] gegenüber String etwas übertrieben.

Schauen Sie sich hier die _{weit verbreitete} Spring Security-Bibliothek an und fragen Sie sich, ob Spring Security-Leute inkompetent sind oder char [] -Kennwörter einfach nicht viel Sinn machen. Wenn ein böser Hacker Speicherabbilder Ihres Arbeitsspeichers abruft, stellen Sie sicher, dass er alle Kennwörter erhält, auch wenn Sie sie auf ausgeklügelte Weise ausblenden.

Java ändert sich jedoch ständig, und einige beängstigende Funktionen wie die String-Deduplizierungsfunktion von Java 8 können String-Objekte ohne Ihr Wissen internieren. Aber das ist ein anderes Gespräch.

Zeichenfolgen sind unveränderlich und können nach ihrer Erstellung nicht mehr geändert werden. Wenn Sie ein Kennwort als Zeichenfolge erstellen, verbleiben streunende Verweise auf das Kennwort auf dem Heap oder im Zeichenfolgenpool. Wenn jemand einen Heap-Dump des Java-Prozesses erstellt und sorgfältig durchsucht, kann er möglicherweise die Kennwörter erraten. Natürlich werden diese nicht verwendeten Zeichenfolgen durch Müll gesammelt, aber das hängt davon ab, wann der GC startet.

Auf der anderen Seite sind char [] veränderbar, sobald die Authentifizierung abgeschlossen ist. Sie können sie mit einem beliebigen Zeichen wie allen Ms oder Backslashes überschreiben. Selbst wenn jemand einen Heap-Dump erstellt, kann er möglicherweise nicht die Kennwörter abrufen, die derzeit nicht verwendet werden. Dies gibt Ihnen mehr Kontrolle in dem Sinne, dass Sie den Objektinhalt selbst löschen, anstatt darauf zu warten, dass der GC dies tut.

String ist unveränderlich und geht in den String-Pool. Einmal geschrieben, kann es nicht überschrieben werden.

char[] ist ein Array, das Sie überschreiben sollten, sobald Sie das Kennwort verwendet haben. So sollte es gemacht werden:

char[] passw = request.getPassword().toCharArray()
if (comparePasswords(dbPassword, passw) {
 allowUser = true;
 cleanPassword(passw);
 cleanPassword(dbPassword);
 passw=null;
}

private static void cleanPassword (char[] pass) {

Arrays.fill(pass, '0');
}

Ein Szenario, in dem der Angreifer es verwenden könnte, ist ein Absturzspeicherauszug. Wenn die JVM abstürzt und einen Speicherauszug generiert, wird das Kennwort angezeigt.

Das ist nicht unbedingt ein böswilliger externer Angreifer. Dies kann ein Support-Benutzer sein, der zu Überwachungszwecken Zugriff auf den Server hat. Er konnte in einen Crashdump schauen und die Passwörter finden.

Die kurze und unkomplizierte Antwort wäre, weil sie char[]veränderlich ist, während StringObjekte dies nicht sind.

Stringsin Java sind unveränderliche Objekte. Aus diesem Grund können sie nach ihrer Erstellung nicht mehr geändert werden. Daher besteht die einzige Möglichkeit, ihren Inhalt aus dem Speicher zu entfernen, darin, sie mit Müll zu sammeln. Erst dann kann der vom Objekt freigegebene Speicher überschrieben werden und die Daten gehen verloren.

Jetzt erfolgt die Speicherbereinigung in Java nicht in einem garantierten Intervall. Das Stringkann somit für eine lange Zeit im Speicher verbleiben, und wenn ein Prozess während dieser Zeit abstürzt, kann der Inhalt der Zeichenfolge in einem Speicherauszug oder einem Protokoll enden.

Mit einem Zeichenarray können Sie das Kennwort lesen, die Arbeit so schnell wie möglich beenden und dann sofort den Inhalt ändern.

String in Java ist unveränderlich. Wenn also eine Zeichenfolge erstellt wird, bleibt sie im Speicher, bis sie durch Müll gesammelt wird. Jeder, der Zugriff auf den Speicher hat, kann den Wert der Zeichenfolge lesen.
Wenn der Wert der Zeichenfolge geändert wird, wird eine neue Zeichenfolge erstellt. So bleiben sowohl der ursprüngliche Wert als auch der geänderte Wert im Speicher, bis der Müll gesammelt wird.

Mit dem Zeichenarray kann der Inhalt des Arrays geändert oder gelöscht werden, sobald der Zweck des Kennworts erfüllt ist. Der ursprüngliche Inhalt des Arrays wird nach dem Ändern und noch vor dem Start der Speicherbereinigung nicht im Speicher gefunden.

Aus Sicherheitsgründen ist es besser, das Kennwort als Zeichenarray zu speichern.

Es ist fraglich, ob Sie String oder Char [] für diesen Zweck verwenden sollten, da beide ihre Vor- und Nachteile haben. Dies hängt davon ab, was der Benutzer benötigt.

Da Strings in Java unveränderlich sind, wird bei jedem Versuch, Ihren String zu manipulieren, ein neues Objekt erstellt, und der vorhandene String bleibt davon unberührt. Dies könnte als Vorteil für das Speichern eines Kennworts als Zeichenfolge angesehen werden, das Objekt bleibt jedoch auch nach der Verwendung im Speicher. Wenn also jemand irgendwie den Speicherort des Objekts hat, kann diese Person Ihr an diesem Speicherort gespeichertes Passwort leicht nachverfolgen.

Char [] ist veränderlich, hat jedoch den Vorteil, dass der Programmierer nach seiner Verwendung das Array explizit bereinigen oder Werte überschreiben kann. Wenn es fertig ist, wird es gereinigt und niemand kann jemals etwas über die Informationen erfahren, die Sie gespeichert haben.

Basierend auf den oben genannten Umständen kann man sich ein Bild davon machen, ob man für seine Anforderungen mit String oder mit Char [] arbeiten soll.

Fallzeichenfolge:

    String password = "ill stay in StringPool after Death !!!";
    // some long code goes
    // ...Now I want to remove traces of password
    password = null;
    password = "";
    // above attempts wil change value of password
    // but the actual password can be traced from String pool through memory dump, if not garbage collected

Fall CHAR ARRAY:

    char[] passArray = {'p','a','s','s','w','o','r','d'};
    // some long code goes
    // ...Now I want to remove traces of password
    for (int i=0; i<passArray.length;i++){
        passArray[i] = 'x';
    }
    // Now you ACTUALLY DESTROYED traces of password form memory