Perché char [] è preferito su String per le password?

In Swing, il campo password ha un metodo getPassword()(restituisce char[]) invece del solito metodo getText()(restituisce String). Allo stesso modo, ho trovato un suggerimento di non utilizzare Stringper gestire le password.

Perché Stringrappresenta una minaccia per la sicurezza quando si tratta di password? Sembra scomodo da usare char[].

Le stringhe sono immutabili . Ciò significa che, una volta creato String, se un altro processo può scaricare la memoria, non c'è modo (a parte la riflessione ) di liberarsi dei dati prima della garbage collection .

Con un array, puoi cancellare esplicitamente i dati dopo aver finito con esso. Puoi sovrascrivere l'array con qualsiasi cosa ti piaccia e la password non sarà presente in nessun punto del sistema, nemmeno prima della garbage collection.

Quindi sì, questo è un problema di sicurezza, ma anche l'utilizzochar[] riduce solo la finestra di opportunità per un attaccante, ed è solo per questo specifico tipo di attacco.

Come notato nei commenti, è possibile che gli array che vengono spostati dal Garbage Collector lascino in memoria copie vaganti dei dati. Credo che questo sia specifico dell'implementazione: il Garbage Collector potrebbe cancellare tutta la memoria mentre procede, per evitare questo genere di cose. Anche se lo fa, c'è ancora il tempo durante il quale char[]contiene i personaggi reali come una finestra di attacco.

Mentre altri suggerimenti qui sembrano validi, c'è un'altra buona ragione. Con Plain Stringhai molte più possibilità di stampare accidentalmente la password su registri , monitor o altri luoghi non sicuri. char[]è meno vulnerabile.

Considera questo:

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

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

stampe:

String: Password
Array: [C@5829428e

Per citare un documento ufficiale, la guida Java Cryptography Architecture dice questo su char[]vs. Stringpassword (sulla crittografia basata su password, ma questo è più in generale sulle password ovviamente):

Sembrerebbe logico raccogliere e archiviare la password in un oggetto di tipo java.lang.String. Tuttavia, ecco l'avvertenza: Objecti tipi di s Stringsono immutabili, ovvero non esistono metodi definiti che consentono di modificare (sovrascrivere) o azzerare il contenuto di un String post-utilizzo. Questa funzione rende gli Stringoggetti non idonei per la memorizzazione di informazioni sensibili alla sicurezza come le password degli utenti. Dovresti sempre raccogliere e archiviare le informazioni sensibili alla sicurezza in un chararray.

La Linea guida 2-2 delle Linee guida per la codifica sicura per il linguaggio di programmazione Java, versione 4.0 dice anche qualcosa di simile (sebbene sia originariamente nel contesto della registrazione):

Linea guida 2-2: non registrare informazioni altamente sensibili

Alcune informazioni, come i numeri di previdenza sociale (SSN) e le password, sono altamente sensibili. Queste informazioni non devono essere conservate più a lungo del necessario né dove possono essere visualizzate, neppure dagli amministratori. Ad esempio, non dovrebbe essere inviato ai file di registro e la sua presenza non dovrebbe essere rilevabile attraverso le ricerche. Alcuni dati transitori possono essere conservati in strutture di dati mutabili, come ad esempio array di caratteri, e cancellati immediatamente dopo l'uso. L'eliminazione delle strutture di dati ha ridotto l'efficacia sui tipici sistemi di runtime Java poiché gli oggetti vengono spostati in memoria in modo trasparente al programmatore.

Questa linea guida ha anche implicazioni per l'implementazione e l'uso di librerie di livello inferiore che non hanno una conoscenza semantica dei dati con cui hanno a che fare. Ad esempio, una libreria di analisi delle stringhe di basso livello può registrare il testo su cui lavora. Un'applicazione può analizzare un SSN con la libreria. Ciò crea una situazione in cui gli SSN sono disponibili per gli amministratori con accesso ai file di registro.

Le matrici di caratteri ( char[]) possono essere cancellate dopo l'uso impostando ogni carattere su zero e Stringhe no. Se qualcuno può in qualche modo vedere l'immagine di memoria, può vedere una password in testo semplice se vengono utilizzate le stringhe, ma se char[]viene utilizzata, dopo aver eliminato i dati con 0, la password è sicura.

Alcune persone credono che sia necessario sovrascrivere la memoria utilizzata per archiviare la password quando non è più necessaria. Ciò riduce la finestra temporale in cui un utente malintenzionato deve leggere la password dal sistema e ignora completamente il fatto che l'attaccante ha già bisogno di accesso sufficiente per dirottare la memoria JVM per farlo. Un aggressore con così tanto accesso può catturare i tuoi eventi chiave rendendolo completamente inutile (AFAIK, quindi per favore correggimi se sbaglio).

Aggiornare

Grazie ai commenti devo aggiornare la mia risposta. Apparentemente ci sono due casi in cui questo può aggiungere un (molto) lieve miglioramento della sicurezza in quanto riduce il tempo in cui una password potrebbe atterrare sul disco rigido. Penso comunque che sia eccessivo per la maggior parte dei casi d'uso.

• Il tuo sistema di destinazione potrebbe essere configurato in modo errato o devi presumere che lo sia e devi essere paranoico sui dump principali (può essere valido se i sistemi non sono gestiti da un amministratore).
• Il tuo software deve essere eccessivamente paranoico per impedire la perdita di dati con l'attaccante che ottiene l'accesso all'hardware, usando cose come TrueCrypt (fuori produzione), VeraCrypt o CipherShed .

Se possibile, disabilitare i core dump e il file di scambio si occuperebbe di entrambi i problemi. Tuttavia, richiederebbero i diritti di amministratore e potrebbero ridurre la funzionalità (meno memoria da utilizzare) e estrarre RAM da un sistema in esecuzione sarebbe comunque una preoccupazione valida.

Non penso che questo sia un suggerimento valido, ma posso almeno indovinare il motivo.

Penso che la motivazione sia voler assicurarsi di poter cancellare prontamente e con certezza ogni traccia della password in memoria dopo che è stata utilizzata. Con un char[]puoi sovrascrivere ogni elemento dell'array con uno spazio vuoto o qualcosa di sicuro. Non è possibile modificare il valore interno di Stringquel modo.

Ma quella da sola non è una buona risposta; perché non assicurarsi semplicemente un riferimento a char[]o Stringnon scappare? Quindi non ci sono problemi di sicurezza. Ma il fatto è che gli Stringoggetti possono essere intern()editati in teoria e mantenuti vivi all'interno del pool costante. Suppongo che l'uso char[]proibisca questa possibilità.

La risposta è già stata data, ma vorrei condividere un problema che ho scoperto di recente con le librerie standard Java. Mentre ora si prendono molta cura di sostituire le stringhe di password con char[]ovunque (il che ovviamente è una buona cosa), altri dati critici per la sicurezza sembrano essere trascurati quando si tratta di cancellarli dalla memoria.

Sto pensando ad esempio alla classe PrivateKey . Considerare uno scenario in cui caricare una chiave RSA privata da un file PKCS # 12, utilizzandolo per eseguire alcune operazioni. Ora, in questo caso, annusare la password da sola non sarebbe di grande aiuto fintanto che l'accesso fisico al file chiave è adeguatamente limitato. Come attaccante, staresti molto meglio se avessi ottenuto la chiave direttamente invece della password. Le informazioni desiderate possono essere trapelate molteplici, core dump, una sessione di debugger o file di scambio sono solo alcuni esempi.

E a quanto pare, non c'è nulla che ti consenta di cancellare le informazioni private di un PrivateKeydalla memoria, perché non esiste un'API che ti consente di cancellare i byte che formano le informazioni corrispondenti.

Questa è una brutta situazione, poiché questo documento descrive come questa circostanza potrebbe essere potenzialmente sfruttata.

La libreria OpenSSL, ad esempio, sovrascrive le sezioni di memoria critica prima che vengano liberate le chiavi private. Poiché Java viene raccolto in modo inutile, avremmo bisogno di metodi espliciti per cancellare e invalidare le informazioni private per le chiavi Java, che devono essere applicate immediatamente dopo aver usato la chiave.

Come afferma Jon Skeet, non c'è altro modo che usare la riflessione.

Tuttavia, se la riflessione è un'opzione per te, puoi farlo.

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);
    }
}

quando eseguito

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

Nota: se il carattere String [] è stato copiato come parte di un ciclo GC, è possibile che la copia precedente sia da qualche parte nella memoria.

Questa vecchia copia non verrebbe visualizzata in un dump dell'heap, ma se si avesse accesso diretto alla memoria grezza del processo, la si potrebbe vedere. In generale dovresti evitare che chiunque abbia tale accesso.

Questi sono tutti i motivi, si dovrebbe scegliere un array char [] anziché String per una password.

1. Poiché le stringhe sono immutabili in Java, se si memorizza la password come testo normale, sarà disponibile in memoria fino a quando il Garbage Collector non la cancella e poiché String viene utilizzato nel pool di stringhe per la riusabilità, è molto probabile che rimanere in memoria per un lungo periodo, il che rappresenta una minaccia per la sicurezza.

Dal momento che chiunque abbia accesso al dump della memoria può trovare la password in chiaro, questo è un altro motivo per cui dovresti sempre usare una password crittografata piuttosto che un semplice testo. Poiché le stringhe sono immutabili, non è possibile modificare il contenuto delle stringhe poiché qualsiasi modifica produrrà una nuova stringa, mentre se si utilizza un carattere [] è comunque possibile impostare tutti gli elementi come vuoti o zero. Pertanto, la memorizzazione di una password in una matrice di caratteri riduce chiaramente il rischio per la sicurezza di rubare una password.

2. Java stesso consiglia di utilizzare il metodo getPassword () di JPasswordField che restituisce un carattere [], anziché il metodo deprTated getText () che restituisce le password in testo chiaro indicando motivi di sicurezza. È bene seguire i consigli del team Java e aderire agli standard piuttosto che andare contro di essi.

3. Con String esiste sempre il rischio di stampare testo normale in un file di registro o in una console, ma se si utilizza un array non si stampa il contenuto di un array, ma viene stampata la posizione di memoria. Sebbene non sia una vera ragione, ha ancora senso.

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

Riferito da questo blog . Spero che questo possa essere d'aiuto.

Modifica: tornando a questa risposta dopo un anno di ricerche sulla sicurezza, mi rendo conto che ha la sfortunata implicazione che tu possa mai effettivamente confrontare le password in chiaro. Per favore, no. Usa un hash unidirezionale sicuro con un sale e un numero ragionevole di iterazioni . Prendi in considerazione l'uso di una libreria: è difficile ottenere queste cose!

Risposta originale: Che dire del fatto che String.equals () utilizza la valutazione del corto circuito ed è quindi vulnerabile a un attacco di temporizzazione? Potrebbe essere improbabile, ma teoricamente potresti calcolare il confronto delle password per determinare la sequenza corretta di caratteri.

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;
}

Altre risorse sugli attacchi di cronometraggio:

• Una lezione sugli attacchi al cronometro
• Una discussione sugli attacchi temporali allo scambio di stack di sicurezza delle informazioni
• E, naturalmente, la pagina Wikipedia di Timing Attack

Non c'è nulla che char array ti offra vs String se non lo ripulisci manualmente dopo l'uso e non ho visto nessuno farlo. Quindi per me la preferenza di char [] vs String è un po 'esagerata.

Dai un'occhiata alla libreria di Spring Security _{ampiamente usata} qui e chiediti: le password incompetenti o char [] dei ragazzi di Spring Security non hanno molto senso. Quando un brutto hacker afferra i dump della memoria della tua RAM, assicurati che ottenga tutte le password anche se usi metodi sofisticati per nasconderle.

Tuttavia, Java cambia continuamente e alcune funzionalità spaventose come la funzionalità di deduplicazione delle stringhe di Java 8 potrebbero internare oggetti String a tua insaputa. Ma questa è una conversazione diversa.

Le stringhe sono immutabili e non possono essere modificate una volta create. La creazione di una password come stringa lascerà riferimenti vaganti alla password nell'heap o nel pool di stringhe. Ora, se qualcuno prende un dump del processo Java e lo scansiona attentamente, potrebbe essere in grado di indovinare le password. Naturalmente, queste stringhe non utilizzate verranno raccolte in modo immondizia, ma ciò dipende da quando il GC entra in funzione.

Dall'altro lato, i caratteri [] sono modificabili non appena l'autenticazione è stata eseguita, puoi sovrascriverli con qualsiasi carattere come tutte le M o le barre rovesciate. Ora, anche se qualcuno prende un dump dell'heap, potrebbe non essere in grado di ottenere le password che non sono attualmente in uso. Questo ti dà un maggiore controllo nel senso di cancellare il contenuto dell'Oggetto da solo, in attesa che il GC lo faccia.

String è immutabile e va al pool di stringhe. Una volta scritto, non può essere sovrascritto.

char[] è un array che dovresti sovrascrivere dopo aver usato la password ed è così che dovrebbe essere fatto:

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');
}

Uno scenario in cui l'attaccante potrebbe utilizzarlo è un crashdump - quando la JVM si arresta in modo anomalo e genera un dump di memoria - sarai in grado di vedere la password.

Questo non è necessariamente un aggressore esterno dannoso. Potrebbe trattarsi di un utente dell'assistenza che ha accesso al server a fini di monitoraggio. Poteva sbirciare in una discarica e trovare le password.

La risposta breve e diretta sarebbe perché char[]è mutevole mentreString oggetti non lo sono.

Stringsin Java sono oggetti immutabili. Questo è il motivo per cui non possono essere modificati una volta creati, e quindi l'unico modo per rimuovere i loro contenuti dalla memoria è farli raccogliere. Sarà solo allora che la memoria liberata dall'oggetto potrà essere sovrascritta e i dati saranno spariti.

Ora la garbage collection in Java non avviene ad alcun intervallo garantito. IlString può quindi persistere nella memoria per molto tempo e se un processo si arresta in modo anomalo durante questo periodo, il contenuto della stringa potrebbe finire in un dump della memoria o in qualche registro.

Con un array di caratteri , puoi leggere la password, terminare di lavorarci il prima possibile e quindi modificare immediatamente il contenuto.

La stringa in Java è immutabile. Pertanto, ogni volta che viene creata una stringa, rimarrà nella memoria fino a quando non verrà raccolta in modo errato. Quindi chiunque abbia accesso alla memoria può leggere il valore della stringa.
Se il valore della stringa viene modificato, finirà per creare una nuova stringa. Pertanto, sia il valore originale che il valore modificato rimangono in memoria fino a quando non vengono raccolti.

Con l'array di caratteri, il contenuto dell'array può essere modificato o cancellato una volta offerto lo scopo della password. Il contenuto originale dell'array non verrà trovato in memoria dopo che è stato modificato e anche prima che entri in azione la garbage collection.

Per motivi di sicurezza, è meglio archiviare la password come array di caratteri.

È discutibile se si debba usare String o usare Char [] a questo scopo perché entrambi hanno i loro vantaggi e svantaggi. Dipende da ciò di cui l'utente ha bisogno.

Poiché le stringhe in Java sono immutabili, ogni volta che alcuni tentano di manipolare la stringa, crea un nuovo oggetto e la stringa esistente rimane inalterata. Questo potrebbe essere visto come un vantaggio per l'archiviazione di una password come stringa, ma l'oggetto rimane in memoria anche dopo l'uso. Quindi, se qualcuno in qualche modo ha ottenuto la posizione di memoria dell'oggetto, quella persona può facilmente rintracciare la password memorizzata in quella posizione.

Char [] è mutabile, ma ha il vantaggio che dopo il suo utilizzo il programmatore può pulire esplicitamente l'array o sovrascrivere i valori. Quindi, una volta terminato l'uso, viene pulito e nessuno potrà mai sapere delle informazioni memorizzate.

Sulla base delle circostanze di cui sopra, si può avere un'idea se andare con String o andare con Char [] per i loro requisiti.

Stringa di caso:

    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

Caso 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