3

After reading this beautiful question: Why is char[] preferred over String for passwords?, I'm curious as to how this applies to servlet based web applications. Say your UI has some input field for the password, the password will be retrievable with request.getParameter("passwordFieldName") which returns a String. Even if you then convert it to a char[], you have to wait for GC to clear the String object.

Also, many of the Encryption/Hashing libraries I'm looking into using for password hashing have a method such as checkPassword(plaintext, hashed) that takes two Strings and returns true if the entered plain text string gives a hash equal to hashed. With this, even if you had a char[], you would still need to convert the array to a String with the new String(char[]) constructor.

It seems to me like you can't really avoid having your password as a String for comparing it to its stored representation. If you are worried about attacks during that small window, how do you protect yourself?

Community
  • 1
  • 1
Sotirios Delimanolis
  • 274,122
  • 60
  • 696
  • 724
  • As the answers to the question you brought already state, it's mostly overkill and the things you have to pull out (you're listing some of them in your question already) cause more concern than safety. If you're worried about that small window of time, please check some other things in your implementation (full access to JVM and hard disk, for example). – Alfabravo Dec 10 '12 at 16:19

1 Answers1

2

This is an overreaction and really just "security theater". There is really no scenario in which having a long String as a password in a Java application would be at all desirable to an attacker. If a memory exhaustion attack is a concern, then don't use Strings anywhere.

That being said CWE-521 states that passwords must have a max size. Strings don't really have a max size, and using a char[x] is a good way of enforcing a max size.

rook
  • 66,304
  • 38
  • 162
  • 239
  • `String` doesn't, but the persistence layer has constraints for that usually. – Sotirios Delimanolis Dec 10 '12 at 18:45
  • `char[]` doesn't have a maximum size in exactly the same way `String` doesn't either. Are you thinking passing an existing maximum-sized `char[]` to a callback and having that mutated? As far as I am aware, APIs are not usually written like that in Java. / Real scenarios would be core dumps, directly reading memory, swap files, hibernation files and spraying refrigerant onto the DRAMs so they can be whipped out into another machine for reading. – Tom Hawtin - tackline Dec 11 '12 at 12:30
  • No, nothing so extreme. I just meant that even though a `String` doesn't have a maximum size, if you try to write it into a database that has a mapping field, for example, `varchar(10)`, your `String` would be refused. – Sotirios Delimanolis Dec 11 '12 at 15:02
  • @Sotirios Delimanolis but you shouldn't be storing the password in the database in plain text, that is a very obvious mistake. A hash will always have the same size, even if its stored in a String. – rook Dec 11 '12 at 16:49
  • Ya, I'm just pointing out that CWE-521 limit on the size of a password can be constrained by other things than just which data structure you are using to hold it, be it database constraints or business logic. – Sotirios Delimanolis Dec 11 '12 at 18:48
  • 1
    @Sotirios Delimanolis yeah and i'm saying doing this with database logic would be a much much much much much more serious vulnerability. It would be plaintext password storage. – rook Dec 11 '12 at 18:55