How does one store password hashes securely in mem

Question

Our web-based applications has user accounts tied down to users with the passwords specified during account creation. In the case of Java, how does one process the password securely, before persisting its hash in the database.

To be more specific, how does one ensure that the string holding the password is garbage collected within a sufficiently short interval of time ?

Answer 1

You do not use a String. You use a char[] and then overwrite the char[] when done.

There are absolutely no guarantees when it comes to garbage collection (aside from that the finalizer will run before the object is collected). The GC may never run, if it runs it may never GC the String that has the password in it.

Answer 2

If you create the hash on the client side, there should be no need to think about this problem. The plain password is never submitted to the server.

Answer 3

If you have the possibility (may be difficult in web applications), it would be better to store passwords in character arrays than to store them in strings. If you finished storing the password you can overwrite it in memory by using Array.fill() and make the reference available for the garbage collector by discarding it:

Arrays.fill(password, ' ');
password = null;

I just noticed that nulling the password would be a bit paranoid but you can do if it reassures you :)

Answer 4

Two words: Local Scope. The declared variables for password processing need to have the absolute smallest scope possible.

Once the variables go out of scope, the objects are eligible for garbage collection.

Often, you're picking things out of a request. You want a very, very small transaction that accepts the request, hashes the password, persists it and redirects. The page to which you redirect can then fetch content and do all the "other" processing that is part of your application.

Answer 5

There is no way to guarantee that clear text passwords are removed from memory in Java.

However a hacker doesn't need access to the memory of a program to get clear text passwords. There are much simpler ways (such as sniffing the packets) so it is highly unlikely anyone would rely on this approach.

The best approach is to have the client encrypt the password as @Mork0075 suggests. However, while it means you cannot easily get the password, a program can still get the encrypted version of passwords and so pretend to be a user. A way around this is to encrypt the whole connection using SSL.

All this is rather academic, as the simplest approach for a hacker is to monitor the packets to the database and get the password for your database. I suspect direct access to your database is more concerning... or perhaps its isn't. ;)

Answer 6

Use a password challenge:

1. Server chooses a challenge value and sends it to the Client
2. Server performs a 1-way translation with the password and the challenge, ex. MD5(CONCAT(challenge, password)) and assigns it to the session.
3. Plain-text password is now out-of-scope and ready for garbage collection.
4. Client also performs the same translation and sends the result to the Server.
5. If Server and Client choose the same final value, the client is authenticated.

This method prevents replay attacks, but requires the challenge value to be very unpredictable (random) and not often reused (long).

The plain-text password is only in scope during the handling of the initial connection request - not during authentication. It doesn't matter how long the 1-way translation result is in scope (not garbage collected) because it has little replay value.