Hashed passwords storage: iterations vs entropy

Question

Context: A website is hosted on multiple dedicated servers. There are frontend webservers, backend DB servers and other servers between them. The DB holds user's accounts passwords. All connections are secure and the registration/login pages can not be bruteforced (out of the question's range).

Threat model: A hacker manages to get a copy of the DB and wants to crack the passwords. The hacker has very powerful hardware power at his disposal (CPU/GPU/RAM/ASIC) and only needs to crack one single password to be considered as the winner (protecting a maximum of users is not enough, all users must be protected).

Question: Which of the cases below would be considered the most secure against the hacker efforts?

1. Traditional iterations based hashing with salt (scrypt/bcrypt)
2. Handmade multi-peppered hashing with very long secrets held at each "stage" (webserver/middle/DB).
   • Webserver operation: Hash1 = SHA512 (password + secret1)
   • Middle operation: Hash2 = SHA512 (hash1 + secret2)
   • DB operation: Hash3 = SHA512 (hash2 + secret3)
   • DB storage: Hash3 with salt

My opinion is that case 2 is by far the more resistant because iterations will not protect poor (low entropy) passwords such as "123456" for more than a few hours/days at best. As long as the secrets are very long and at least one of them remain unknown then I think the increased entropy will secure everyone for decades.

I do not see such scheme rolled out on production very often though, in general the consensus is "iterations+salt or get shamed", so maybe I am missing something.

Of course the implementation would need to be secure (handmade vs more standart scrypt) and the secrets must remain unknown. Moreover if a secret is revealed and must be changed, the update process would be a pain. On the other hand, login process would be more hardware friendly (no iterations).

Edit (based on Matthews comment): My question is not about the benefit of a pepper in an iterations based method. It is the security difference between iterations based vs secrets based methods.

Edit 2: I made more searches and managed to find a similar question after all, my bad (maybe the results improved based on my activity on current question though). It has a nice answer (by Thomas Pornin) similar to here.

Answer 1

A message authentication code with a secret key that's unavailable to the attacker will indeed resist many attacks that resource-intensive password hashing won't. There's no question there. You don't even need the excessively complex three-tier key architecture; just one 128-bit secret key would be plenty.

(Side note: I highlight "message authentication code" because that's the cryptographic construct that's appropriate for your proposal. Your "SHA512(password + secret)" betrays that you don't seem to know what construct is appropriate for what you've proposed; HMAC-SHA512(key, password) would be the better choice.)

But here's the big, difficult topic that your question completely sidesteps: how do you protect those secret keys? You say this:

Of course the implementation would need to be secure (handmade vs more standard scrypt) and the secrets must remain unknown.

...but those two are precisely where laypersons who attempt to implement your proposal will fail, again and again! You already have questionable crypto in your proposal (handrolled keyed hash instead of HMAC, three layers of MAC computation when just one would do), and you say nothing about how you'll make sure your secret keys don't get disclosed—which is the point on which the security of the scheme hinges!

Moreover if a secret is revealed and must be changed, the update process would be a pain.

This can be solved with a hash-then-encrypt approach, like Dropbox has adopted (with bcrypt, however). The equivalent in your no-iterations approach would be something like encrypt(key, hash(password)), or (scarcely) better encrypt(key, hmac(salt, password)), which would allow you to later rekey the encrypted hashes.

I do not see such scheme rolled out on production very often though, in general the consensus is "iterations+salt or get shamed", so maybe I am missing something.

Insecure storage of long-term secret keys is really, really common, and nearly everybody who suggests using a pepper haven't really thought the key management problem through. This is what makes key-less schemes like resource-intensive password hashing so valuable and such a strong recommendation; if we can avoid or reduce the reliance on secret keys, that is generally a plus. Basically, key management is hard, so the fewer long-term cryptographic keys we need to store and defend the better, and the more we can mitigate the consequences of failure the better as well.

Secret keys should therefore only be considered for password hashing after:

1. You've adopted resource-intensive password hashing, which serves at least as a fallback line of defense if the keys are disclosed.
2. You have a well-thought out and well-engineered system for protecting and managing your systems' secret keys—ideally one where the keys are stored in just one secure key management system whose only purpose is to store long-term secret keys and never to leak them to any external system. A KMS shouldn't disclose the keys not even to its clients, who instead must resort to asking the KMS to perform cryptographic operations on their behalf. Some examples:
   • A hardware security module
   • Secret management tools like Amazon KMS or HashiCorp Vault's Transit backend.

Answer 2

Assume that your system is fully compromised. An attacker has all of your peppers, all required salts, and knowledge of how you're combining them. This is the equivalent situation for an attacker who gets a table of bcrypted passwords.

At this point, for your scheme, breaking passwords is fast. SHA-512 can be calculated at millions of hashes per second. For the current general advice, bcrypt, breaking passwords is still slow. By tuning it, standard hardware could be restricted to 100s per second, with specialist hardware still only giving 10,000s per second.

Now, if you can be absolutely sure that no one can steal your pepper data, that's fine. However, if you do lose them, your passwords are almost instantly vulnerable - fast hashing lets an attacker try common passwords easily. On the other hand, the iterations don't have that issue.

The iterations are also easy to implement - one, usually built in, function. That's very little effort for developers, which makes it easy to implement correctly. On the other hand, your scheme requires hashing code in multiple places, on different servers. You need to make sure that the intermediate hashes aren't exposed at any point. You need to ensure that the code at each layer is correct. You might need to run extra software on some systems (does the DBMS natively support the hashing method?). There are lots of moving parts. It's a lot easier to make a mistake somewhere.

In short, iterations retain security in the event of complete compromise, and are easier to develop. In an ideal world, multilayer pepper would help against the failure mode where the database is compromised, and no other systems are. It would be suitable for adding to a system with high security requirements, in addition to using slow (high iteration) hashing, but not instead, unless you have complete confidence that the peppers can never be compromised.