Why does JPasswordField.getPassword() create a String with the password in it?

Question

Swing's JPasswordField has the getPassword() method that returns a char array. My understanding of this is that the array can be zeroed immediately after use so that you do not have sensitive things hanging around in memory for long. The old way to retrieve the password was to use getText(), which returns a String object, but it has been deprecated.

So, my question is why it is actually being used by Java during the retrieval process using getPassword()??? To be clearer, I was debugging my test app for something else**, I followed the calls and bang... getText() in JPasswordField was called and, of course, a nice String object with my password has been created and now is hanging around the memory.

Try it for yourself:

public class PasswordTest() {
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        JPasswordField passField = new JPasswordField();
        pass.addActionListener(new ActionListener() {
            public ActionPerformed(ActionEvent evt) {
                char[] p = passField.getPassword(); // put breakpoint
                // do something with the array
            }
        });
        frame.add(passField);
        frame.setVisible(true);
        frame.pack();
    }
}

Follow up question: is this 'hidden' use of getText() dangerous in any way? Of course a dedicated attacker WILL get your password if it has compromised the system, I am talking about a less dedicated one ;)

**I came across this while I was looking for a way to actually display some sensitive data on a Swing component without using a String object. Apparently there is no way to do it unless I am willing to rewrite part (all?) of the Swing API.. not gonna happen.

Solution 1

This works for me and helps you to build a Stringified password:

String passText = new String(passField.getPassword());

Solution 2

Actually, here's the Sun implementation of getPassword():

public char[] getPassword() {
    Document doc = getDocument();
    Segment txt = new Segment();
    try {
        doc.getText(0, doc.getLength(), txt); // use the non-String API
    } catch (BadLocationException e) {
        return null;
    }
    char[] retValue = new char[txt.count];
    System.arraycopy(txt.array, txt.offset, retValue, 0, txt.count);
    return retValue;
}

The only getText in there is a call to getText(int offset, int length, Segment txt), which calls getChars(int where, int len, Segment txt), which in turn copies characters directly into the Segment's buffer. There are no Strings being created there.

Then, the Segment's buffer is copied into the return value and zeroed out before the method returns.

In other words: There is no extra copy of the password hanging around anywhere. It's perfectly safe as long as you use it as directed.

Solution 3

The Swing implementation is too complex to check by hand. You want tests.

public class Pwd {
    public static void main(String[] args) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                new javax.swing.JFrame("Pwd") {{
                    add(new javax.swing.JPasswordField() {
                        @Override public String getText() {
                            System.err.println("Awoooga!!");
                            return super.getText();
                        }
                        {
                            addActionListener(
                                new java.awt.event.ActionListener() {
                                    public void actionPerformed(
                                        java.awt.event.ActionEvent event
                                    ) {
                                        // Nice.
                                    }
                                }
                            );
                        }
                    });
                    setDefaultCloseOperation(DISPOSE_ON_CLOSE);
                    pack();
                    setVisible(true);
                }};
            }
        });
    }
}

Looks like the command string for the (pointless) action event to me. There will be other way to cause the effect as well.

A vaguely modern VM will move objects in memory anyway, so clearing the char[] does not necessarily work.

Solution 4

**I came across this while I was looking for a way to actually display some sensitive data on a Swing component without using a String object. Apparently there is no way to do it unless I am willing to rewrite part (all?) of the Swing API.. not gonna happen.

You can tell a JPasswordField to display the characters by calling field.setEchoChar('\0'). This retains the rest of the protection offered by JPasswordField (no Strings, no cut/copy).

View more solutions