Why Can't You Hash a Password Multiple Times

[The_Decryptor Veteran]

Just another tip, hiding your password creation and verification routines isn't a bad idea.

 

I like to use used an encrypted stored procedure in the database server for logins(In my case MSSQL). You feed it the user name and password, it returns true or false. You can, of course, get more complex, but the design rule was that all logins are validated through the one procedure. You can call it from another proc, from the web server or from any other front end, but that SP was the only way to validate a login.

I can't imagine that being very secure, if somebody attacks your database (Which is pretty much going to be the attack vector) they've then got your custom method for authenticating users.

If the method was properly secure, you could tell the attacker exactly how you're doing it and they still wouldn't be able to break it (Just because the attacker knows you're using bcrypt, doesn't make bcrypt any less secure, etc.)

[sir West]

what about: sha512(sha256(sha256(sha256(<password>) + <username>) + sha256(<password>) + <password-set-date&time>)) ?

Adding user-specific and different types salting would surely make it harder, no?

[The_Decryptor Veteran]

Not really, you're not adding any actual extra work for the attacker, they still just have to come up with one password to test.

Edit: The hard part isn't "How many times do I run SHA", it's "What do I feed the hash function?", adding 3 hash iterations isn't any harder than just 1 hash iteration, it's just ever so slightly slower.

[Crimson Rain]

If you are hashing multiple times, it should be with different salts each time.

[Joe User]

I can't imagine that being very secure, if somebody attacks your database (Which is pretty much going to be the attack vector) they've then got your custom method for authenticating users.

If the method was properly secure, you could tell the attacker exactly how you're doing it and they still wouldn't be able to break it (Just because the attacker knows you're using bcrypt, doesn't make bcrypt any less secure, etc.)

 

First off, the production database server doesn't see the Internet. It doesn't even have a default gateway. It's locked down to VPN and local server access only.

Second, The stored procedure is compiled with encryption, it's not easily editable, and they would have to break the database security system to figure out how to decrypt it.

Third, I'm using bcrypt, but it's not on the forward facing server, it's out of sight in a stored procedure with much tighter security.

 

So, after breaking the VPN, breaking domain security, and breaking SQL Server security, they've figured out I'm using bcrypt. 

 

Now, if we coded security at the web tier, someone could break into the public facing server and figure out what we're using in far less time. Why make it easy on them?

[n_K]

If they get access to your web server chances are they'll get access to your database server.

If you think that just because one server itself doesn't have the internet makes it untouchable, you've got a lot to learn. A very early example of netcat was exactly that, hack a web front end, put a netcat remote listener on and then you do what you want to the database server as if it was on the internet.

[n_K]

Just FYI PHP 5.5 has a new password hashing API;

http://www.php.net/manual/en/function.password-hash.php