Is it harmful to use java.lang.String to store sensitive data?

Question

Because Java string objects are immutable and the garbage collector asynchronous, storing authentication information in strings prevents one sort of security in favor of thread safety.

Securely handling such information requires mutability, ie zeroing out memory previously used to store sensitive information.

Assume you may be using a version of openssl with the HeartBleed vulnerability.

Is it not the case that a naive implementation of authentication may result in JVM memory being littered with usernames and passwords?

Should java.lang.string be avoided altogether if you can't know a priori that the information is not sensitive?

And as a side-question, what can the Jvm do to mitigate the risk? I'm not aware of a switch a la "eagerly zero-fill reclaimed memory ASAP. "

Answer 1

I am not much of a crypto expert, but I think this depends on your assessment of the threat model.

If you can assume that an attacker can read random parts of memory, I'm honestly not sure how you can design a cryptographically secure system. After all, an attacker might be able to extract your secret key as soon as you pull it into memory. If you assume that attackers can do this, putting in extra protections to clear memory as fast as possible won't change the fact that your system is still vulnerable. An attacker with any advance knowledge of the timing of the system could break into it.

If you don't assume that an attacker can do this, then the security concerns of keeping old strings in memory are less important. Java's language-level security features should ensure that an attacker who can compromise the JVM can't see the expired string objects. If you don't trust Java's implementation to protect this, then I don't think the fault is more with the JVM than with the string objects.

More generally, I think the first question to ask is what you can assume an attacker can do. If you think that your system might be vulnerable to someone scanning the contents of RAM, then I think you have a much bigger issue than garbage collectors not running quickly enough. If you think that someone might be able to run arbitrary Java code, then I don't think it's a problem. If you think that someone might freeze the computer and carry it to a lab to inspect RAM, I think you have larger problems to worry about.

Hope this helps!