Results 1 to 4 of 4

Thread: Spring Security uses String for password

  1. #1
    Join Date
    Apr 2009
    Posts
    1

    Default Spring Security uses String for password

    Hi,

    By default, Spring security uses String for password fields in its implementation. That's not a good security practice in general. It worried me a bit about using a immutable field for sensitive information. I understand the reason most likely is ease of use for most users but is their a more secure alternative like char[]?

    Thanks,
    -Rishi

  2. #2
    Join Date
    Sep 2004
    Location
    Manchester, NH
    Posts
    1,236

    Default

    Sorry, I don't follow your argument. How is using an immutable String bad security practice?
    Peter Mularien | Blog
    Author, Spring Security 3 (Book) - Packt Publishing, Available in print and eBook form
    SCJP 5, Oracle DBA
    Any postings are my own opinion, and should not be attributed to my employer or clients.


  3. #3
    Join Date
    May 2008
    Posts
    153

    Default

    The argument he is making is probably this:

    - String in Java is immutable, and therefore, an in-memory secret represented as a String an cannot be destroyed.
    - If you have secrets stored in memory, and that memory gets swapped to disk, another process on the same box can allocate large chunks of memory at random, and potentially look for passwords in the uninitialized memory they get back.
    - If you store a password as char[], you can do something like:
    Code:
    char [] password = getPassword();
    submitPassword(password);
    zero(password);
    This will reduce the time the secret is stored in memory, and reduce the likelihood of exposing it through an unintended channel.

    I don't know if this argument is still valid for modern OSs, but I have noticed that some of the java security APIs have moved aware from String in favor of char[] (the Keystore API for example). Also the swing components for reading password all use char[] now too.

    For web applications, I'm not so sure it matters -- in a web server, you are usually always going to get the password from a form, so its going through the HTTP request, the servlet API and has already been converted to a String.

    If your web server/servlet engine has some way of clearing out the memory used by the request when the servlet handing thread is done with it, then it would make sense to worry about your framework code not following the destroyable interface; but I sort of doubt that modern web containers actually do this.

  4. #4
    Join Date
    Sep 2004
    Location
    Manchester, NH
    Posts
    1,236

    Default

    Excellent explanation, honeybunny!

    It's too bad we don't have something in Java like the .NET SecureString class
    Peter Mularien | Blog
    Author, Spring Security 3 (Book) - Packt Publishing, Available in print and eBook form
    SCJP 5, Oracle DBA
    Any postings are my own opinion, and should not be attributed to my employer or clients.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •