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
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 :-)
I think that applying SHA512 any more than once doesn't have any additional value.
Do you have the following authentication workflow:
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...
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... :)
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).