Passwords are recommended to be stored in char[] instead of String, as Strings are stored in StringPool. Read more here

As per this question Strings in StringPool are not available directly. To obtain Strings in Stringpool, we would need a password-dictionary to check them in StringPool. If we have a password-dictionary, we don't need to worry about StringPool, we can anyhow try directly on password fields.

To prevent Brute-force attack we are limiting number of re-tries for passwords and checking for any suspicious activities.

If all that is in place still should we not use "String" as a datatype for passwords?

The answer obtained from similar questions is: We can have access to memory dump and get access to Strings in stringpool.

Follow up questions:

  • How can one access the memory dump?
  • Can the access be prevented?
  • If access to memory dump is prevented, Is it safe to use String as a type for passwords?
  • 1
    Passwords shouldn't be stored at all. Anyway, if you read the article carefully, what it says is that using char[] instead of string allows you to zero-out the password in memory, which is true. You can't do that with strings because they're immutable, so theoretically you could still retrieve the passwords from the computer's memory after they ave been garbage-collected. Commented Aug 1, 2015 at 5:18

2 Answers 2


The String, once created, exists in memory until a garbage collection is run. If anything has a reference to it, it isn't collected. Compare this to the code:

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

While the character array may exist for some time, the values within the character array are gone once that Arrays.fill runs. In this way the password stored within a char[] has a known duration that can be reasoned about, unlike the duration of a String on the heap.

Creating a memory dump is as easy as running a program where you can connect to the various virtual machines. VisualVM can do it quite nicely.

enter image description here


enter image description here

Go to classes, double click on String...

enter image description here

And then you have every instance of a String that is running in the JVM at the time of the memory dump.

enter image description here

While this implies some access to the machine, the key takeaway is that it is really quite easy to get a heap dump and examine it. There's even an SQL like language for it called OQL for doing queries against it.

The reason to use a char[] is to limit your exposure to a memory dump. If you note the line right under the String in the memory dump was char[] and they are in there too.

Security minded individuals are especially concerned of this on Android where one could steal a device and do a memory dump of running processes thus collecting passwords to all of the apps that stored their passwords in Strings that haven't been garbage collected yet.


Memory dumps can be obtained in a variety of ways, depending on what exact type of system your application runs on. Typically, creating a memory dump would require access to run processes on either the server your application runs on, or if it's a VM it could also be done from the VM host. Blanking passwords is a mitigation measure to reduce the amount of damage a hacker can do if he gets this access.

In general, it is impossible to guarantee that access to create memory dumps has been prevented, because new operating system level vulnerabilities are discovered with relatively high frequency, and therefore you cannot know that no attacker has a working route into your system that you (and potentially the OS vendor) is unaware of. Inside attacks (e.g. by disgruntled employees) may also be mitigated by this approach, so even if you assume you are safe from external attack it is still best practise to zero passwords as soon as you are finished with hashing them.

  • In case of Android, how reasonable is to avoid using Strings for passwords/private keys, when other apps cannot possible access StringPool?
    – soshial
    Commented Feb 19 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.