Skip to Main Content

Java Programming

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Secure password usage, JPasswordField, and JVM heaps

NigelB-OracleNov 5 2010 — edited Nov 8 2010
Hi,

Can anyone advise me on whether constructing a JPasswordField with a String password presents any security risks?

[Passwords should be stored as char[] objects, rather than Strings, so that they can be overwritten when the password is finished with. Strings will hang around on the heap until garbage collection and so will not be secure.]

For a JPasswordField, the constructor takes a String parameter containing the password, and then internally stores it as a char[]. The internal storage and access via getPassword() are fine - I don't have a problem with them. My question is whether the String object that is passed into the constructor is secure?

For example,

myMethod(char[] password) {
// create new password field passing in the required String
JPasswordField pwdField = new JPasswordField(new String(password));
}

As you can see, I have to create a new String object just to pass it to the JPasswordField class.

After some investigation, I found that in the JVM that I'm using, the anonymous use of the new String() constructor doesn't seem to hang around on the heap. The garbage collector is not being invoked (running with -verbose:gc), so I'm not sure what's cleaning it up, or whether it's still in memory somewhere else, just unreferenced.

After googling aound, I can't say if this is standard behaviour for all JVMs, whether it's still in memory somewhere else but unreferenced, and whether we can rely on this behaviour in the future.

Bottom line, I guess is whether passing a password to a method via new String(password) is secure from the callers perspective, subject to the called method handling it securely.

Thanks,

Nigel.
Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Dec 6 2010
Added on Nov 5 2010
18 comments
927 views