Perché le stringhe in StringPool sono considerate non sicure?

Question

Perché le stringhe in StringPool sono considerate non sicure?

#1 da (5 voti)
#2 da (1 voti)

1

Le password si consiglia di essere memorizzate in char [] invece di String, poiché le stringhe sono memorizzate in StringPool. Leggi di più qui

Come per questa domanda le stringhe in StringPool non sono disponibili direttamente. Per ottenere le stringhe in Stringpool, è necessario un dizionario delle password per controllarle in StringPool. Se abbiamo un dizionario delle password, non dobbiamo preoccuparci di StringPool, possiamo comunque provare direttamente sui campi delle password.

Per impedire l'attacco Brute-force stiamo limitando il numero di tentativi per le password e il controllo di eventuali sospetti attività.

Se tutto ciò non è ancora attivo, non dovremmo usare "String" come tipo di dati per le password?

La risposta ottenuta da domande simili è: possiamo accedere al dump della memoria e accedere alle stringhe in stringpool.

Domande successive:

Come si può accedere al dump della memoria?
L'accesso può essere impedito?
Se viene impedito l'accesso al dump della memoria, è sicuro utilizzare String come tipo per le password?

java security strings passwords server-security

posta Mohit Kanwar 01.08.2015 - 06:39

fonte

2 risposte

Leggi altre domande sui tag java security strings passwords server-security

Un "sistema tipo" secondario per riferimenti? Qual è il pattern factory di DRY-est per istanziare sottotipi basati su uno dei valori delle loro proprietà?

score 5 · Answer 1

La stringa, una volta creata, esiste in memoria fino a quando non viene eseguita una garbage collection. Se qualsiasi cosa ha un riferimento ad esso, non viene raccolto. Confronta questo con il codice:

char[] password = somedata;
// test password;
Arrays.fill(password, 0);

Sebbene l'array di caratteri possa esistere per qualche tempo, i valori all'interno dell'array di caratteri scompaiono una volta che Arrays.fill viene eseguito. In questo modo, la password memorizzata in char[] ha una durata nota su cui è possibile ragionare, a differenza della durata di una stringa sull'heap.

Creare un dump della memoria è facile come eseguire un programma in cui è possibile connettersi alle varie macchine virtuali. VisualVM può farlo abbastanza bene.

E...

Vaialleclassi,faidoppioclicsuString...

EpoihaiogniistanzadiunastringacheèinesecuzionenellaJVMalmomentodeldumpdellamemoria.

Sebbene ciò implichi un qualche accesso alla macchina, il takeaway della chiave è che è molto facile ottenere un dump dell'heap ed esaminarlo. Esiste anche un linguaggio simile a SQL che si chiama OQL per fare query su di esso.

Il motivo per utilizzare char[] è limitare l'esposizione a un dump della memoria. Se noti che la riga destra sotto String nel dump della memoria era char[] e sono presenti anche lì.

Le persone attente alla sicurezza sono particolarmente preoccupate di questo su Android dove si può rubare un dispositivo e fare un dump di memoria dei processi in esecuzione raccogliendo password per tutte le app che hanno memorizzato le loro password in String che non sono ancora state raccolte.

score 1 · Answer 2

I dump della memoria possono essere ottenuti in vari modi, a seconda del tipo esatto di sistema su cui viene eseguita l'applicazione. In genere, la creazione di un dump di memoria richiederebbe l'accesso per eseguire processi sul server su cui viene eseguita l'applicazione o, se si tratta di una VM, potrebbe essere eseguita anche dall'host di macchine virtuali. Le password di blanking sono una misura di mitigazione per ridurre la quantità di danni che un hacker può fare se ottiene questo accesso.

In generale, è impossibile garantire che l'accesso alla creazione di dump di memoria sia stato prevenuto, poiché le nuove vulnerabilità a livello di sistema operativo sono scoperte con frequenza relativamente alta, e quindi non si può sapere che nessun attaccante ha una rotta funzionante nel sistema che tu (e potenzialmente il fornitore del sistema operativo) non ne sei consapevole. Gli attacchi interni (ad esempio, da dipendenti scontenti) possono anche essere mitigati da questo approccio, quindi anche se si presume di essere al riparo da attacchi esterni, è sempre buona pratica azzerare le password non appena si termina di eseguirne l'hashing.