Password stored as a String is left in memory. A char[] is recommended because you can overwrite the value in the array. Strings are immutable, they can’t change. So if the String that had the password written to it was set to “null”, then in actuality, it is the reference that is set to null the data persists until the GC eats it up. Until then that gives the hacker time to grab that memory block and abuse it (putting it nicely).
By overwriting the char array with 0s you are giving the hacker less time to crack the memory.
@squizzle said:
Password stored as a String is left in memory. A char[] is recommended because you can overwrite the value in the array. Strings are immutable, they can't change. So if the String that had the password written to it was set to "null", then in actuality, it is the reference that is set to null the data persists until the GC eats it up. Until then that gives the hacker time to grab that memory block and abuse it (putting it nicely).
By overwriting the char array with 0s you are giving the hacker less time to crack the memory.
I need to sleep I worded that so horribly. The above is referring to the Password “control”. The Password#getVisibleText method is grabbing the “masked text” from a String. My approach would be to let them grab it once and clear the password char array. If the password verification failes then they have to create the Password control to submit a password again.
The password control isn’t meant to solve someone security related issues. It provides a mask for character on screen… The characters being fed to the control via input are in plain text, so I’m not really sure what I could do to solve this.
You know that the whole pseudo password stuff is not worth it? If i can read memory on your machine, I can just attach a global keylistener
Or i could inject myself into the vm and then read it there via normal means
Or I could replace the passwordinput class with a own implementation by manipulating the bootstrapper.
In short if the computer is compromised, everything you input is.
@Empire Phoenix said:
You know that the whole pseudo password stuff is not worth it? If i can read memory on your machine, I can just attach a global keylistener
Or i could inject myself into the vm and then read it there via normal means
Or I could replace the passwordinput class with a own implementation by manipulating the bootstrapper.
In short if the computer is compromised, everything you input is.
Yeah, even Swing does this char[] buffer thing and suggests clearing it out. I’ve always thought it rather curious because if I wanted to get your password then I’d just use a keylogger. Seems WAY easier than sifting through memory.
On the other hand, that String could be potentially really long-lived for some apps. So I don’t doubt that Sun (original writer of the docs in that class) is right (especially in browser-land) but it does seem a little overly paranoid to me.
@t0neg0d said:
But... this assumes you can get a keystroke logger on to my machine AND that my game account password is actually worth the effort ;)
I do have a bitchin’ lvl 604 dual class monk/accountant on Zombies vs Fluffy Bunnies (pvp server of course)
So it may be worth the effort after all
Many many people use the same password everywhere. So the general theory is that for some percentage of people, if you get their password in one place then you have a decent start on getting in everywhere else they’ve been.
This is one of the reasons passwords should be stored in salted hashes on servers. A breach is one thing and can be corrected… but having the users’ passwords means you will likely get lots of nice hits elsewhere.
Actually while there is a small benefit in using a char[] array to be able to 0 it afterwards that is not actually the main advantage.
The main advantage is that if you ever accidentally log a password with a String the password will be shown. With a char[] then the contents will not be shown.
It’s one of those small things that doesn’t really bring big benefits but is easy enough to do and does guard against accidents a bit.
@zarch said:
Actually while there is a small benefit in using a char[] array to be able to 0 it afterwards that is not actually the main advantage.
The main advantage is that if you ever accidentally log a password with a String the password will be shown. With a char[] then the contents will not be shown.
It’s one of those small things that doesn’t really bring big benefits but is easy enough to do and does guard against accidents a bit.
Just for the sake of explaining why the password control stores things the way it does…
Password extends TextFields…
TextField is 2000(ish) lines of code… it’s the nature of the beast. This includes all of the code needed for text ranges, caret display, click-placement of caret, click-drag-relase selection, SHIFT+arrow movement, CTRL+SHIFT+arrow selection, double-click selection , triple-click selection, Mac & Android compatibility, clip-board usage (if I can ever resolve the Android issue), display text vs all text, forced character limitation (standard numeric, alpha numeric, etc… and custom user defined grab-bags) etc, etc, etc. - I need tostop adding to this list, I’ll be here all day
Password does nothing more than add a character mask to TextField.
I dread the thought of even considering making password a version of TextField that does all this without the use of String. /gulp. EDIT: Especially considering there is nothing I can do to prevent the above mentioned (most common) method of capturing someones password from the local machine. No matter what I do.
My suggestion was for a small layer of security I wasn’t going professional grade A security with my suggestion. I should’ve added that it was for simple security measures.
Since we are on the subject, what about going with KeyStore? There is a means around everything but would it be a extra layer to piss off wannabe ne’er do wells? Granted you have to have a password to access the KeyStore… but the password could be the constructed from different parameters (mac address plus salt?).
It remains the question about the gain?
If the computer is compromised i can just use jmx to get everything I want right from the source. By connecting the the jvm and adding a breakpoint right at the login part, grabbing the variables and letting ti continue.
If the computer is not compromised, the gain is really low. An additional System.gc() might just do enough as well and gc the String then in most cases.
