Password stretching - a way to mitigate CPU flood

I'm now using password stretching for all user account passwords throughout all my websites. In the db I store an iteration count and randomly assigned salt along with the final hash. I'm using SHA512 as the hash algorithm. I'm using C# in .Net 3.5 and 4.0 (dual framework library) for this.

For accounts that only ever get randomly assigned passwords (things like web service API users etc) I keep the iteration count down to a range such that a password check takes no more than 1 second or so. Over the years, according to whether or not these websites stick(!), I will look at increasing these ranges in alignment with CPU power.

For accounts where the user might be choosing the password themselves, I have cranked up the iteration count so a login can take around 5 seconds while the iterations are carried out.

So I'm happy with the security of my passwords; but now I have another p开发者_开发知识库roblem - I can flood an 8 core cpu with 100% usage for 5 seconds if I get 8 different people to login at once!

My current solution to this is to have an iteration threshold: If a stretch operation exceeds this, I push it on to a queue that is handled by a single thread. I could extend this further so that it uses at most half the processors in the machine.

Is there anything better I can do? Have you implemented this pattern for password storage and logon - what did you do?

The idea of password stretching is to have the attacker do the heavy work:

When a client wants to log in, the server presents a challenge. The client performs the resource-intensive calculations and sends a response to the server. The server should be able to determine whether the response is valid or not with very few resources.

Because it's the client that's doing the heavy work and the client requires a new challenge for each attempt to log in, brute-forcing all possible password combinations becomes (hopefully) too expensive for an attacker.

Have a look at the Salted Challenge Response Authentication Mechanism (SCRAM).

Isn't the big benefit of password stretching, that the calculations are done on the client side and therefore they should not affect your server while still providing a good protection?
Frankly, if you implemented it on your server, you are doing it wrong and missed the point :-)

Are you sure that its not easier for a hacker to intercept the password in clean text then cracking the database information. I'd simplify the algoritm to create and check the passwords and would focus more on important security.

Like Jon said:

I think you have overdone it... :)

I think that applying SHA512 any more than once doesn't have any additional value.

Do you have the following authentication workflow:

1. User enters username and password on the web form and sends it to the server either plain-text or over SSL;
2. Server calculates the proper hash/salted hash/whatever to compare with the one stored in the database;
3. Server compares the hash computed with the one stored in the database.

If so, then the hashing doesn't have much sense because potential attacker won't be able to send the straight hash anyway. In this case not hashing makes your system more secure but rather delay before server responds to the request -- which can be accomplished with the much cheaper Thread.Sleep(1000) technique...