md5 hash for password string in GWT/GWT-Ext?

Question

I am currently trying to modify an existing GWT-Ext application, that is using plain text passwords in its MySql database.

My plan was to use md5 hashes, as the existing passwords can be easily altered with the MySql function and I was expecting to find an easy solution for the GWT-Ext side as well. But as I found out, java.security is not supported by GWT and there doesn't seem to be any other implementation that can be used to change the password string to a md5 hash on client side.

Only "solution" I found so far, is to re implement a md5 method via JSNI as described here: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/ad09475a9944c9f8

There is an existing user extension for Ext-JS, but I couldn't find anything for GWT-Ext: http://extjs.com/forum/showthread.php?p=133516

Does anybody know a more elegant/simple way to solve this problem? Maybe I should use something else instead of md5 to make sure the passwords are encrypted?

Cheers Frank

Answer 1

Personally, I would say you're doing it wrong. I wouldn't hash a password on the client side (which is what GWT is). If you hash your password, you will undoubtedly want to salt it, otherwise you will be susceptible to rainbow attacks. If you hash + salt it on the client side, your salt will be accessible to your users.

If I were you, I would hash + salt your password on the server side. This will allow you to use your standard Java code to perform your MD5 hash.

My 2 cents.

-JP

Answer 2

Another idea that may fit your need is something called zero knowledge auth. (Ie. the server never needs to know the user's plain text password.)

Basically, when setting the initial password, the client hashes the user's password N times (where N is a largish number like 1000), and then sends that final hash to the server along with N. The server stores the hash and N.

Later, when the user wants to authenticate, the server tells the client N-1, and the client hashes the password the user types N-1 times and sends that to the server. The server does 1 more hash on the received hash, and (hopefully) gets the stored hash. The server then stores the N-1 hash and N-1 number.

Each time the user authenticates, the server decrements the stored N and saves the previous hash.

When N gets down to 0, the user must choose and set a new password.

The server must ensure that it never asks for the same iteration, otherwise it is vulnerable to a replay. You can't really enforce that condition from the client side because the client (especially a browser) can't reliably keep track of the last N.