Thursday, March 15, 2012

Why character array is better than String for storing password in Java was recent question asked to one of my friend in a java interview. he was interviewing for a Technical lead position and has over 6 years of experience.Both Character array and String can be used to store text data but choosing one over other is difficult question if you haven't faced the situation already. But as my friend said any question related to String must have a clue on special property of Strings like immutability and he used that to convince interviewer. here we will explore some reasons on why should you used char[] for storing password than String.

1) Since Strings are immutable in Java if you store password as plain text it will be available in memory until Garbage collector clears it and since String are used in String pool for reusability there is pretty high chance that it will be remain in memory for long duration, which pose a security threat. Since any one who has access to memory dump can find the password in clear text and that's another reason you should always used an encrypted password than plain text. Since Strings are immutable there is no way contents of Strings can be changed because any change will produce new String, while if you char[] you can still set all his element as blank or zero. So Storing password in character array clearly mitigates security risk of stealing password.

2) Java itself recommends using getPassword() method of JPasswordField which returns a char[] and deprecatedgetText() method which returns password in clear text stating security reason. Its good to follow advice from Java team and adhering to standard rather than going against it.

3) With String there is always a risk of printing plain text in log file or console but if use Array you won't print contents of array instead its memory location get printed. though not a real reason but still make sense.

That's all on why character array is better choice than String for storing passwords in Java. Though using char[] is not just enough you need to erase content to be more secure. I also suggest working with hash'd or encrypted password instead of plain text and clearing it from memory as soon as authentication is completed.

Using char[] instead of String for passwords is (IMHO) a bad idea for a few reasons:

1. That's going to massively complicate things. Strings maintain information about character encodings - char[] (obviously) does not. So if you use char[], you have to be very careful to always use the same encoding. This is critical if you support non-US English users (and you should always do that!).

2. If a malicious user gets access to read core dump files in /tmp, it's game over anyways. At that point, it means that not only has a malicious user gained access to your server, but he's also gained either root or application user access - so he's fully compromised the system.

3. char[] are not pinned to RAM. The OS swaps char[] data just as easily as String data, writing it to disk in the swap file.

4. Strings may be immutable, making it more likely that they hang around for a while in memory due to string internment, but char[]'s aren't guaranteed to be removed from memory either due to the uncertainties of garbage collections. You can never be sure any memory is cleared in Java, nor can you tell Java to clear any memory.

Using char[] instead of String makes your code buggier, harder to maintain, harder to write, and only more secure in a totally impractical sense.

There are a few mistakes here. First, there is no real "danger" of a password String being logged, since it would only happen if you explicitly log it.

Second, you can easily print the contents of an array using Arrays.toString(), so if you're afraid your fingers will type logger.info(password), well, they might also accidentally type logger.info(Arrays.toString(password)).

Finally, there is no safety from serialization using an array instead of a String. Yes, it's true that Strings are Serializable; so are arrays.

Strings don't keep any information about encoding -- they just have a char[], and a char is a unicode code point in utf-16. You can create a String from a byte[] and an encoding, and given a String you can get a byte[] if you give it an encoding -- but the String itself has no encoding other than the utf-16 of its chars.

There is API provided by Java itself to get the characters in an array. Please have a look at below code snippet, there is no use of array over string other in this scenario but memory wise yes it is:System.out.println("Character password: " + Arrays.toString(charPassword));

As you said that if someone who have acess to memory dump can know the passwords if it is string form,and in char array it will be known only the address, As he know the memory dump Wont he able to find the passsowrd using that address which he knows.

"String are used in String pool for reusability" is generally not correct in this case.

Only certain types of strings are interned in the permanent generation. Strings created dynamically at runtime, i.e. strings in a HTTP request, are not. Consider this: if every String pulled in a HTTP request was interned, you'd consume all of the permanent gen quickly.

This may be different for nonstandard JVMs, but for the Oracle VM this is correct.