entering Password (a String) without leaving in-memory traces

Discussion in 'Java' started by otf, Nov 28, 2005.

  1. otf

    otf Guest

    Hi *,

    I remember I once read an article at java.sun.com about how you could
    implement certain functionality extending JTextPassword that would not
    leave in-memory traces of the characters entered

    I read about it, I think at the technical articles and tips forum, but at
    that time I didn't have the time to dive into it. Now, I can not find
    it :-(

    Does anyone here have these ideas fresh and remember/know what the links
    are?

    Thanks
    otf
    otf, Nov 28, 2005
    #1
    1. Advertising

  2. otf

    Chris Smith Guest

    otf <> wrote:
    > I remember I once read an article at java.sun.com about how you could
    > implement certain functionality extending JTextPassword that would not
    > leave in-memory traces of the characters entered
    >
    > I read about it, I think at the technical articles and tips forum, but at
    > that time I didn't have the time to dive into it. Now, I can not find
    > it :-(


    The class is JPasswordField. Create it without an initial value, and
    call getPassword instead of getText. Zero out the char[] after you're
    done with the value. You have to be careful not to create your own
    String objects out of the result, though.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Nov 28, 2005
    #2
    1. Advertising

  3. otf

    Roedy Green Guest

    On Mon, 28 Nov 2005 15:37:54 -0500, otf <>
    wrote, quoted or indirectly quoted someone who said :

    >Does anyone here have these ideas fresh and remember/know what the links
    >are?


    basically the idea is you never let the password exists as a string,
    only as a char[]. That way you can zap it.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 28, 2005
    #3
  4. otf

    Chris Uppal Guest

    Chris Smith wrote:

    > The class is JPasswordField. Create it without an initial value, and
    > call getPassword instead of getText. Zero out the char[] after you're
    > done with the value. You have to be careful not to create your own
    > String objects out of the result, though.


    Even with those cautions, I doubt whether JPasswordField counts as "not leaving
    in-memory traces", not when there's a copying garbage collector in the system.

    AFAIK, it's not actually possible to do on all OSes -- at least the crypto
    people seem fairly sure that there's no defined way of doing it (that actually
    /works/) on Windows.

    Not to say that JPasswordField, if used as Chris describes, isn't a reasonable
    solution for a given application.

    Actually, looking at the code, I'm not too impressed. In terms of sofware
    engineering, it inherits from JTextField and (therefore) uses Document --
    complex classes that have no security responsibilities themeselves and which
    are therefore fragile if used in a secure context. In terms of functionality,
    there is no need to keep the password text "in plain" in memory at all, and
    there should be an API for retrieving it without assembling it into a String or
    char[]. You can't get security against an attacker who is able to review /all/
    the contents of memory, but you can certainly -- and quite easily -- make the
    job of a would-be attacker using a partial memory trace (say from the "swap"
    file), and lacking the resources of a major governement, much harder or even
    (perhaps) impossible. Of course, for that level of protection to make sense,
    there must also be a way to /use/ the password which doesn't require assembling
    it into plaintext in memory, and (afaik) such APIs don't commonly exist, and
    for some purposes may not even be possible.

    -- chris
    Chris Uppal, Nov 29, 2005
    #4
  5. otf

    Chris Smith Guest

    Chris Uppal <-THIS.org> wrote:
    > Even with those cautions, I doubt whether JPasswordField counts as "not leaving
    > in-memory traces", not when there's a copying garbage collector in the system.


    Indeed. On the other hand (but for the problems below) it would at
    least be possible to minimize the probability. So long as the object
    were not kept for long, it would be unlikely to copied too much, and the
    younger generations would be likely to be overwritten quickly with newly
    allocated objects.

    Problems with copies due to virtual memory in the operating system are
    equally difficult and far less transient, but are also even less likely
    to happen so long as the data is disposed of quickly.

    > Actually, looking at the code, I'm not too impressed.


    Looking at the code, I'm not too impressed, either. I had assumed that
    JPasswordField used a custom implementation of Document that prevents
    discarded copies of data, and that getPassword() returned the actual
    underlying char[] used by the Document implementation. It turns out
    that's not the case; there is no special-purpose document, and
    getPassword() just makes another copy of the text. This makes
    getPassword basically useless; may as well use getText instead.

    Except that getText is deprecated. That, then, is the kind of arrogance
    in API design that gets my hackles up from Sun occasionally. Even if
    JPasswordField and getPassword() were implemented properly, this kind of
    trick would be unnecessary in 99% of cases where JPasswordField is used.
    Instead of allowing for that, someone from Sun decides to demonstrate
    horrible OO design (deprecating a method in a subclass that is public
    and definitely not deprecated in the superclass) and take away a tool
    that could prevent a conversion step in the normal case of an
    application.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Nov 29, 2005
    #5
  6. otf

    Roedy Green Guest

    On Tue, 29 Nov 2005 10:41:09 -0000, "Chris Uppal"
    <-THIS.org> wrote, quoted or indirectly
    quoted someone who said :

    >Even with those cautions, I doubt whether JPasswordField counts as "not leaving
    >in-memory traces", not when there's a copying garbage collector in the system.


    here is the code for JPassword.getPassword. You are supposed to clear
    the returned array after you are finished with it. It seems to me
    there are still TWO copies of the password lying around in RAM after
    this is done: the uncollected Segment and the Document.
    You could wipe the document with setText("ZZZZZZZZZZZZZZZZZZZZZZZZ");
    For better security Sun should have zapped the segment after copying
    it to the final array.

    /**
    * Returns the text contained in this <code>TextComponent</code>.
    * If the underlying document is <code>null</code>, will give a
    * <code>NullPointerException</code>. For stronger
    * security, it is recommended that the returned character array
    be
    * cleared after use by setting each character to zero.
    *
    * @return the text
    */
    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;
    }

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 29, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Twisted
    Replies:
    1
    Views:
    1,046
    Twisted
    Feb 24, 2006
  2. Tuvas

    Password entering system

    Tuvas, Mar 10, 2006, in forum: Python
    Replies:
    4
    Views:
    353
    Tuvas
    Mar 10, 2006
  3. rodrigo
    Replies:
    3
    Views:
    752
    Ryan Ginstrom
    Oct 15, 2007
  4. AAaron123
    Replies:
    2
    Views:
    2,099
    AAaron123
    Jan 16, 2009
  5. AAaron123
    Replies:
    1
    Views:
    1,318
    Oriane
    Jan 16, 2009
Loading...

Share This Page