Client Side MD5 Hash with Time Salt

Question

I want to salt a hashed username and password (submitted via http POST) in JS on the client-side with a higher-order time value (< 1 minute resolution) to avoid sending the username and password hash as a constant value that could be used for a log-in attempt via POST fabrication by an unauthorized user (i.e. a sniffer).

This will impose a short expiry on the usefulness of the passed hash.

If they inspect the JS and see that it uses this time salt, how much easier will it make the job of breaking the MD5 if they know what the salt is?

Stephen

Answer 1

Their job will become infeasible, since you can't use a rainbow table at all if the hash is salted correctly, and you can't break MD5 in less than a minute, by which time the hash is invalidated anyway.

Answer 2

The salt doesn't need to be secret. In that sense, your solution is okay.

MD5 is broken in some applications; this one might be alright, but why not use a hash from the SHA-2 family? For that matter, why not use SSL to provide a confidential channel, and better security?

Answer 3

The time-based salt will not make MD5 any easier to break. You're still relying on 1) the user having a good password to defeat brute force calculations, and 2) MD5 being a decent hash. That's the basic answer to your question. However, this may not be a good idea anyway. Some comments--

Unless you can ensure the client or server's time are synchronized (or you use Javascript to fake a synchronization), the client would have to send the time it used as salt. The server would have to decide if the time used was close enough to the server's time.

Even if synchronized, you'd probably have to accept hashes plus or minus a minute or so because of latency on the Internet. Another problem is that if I'm sniffing I could immediately reuse this hash as long as I'm still within this time window.

Because of the problems above a better idea is to use a one-time server-assigned salt with the hash since it sounds like you don't want to use SSL. In other words, everytime a login form is sent to the client, the server would generate a random, unique salt string, sending it to the client and keep track that this is an acceptable salt. Then the client uses that as salt with the password. After this is submitted once, the server discards this as an acceptable salt string. No two hashes should ever be the same. The downside of this is you have to keep track of these acceptable salt strings.