Il org.identityconnectors.common.security.GuardedString di Oracle lo afferma nella sua documentazione:
The GuardedString class alleviates [the problem that string data is kept in memory as clear text] by storing the characters in memory in an encrypted form. The encryption key will be a randomly-generated key.
Questo protegge da un heap o da un dump della memoria? A prima vista, sembra banale individuare la chiave generata a caso in memoria e usarla per decrittografare i dati sensibili.
Un'analisi più approfondita dell'attuazione effettiva aiuterà un utente malintenzionato a comprendere la struttura dei dati di un dump di memoria e da ciò che ho trovato in EncryptorImpl non ci sono stati sforzi per nascondere il meccanismo di memorizzazione delle chiavi per prolungare il tempo necessario per il reverse-engineering del segreto. Quindi no, questa non è una misura efficace contro l'esposizione della memoria.
Consentimi di fornire uno scenario di utilizzo migliore per questa classe: Poiché la variabile chiave è privata, almeno è molto improbabile che uno sviluppatore possa trovare il modo di rispondere con la chiave per errore a un utente malintenzionato (ad esempio a causa di un bug nel flusso di controllo di un gestore di richieste di servizi Web), quindi c'è qualche uso per questa classe nell'assicurare che il codice possa solo aiutare a decodificare decifrando effettivamente in background invece di distribuire una chiave. Dopo che il programma è stato arrestato / portato offline, un utente malintenzionato non sarà più in grado di decifrare i segreti e tutte le decrittografie avvenute fino a quel momento (quando l'utente malintenzionato utilizzava il programma come una specie di oracolo) avevano la possibilità di può essere rilevante in un'analisi post-mortem per capire quali dati sono stati compromessi.
Leggi altre domande sui tag java memory encryption