Is it better to hash n*x times in sha1 or n times in sha512 on the client side?

Question

I already know I"m going to hash the user's password n times in either sha512 or n*x in sha1 before it is sent to the server. Once at the server, I'm going to use bcrypt set to use ~1/100th of a second. Before I move on, onto my reasoning behind using sha512 instead of sha1, I'd like to state a few things. First, I know that client-side security is a joke. Second, I know that a Man-in-the-middle attack could strip the page's javascript of the hash function. Finally, I realize that this will mean that people will not be able to login without javascript being enabled.

I am currently using sha512 set to use ~1s in ie8 [2], it is setup as such.

1. Take the user's password and username.
2. Add a static-nonce(to lengthen it really and nothing else).
3. Hash it via the hashing function, in this case sha512.
4. Take that hash, hash it via sha512 with the current loop number packed into a single byte.
5. repeat step 4 n times.
6. Once it is done, take that value, and put it into the password field.
7. finally allow the system to POST to the server.

Now then, what is the advantage of doing n*x hashes of sha1 vs the n times of sha512. The entire point behind using this system is that, in the event of a database leak the attacker will have to increase the amount of time spent trying to find the password by z time. Also, by hashing it before it even gets to the server(along with using TLS), it makes it, so that, in the event of some weird bug, the password is never seen as plain text.

I believe that sha512 is a better choice since there is already broken sha1 and thus it's security is not worthwhile, but on the other side. The fastest javascript library I've found for sha512[1][] is ~50 times slower than native code, but the fastest sha1 library that I've found is only ~17 times slower than native code.

Thus it is a question of is the broken sha1 going to cause a greater loss in overall security and thus slowdown of an attacker than doing less iterations of sha512 which as of right now none of the sha2 family is remotely broken. Has anyone else dealt with this issue before?

[1]: that via fuzzing results in the same hash as the c implementation/php one results in the same hash for ~300 inputs.

[2]: One year after ie10 is out, I'd like to drop support for ie8 so that I can move up the number of hashes to something more reasonable.

Answer 1

This sounds a bit stretched, maybe counter-productive, sub-optimal and it doesn't really offer much added security. The "password" is actually seen in plaintext, because the password is the string you finally send in the place of the real password. What exactly are you trying to achieve?

In any way, if you are really trying to have the 'real' password 'not being seen in clear text' (and don't trust ssl) you should be looking at implementing a challenge-response protocol. This is usually the way one goes about if he does not want the password to be transported in the clear (or something resembling the password as in your case).

Now if you really want to go on with your plan, and still do that client-side trickery you describe, SHA-1 is perfectly fine for that. Even MD5 is fine and considerably faster. The 'talk on the street' about those functions not being secure is about collisions - which is something you probably don't care in your implementation. Also you can have a look at http://www.jcryption.org/ , it's a jquery library that does asymmetric encryption of html forms.

But, again, I strongly advise against this whole implementation.

Answer 2

The extra protection added by the client-side hash is extremely marginal. From the point of view of the server, the hash result is the password, because the server grants access to whoever is able to show that hash value, without requiring the actual password. In particular, if a "weird bug" results in making the hash value apparent to the attacker, then you lost: the attacker can simply connect to the server by showing it the hash value, without running your Javascript (average users may have trouble circumventing a bit of Javascript, but it would not be safe to assume that the attacker is not a bit more capable).

What protection remains is that if the attacker sees only the hash, he has not (yet) guessed the "real password" and will not (immediately) be able to try that password on other servers where the same user also has an account. This changes nothing to the security of your server but it could be viewed as a "community service".

As for the extra attack cost induced by the multiple hashing: although the idea is sound, using Javascript is not. Javascript is much slower than C or assembly. It takes one second with IE8 in Javascript, but nothing forces the attacker to run his attack in Javascript. He may use C, assembly, possibly a GPU. If you want to make dictionary attacks hard, you need to make the hashing slow for the attacker. By doing it on the client in Javascript, you prevent yourself from making as many iterations as would be needed to achieve proper security. One way to see it is the following: we want each "guess" to be slow for the attacker. Unfortunately, we cannot make it slow for the attacker unless we make it slow for the "honest system", too. So the performance of the honest systems (client and/or server) limits the amount of slowness we can inject. By doing it on the client in a suboptimal language, we artificially make the slowness burden much heavier for the honest systems and not for the attacker.

In practice, the attack cost will be that of bcrypt; the hashing will be negligible in comparison. This is especially true for SHA-512, which uses 64-bit integer operations, which are awfully slow to implement in Javascript, due to the lack of 64-bit integer types. So the precise answer to your question is: using SHA-1 (or SHA-256) would be "better" than SHA-512 if the goal is to induce slowness into dictionary attacks; but even so, the induced slowness will be negligible with regards to what server-side bcrypt does, so the question is kind of meaningless. On the other hand, 1s extra delay will infuriate normal users, who are known to have no patience.