Help coderanch get a
new server
by contributing to the fundraiser
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

char[] security

 
Ranch Hand
Posts: 664
Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is a good security reason for storing a password within a char[] rather than within a String?

 
Rancher
Posts: 436
2
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 441
Scala IntelliJ IDE Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 664
Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 441
Scala IntelliJ IDE Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 664
Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 441
Scala IntelliJ IDE Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 664
Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 436
2
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 664
Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Master Rancher
Posts: 4932
75
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Check out the javadoc for java.lang.String - the intern() method.
 
Ranch Hand
Posts: 245
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
There's a way to do it better - find it. -Edison. A better tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/t/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic