4

Sorry to bring this topic up again, I have carefully read another similar question Why does JPasswordField.getPassword() create a String with the password in it?

However I still think there is a loophole in JpasswordField implementation. I still see password being stored in Memory maybe in different data types, not String.

Step that I did: Download the JPasswordField Demo code from Oracle https://docs.oracle.com/javase/tutorial/displayCode.html?code=https://docs.oracle.com/javase/tutorial/uiswing/examples/components/PasswordDemoProject/src/components/PasswordDemo.java

and run it. It will bring up the password dialog.

password dialog

Type in "bugaboo"

Hit enter and see that password is correct. (I delete the typed in password, the end result is the same with/without this delete)

Now at this point, due to the code to clear password content in 

    //Zero out the password.
    Arrays.fill(correctPassword,'0');

I expect there is no leftover bugaboo in memory, however there is. I used http://www.sweetscape.com/010editor/ to examine the memory content and still see "bugaboo" in clear text bugaboo

Conclusion: the reason for this is that JpasswordField internally use PlainDocument and it litter your memory with the whole history of what was keyed in. Hence you cannot fully clear the password clear text in memory.

Therefore the effort to use getPassword() as char[] and clear it afterwards doesn't have much benefit.

Please enlighten me.

Community
  • 1
  • 1
HenryNguyen
  • 1,153
  • 1
  • 10
  • 8
  • Well it has to be stored somewhere, *nu*? – user207421 Apr 24 '16 at 21:30
  • 1
    @EJP The point is that you cannot reliably clear a `PlainDocument`. So the answer to this question is "Yes." (FWIW IIRC, you also get a `String` if you add an `ActionListener`.) – Tom Hawtin - tackline Apr 24 '16 at 22:19
  • @TomHawtin-tackline The point is that it *can't* be secured, if 'secured' means 'not having the password in memory'. All that can be accomplished is providing a `char[]`-based API to avoid the more obvious `String`-based exploits. – user207421 Apr 24 '16 at 22:35

1 Answers1

0

When you retrieve the password from the JPasswordField you just get a copy. The Document object in the JPasswordField still has an own character array containing the password. I guess this is the value that you see in your memory viewer.

Now an idea would be to clear the JPasswordField after one has verified the password:

passwordField.setText("");

Ironically this raises an UndoableEditEvent containing a javax.swing.text.GapContent$RemoveUndo object which stores the password as String object - something which we tried to avoid in the first place.

wero
  • 32,544
  • 3
  • 59
  • 84