In Java, is there still a point in using char[] instead of String to store passwords?

Question

I learned about using char[] to store passwords back in the Usenet days in comp.lang.java.*.

Searching Stack Overflow, you can also easily find highly upvoted questions like this: Why is char[] preferred over String for passwords? which agrees with what I learned a long, long time ago.

I still write my APIs to use char[] for password. But are that just hollow ideals now?

For example, look at Atlassian Jira's Java API: LoginManager.authenticate which takes your password as a String.

Or Thales' Luna Java API: login() method in LunaSlotManager. Of all people, an HSM vendor using String for the HSM slot password.

I think I've also read somewhere that the internals of URLConnection (and many other classes) uses String internally to handle the data. So if you ever send a password (although the password is encrypted by TLS over the wire), it will be in a String in your server's memory.

Is accessing server memory an attack factor so difficult to achieve that it is okay to store passwords as String now? Or is Thales' doing it because your password will end up in a String anyway due to classes written by others?

Answer 1

Lots of detail in the answers but here's the short of it: yes, in theory, putting the password in an array and wiping it provides security benefits. In practice, that only helps if you can avoid the password ever being stored in a String. That is, if you take a password stored in a String and put the contents of the String into a char[], it doesn't magically make the String disappear from the heap. The necessary requirement is that the password never is placed in a String at all. I'd be interested to see that successfully implemented in a real Java application.

Answer 2

Almost everyone else's answer plus one additional point: Swap space on a storage media.

If the JVM heap is ever paged out to disk and the password is still in memory as a string (immutable and not GC'd), it will be written to the swap file. This swap file can then be scanned for password values, so, essentially another attack vector that's time based and still rather difficult to utilize but obviously not that difficult because we're here :D.

Wiping the mutable array at least reduces the time where the password is in memory.

The story I heard was that if an attacker can attack your process (like a DDOS) and trigger the process to swap out, it's somewhat easier to attack the swap space than the memory, AND swap space is preserved across boots/crashes/etc. This allows for yet another attack vector where the attacker pulls the swap drive out to scan the swap space.

Answer 3

First, let’s recall the reason for the recommendation to use char[] instead of String: Strings are immutable, so once the string is created, there is limited control over the contents of the string until (potentially well after) the memory is garbage collected. An attacker that can dump the process memory can thus potentially read the password data. Meanwhile the contents of the char[] object can be overwritten after it has been created. Assuming that this is done, and that the GC hasn’t moved the object to another physical memory location in the interim, this means that the password contents can be destroyed (somewhat) deterministically after it has been used. An attacker reading the process memory after that point won’t be able to get the password.

So using char[] instead of String lets you prevent a very specific attack scenario, where the attacker has full access to the process memory,¹ but only at specific points in time rather than continuously. And even under this scenario, using char[] and overwriting its contents does not prevent the attack, it just reduces its chance of success (if the attacker happens to read the process memory between the creation and the erasure of the password, they can read it).

I am not aware of any evidence that shows (a) how frequent this scenario is, nor (b) how much this mitigation reduces the probability of success under that scenario. As far as I know, this is pure guesswork.

In fact, on most systems, this scenario likely does not exist at all: an attacker who can get access to another process’ memory can also gain full tracing access. For instance, on both Linux and Windows any process that can read another process’ memory can also inject arbitrary logic into that process (e.g. via LD_PRELOAD and similar mechanisms²). So I would say that this mitigation at best has a limited benefit, and potentially none at all.

… Actually I can think of one specific counter-example: an application that loads an untrusted plugin library. As soon as that library is loaded via conventional means (i.e. in the same memory space), it has access to the parent application. In this scenario, it might make sense to use char[] instead of String, and overwrite its contents when done with it, if the password is handled before the plugin is loaded. But a better solution would be not to load untrusted plugins into the same memory space. A common alternative is to launch it in a separate process and communicate via IPC.

(See the answer by Gilles for more vulnerable scenarios. I still think that the benefit is relatively limited, but it’s clearly not nil.)

---

¹ As shown in Gilles’ answer, this is not correct: no full memory access is required to mount a successful attack.

² Although LD_PRELOAD specifically requires the attacker to not only have access to another process but either to launch that process, or to have access to its parent process.

Answer 4

(Note: I am a security expert but not a Java expert.)

Yes, there is a significant security advantage in using char[] rather than strings for passwords. This also applies to some extent to other highly confidential data, although most highly confidential data (e.g. cryptographic keys) tends to be bytes and not characters.

The old, and still valid, reason to use char[] is to clean up memory as soon as it is used, which is not possible with String. This is a very firmly established security practice. For example, in the (in)famous FIPS 140 requirements for cryptographic processing, which are generally considered to be security requirements, there are in fact extremely few security requirements at level 1 (the easiest level). Just two, in fact: one is that you may only used approved cryptographic algorithms, and the other one is that keys, passwords and other sensitive data must be wiped after use.

This practice is one of the reason why production implementations of cryptographic primitives are usually implemented in languages with manual memory management such as C, C++ or Rust: cryptography implementers want to retain control of where sensitive data goes, and to be sure to wipe all copies of sensitive material.

As an example of what can go wrong, consider the (in)famous Heartbleed bug. It allowed anyone on the Internet connecting to a vulnerable server to dump some of the memory of the server, without being detected. The attacker didn't get much control over which part of the memory, but could try again and again. An attacker could make requests that would cause the dumpable part to move around the heap, and thus could potentially dump the whole memory.

Are such bug common? No. This one got a lot of buzz because it was in a very popular software and the consequences were bad. But such bugs do exist and it's good to protect against them.

In addition, since Java 8, there is another reason, which is to avoid string deduplication. String deduplication means that if two String objects have the same content, they may be merged. String deduplication is problematic if an attacker can mount a side channel attack when the deduplication is attempted. The attack does not require the password to be deduplicated (although it is easier in this case): there's a problem as soon as some code compares the password against another string.

The usual way to compare strings for equality is:

• If the lengths are different, return false.
• Otherwise compare the characters one by one. As soon as there are different characters at one position, return false.
• If the end of the strings is reached without encountering a difference, return true.

This has a timing side channel: the time of the middle step depends on the number of identical characters at the beginning of the string. Suppose that an attacker can measure this time, and can upload some strings for comparison (e.g. by making legitimate requests to a server). The attacker notices that comparing with sssssssss takes slightly longer than comparing with aaaaaaaaa, so the password must begin with s. Then the attacker tries to vary the second character, and finds that comparing with swwwwwwww takes again slightly longer. And thus, in relatively short time, the attacker can reconstruct the password character by character.

In the context of string deduplication, the attack is harder, because (as far as I know) the deduplication code first hashes the strings to compare. This may mean that the attacker has to first guess the hash value. But the total number of hash values in a given hash table (that's the number of hash buckets, not the full range of the hash method) is small enough that it's practical to enumerate.

This is not an easy attack, to be sure. But I would absolutely not rule it out, especially with a local attacker, but even with a remote attacker. Remote timing attacks are practical (still).

In conclusion, yes, you should not use String for passwords. Read them as char[], keep careful track of any copies, hash them as soon as possible if you're verifying them, and wipe all copies.

If you need to store a password for a third-party service, it's a good idea to store it in encrypted form even if there is no separate access control for the encryption key. Copies of an encrypted password are less prone to leaking through side channels than copies of the password itself, which is a printable string with low entropy.

I think I've also read somewhere that the internals of URLConnection (and many other classes) uses String internally to handle the data. So if you ever send a password (although the password is encrypted by TLS over the wire), it will be in a String in your server's memory.

I'm not a Java expert, but this doesn't sound right: the plaintext of a connection (TLS or otherwise) is a byte stream, not a character stream. It should be arrays of 8-bit bytes, not arrays of Unicode code points.

Or that your password will end up in a String anyway due to classes written by others, is that why Thales' doing it.

Possibly. Or possibly because they aren't Java experts, or because the people who write the high-level layers are often not the foremost security experts.

Answer 5

It's not an idea of the moment of transfer over the network. There indeed you're indeed better off using a String as it's just more convient to use to send over the network, of course making sure it's properly encrypted.

For using passwords in applications it's different due to stack-dumps and reverse engineering, and the problem of the String being immutable: In case the password has been entered, even if the reference to the variable is changed to another string, there is no certainty about when the garbage collector will actually remove the String from the heap. So a hacker being able to see the dump will also be able to see the password. Using an array of char prevents this as you can change the data in the array directly without relying on the garbage collector.

Now you might say: well then when sending it over the network as a String it'll still be visible no? Well yes, but that's why encrypting it before sending it is important. Never send plain text passwords over the network when possible.