This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Java in General and the fly likes char[] security Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "char[] security" Watch "char[] security" New topic
Author

char[] security

Jon Camilleri
Ranch Hand

Joined: Apr 25, 2008
Posts: 660

What is a good security reason for storing a password within a char[] rather than within a String?


Jon
Hauke Ingmar Schmidt
Rancher

Joined: Nov 18, 2008
Posts: 433
    
    2
Your char[] is not reused or interned like strings are, so you have complete control over the data. An interned string, i.e. one in the string cache, can show up in diagnosis tools or memory dumps even after you dumped the original data.
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

Strings aren't interned unless they're hard-coded as literals (which a password obviously isn't) or they're explicitly interned using the intern() method... or am I missing something?
Jon Camilleri
Ranch Hand

Joined: Apr 25, 2008
Posts: 660

Luigi Plinge wrote:Strings aren't interned unless they're hard-coded as literals (which a password obviously isn't) or they're explicitly interned using the intern() method... or am I missing something?


Would you kindly clarify with an example, please?

Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441


I guess if you were to do something dumb like hard-code a password into a class, it would make more sense to use a char[], but even then someone could just look for a list of chars in the class file, or decompile it to source. So worrying about memory dumps etc seems strange, unless I'm missing something, which is very possible.

It's good practice to set a password String to null, as above, as soon as you've finished with it.
Jon Camilleri
Ranch Hand

Joined: Apr 25, 2008
Posts: 660

Luigi Plinge wrote:
I guess if you were to do something dumb like hard-code a password into a class, it would make more sense to use a char[], but even then someone could just look for a list of chars in the class file, or decompile it to source. So worrying about memory dumps etc seems strange, unless I'm missing something, which is very possible.

It's good practice to set a password String to null, as above, as soon as you've finished with it.


Yes, I agree it's a bit weird to worry about reading passwords off memory dumps, since users normally don't bother to do that, but we're wary of hackers In a business scenario I would store encrypted passwords, and, set the password to null as soon as I have validated it.
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

Well my point was that since you should never have a literal password in your code, it won't make any difference if you use a String or char[]!
Jon Camilleri
Ranch Hand

Joined: Apr 25, 2008
Posts: 660

Luigi Plinge wrote:Well my point was that since you should never have a literal password in your code, it won't make any difference if you use a String or char[]!

Yeah, but Horstmann and Cornell suggest that it is good practice to use char[], hence, I thought it would be safer to ask why before making assumptions.


Source: Core Java Vol 1 (8th Ed) P.64, 473
Hauke Ingmar Schmidt
Rancher

Joined: Nov 18, 2008
Posts: 433
    
    2
Luigi Plinge wrote:Strings aren't interned unless they're hard-coded as literals (which a password obviously isn't) or they're explicitly interned using the intern() method... or am I missing something?


Literal Strings are automatically interned, as stated in the documentation. There is no statement about other Strings, neither positive nor negative, but there exists a JVM flag for a generic String cache: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

But: You don't know what happens when you use other technologies that will work with your password, and typically there are some involved, e.g. persistence and web. Serialization can be involved or even other String operations like trimming that could intern. With a char[] you know nothing of that sort will happen.
Jon Camilleri
Ranch Hand

Joined: Apr 25, 2008
Posts: 660

Hauke Ingmar Schmidt wrote:
Luigi Plinge wrote:Strings aren't interned unless they're hard-coded as literals (which a password obviously isn't) or they're explicitly interned using the intern() method... or am I missing something?


Literal Strings are automatically interned, as stated in the documentation. There is no statement about other Strings, neither positive nor negative, but there exists a JVM flag for a generic String cache: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

But: You don't know what happens when you use other technologies that will work with your password, and typically there are some involved, e.g. persistence and web. Serialization can be involved or even other String operations like trimming that could intern. With a char[] you know nothing of that sort will happen.


What do you mean by 'interned', please?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Check out the javadoc for java.lang.String - the intern() method.
Vlado Zajac
Ranch Hand

Joined: Aug 03, 2004
Posts: 245
The reason for using char[] is that you can fill it with zeroes after use.
Check the javadoc for JPasswordField.

It can't be done with String because Strings are immutable.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: char[] security