4

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

FrankS
  • 2,374
  • 3
  • 26
  • 32

5 Answers5

9

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

JP Richardson
  • 38,609
  • 36
  • 119
  • 151
  • Its not a bad scheme if he does something like cram-md5 on the client side, where the client computes a hmac (md5 hash plus a nonce salt) and sends it to the server. The down side is that the server needs clear text password to check the hmac. – Trevor Harrison Aug 06 '09 at 18:59
  • good point about the rainbow attacks, didn't knew about this before. I also solved it by doing the encryption on the server side, but the idea was, that I wanted to encrypt the password, before sending it to the server, as we currently only use http and no https. – FrankS Aug 06 '09 at 21:27
  • GWT is client-side and server side. Other than that, the post is good advice. Don't hash it on the client side. Have a look at http://www.owasp.org/index.php/Hashing_Java. – Don Branson Sep 01 '09 at 12:33
6

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.

Trevor Harrison
  • 1,744
  • 1
  • 14
  • 20
  • Very interesting idea, and never thought of that before. Doesn't really fit in the current solution, but I will keep it in mind for future reference, thanks :-) – FrankS Aug 07 '09 at 07:59
  • 1
    Interesting idea so I spent some time thinking about it, but it is vulnerable to a man-in-the-middle attack. On an authentication request, the server sends some number M. The attacker sends (M-1) to the client, and receives hash(M-1) back. The attacker tries to authenticate again, receives challenge (M-1) from the server and responds with hash(M-1). The attacker is now authenticated. – rix0rrr Jan 06 '10 at 11:14
  • yes, that does sound like an issue. My first thought would be to require the server to not reuse M after issuing it during a challenge to the client. However, the larger issue remains that Mallory could tell the client M-100, collect the hash(M-100) from the client, and then login up to 100 times with the intercepted hash. I'll have to go see if the project that I first encountered this in found the same issues and dealt with it or abandoned zero knowledge auth. – Trevor Harrison Jan 06 '10 at 16:57
  • I think you're always going to be vulnerable to a man in the middle attack. Keyloggers too. Also drunken confessions of passwords. We can only raise the bar so far with reasonable coding efforts. – Kieveli Jan 21 '11 at 18:53
2

You can use gwt-crypto to generate SHA-1 hashes on the client side using:

String getSHA1for(String text) {
  SHA1Digest sd = new SHA1Digest();
  byte[] bs = text.getBytes();
  sd.update(bs, 0, bs.length);
  byte[] result = new byte[20];
  sd.doFinal(result, 0);
  return byteArrayToHexString(result);
}

String byteArrayToHexString(final byte[] b) {
  final StringBuffer sb = new StringBuffer(b.length * 2);
  for (int i = 0, len = b.length; i < len; i++) {
    int v = b[i] & 0xff;
    if (v < 16) sb.append('0');
    sb.append(Integer.toHexString(v));
  }
  return sb.toString();
}
Rok Strniša
  • 6,781
  • 6
  • 41
  • 53
0

You should never use an md5 or other hash functions for password encryption. See http://codahale.com/how-to-safely-store-a-password/

0

You want gwt-crypto. It includes lots of standard crypto stuff.

Trade-Ideas Philip
  • 1,067
  • 12
  • 21
  • That question is nearly eleven years old ;-) – FrankS Feb 03 '20 at 10:20
  • And I'm running into the exact same problem now. – Trade-Ideas Philip Feb 03 '20 at 16:06
  • Hopefully not trying to use md5 hash password anymore - one of the things I learned over time ;-) – FrankS Feb 04 '20 at 10:40
  • Not for passwords. I want a unique and fixed size signature for files. Not worried about an opponent working against me. I was originally porting some code that used SHA1, but but almost any hash would work. If (client side) GWT supports a newer, better, more secure hash, I'm sure I could make that work for me, too. – Trade-Ideas Philip Feb 06 '20 at 18:04