2

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, i.e. 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. "

reechard
  • 861
  • 6
  • 22
  • What is `StringObject`? – Oliver Charlesworth Jun 07 '14 at 18:36
  • 4
    What is `StringObject`? I don't think it is a standard java class. Are you talking about instances of `java.lang.String`? – Fabian Jun 07 '14 at 18:36
  • 1
    This is why many APIs take passwords as `char[]`, rather than `String`. – Oliver Charlesworth Jun 07 '14 at 18:45
  • 1
    Optimizing anything based on a priori knowledge is considered harmful. – Kevin Krumwiede Jun 07 '14 at 18:46
  • Yes, guys, I meant the primitive char buffer used to hold the String memory. – reechard Jun 07 '14 at 18:51
  • 1
    If you're concerned about a side channel attack from the Heartbleed vulnerability, then you should focus your efforts on updating your OpenSSL library instead. – Makoto Jun 07 '14 at 18:54
  • @Makoto Heartbleed is an example. It is poor practice to leave sensitive information around waiting for the garbage collector. Its like throwing away your paper credit card statements in the garbage. – reechard Jun 07 '14 at 18:57
  • Data is data, whether it's in a human-readable format or not. If it's on your server, in memory, and you're not properly securing it, then it doesn't really *matter* what it's stored as. I wouldn't make a blanket statement to say that keeping instances of `String` around until they can be garbage collected is "bad practice", since you could store them as any object, and be just as vulnerable. – Makoto Jun 07 '14 at 18:59
  • So, I shouldn't worry about shredding credit card statements because I may have photocopied them and posted them on the internet? – reechard Jun 07 '14 at 19:03

1 Answers1

4

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!

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
  • Correct. If a String is truly "garbage" then it cannot be addressed by Java code. Only some attack at the machine language level can access the data, and such an attack can access ANY data. – Hot Licks Jun 07 '14 at 20:14
  • 2
    There is still value in eagerly wiping the data, it reduces attack windows. As you note it's not an effective defense on its own, but there's this concept called defense in depth. It does not necessarily stop any attack, but does make it ever so harder to actually pull off, which could save your ass in the (hopefully) rare case that the other lines of defense fall. –  Jun 07 '14 at 20:24
  • Yes, @delnan , added a follow-on question – reechard Jun 07 '14 at 20:28