Dropbox Password security

Question

Dropbox have recently published How Dropbox securely stores your passwords

Is this really more secure than using bcrypt with a complexity of 11 or 12 ?

The password "chain" is secure as its weakest part, so is there any point adding the extra 2 parts in ?

I understand that the Global "pepper" means that a DB dump protects the hashes until that pepper is found, and then each hash is still salted per user, but how much would that slow down people reversing the passwords in the event of a DB leak over simply bcrypting them ?

Answer 1

Is this really more secure than using bcrypt with a complexity of 11 or 12 ?

It depends. Obviously if you consider everything on their servers compromised this isn't more secure than using a higher workload for the password hashing scheme (PHS). If you assume they can guard their pepper better than their password database then the passwords are irrecoverable from the dump.

The password "chain" is secure as its weakest part, so is there any
point adding the extra 2 parts in ?

A chain isn't really the correct analogy here. Assume an attacker can brute-force infinitely many bcrypt hashes but can't get the pepper. There's no way such an attacker could recover the passwords because he can't obtain the hashes required to brute-force them.

A better analogy would be an onion. You can't get to the core (the password) without going through all the layers (pepper, bcrypt, SHA-512).

I understand that the Global "pepper" means that a DB dump protects the hashes until that pepper is found, and then each hash is still salted per user, but how much would that slow down people reversing the passwords in the event of a DB leak over simply bcrypting them ?

The pepper is a 256-bit AES key. If an attacker doesn't get hands on this one there's no way they can recover the hashes and thus potentially the passwords. However as soon as you have exfiltrated the key, the additional AES encryption has just about 0 influence on the run-time required for brute-forcing a key. So you win in case you can protect the key and you lose nothing if you can't do that.

Answer 2

I understand that the Global "pepper" means that a DB dump protects the hashes until that pepper is found, and then each hash is still salted per user, but how much would that slow down people reversing the passwords in the event of a DB leak over simply bcrypting them ?

If you use AES with a random 128-bit key (the smallest key size), an attacker who obtains the encrypted hashes but not the key is effectively dead on their tracks. Carrying a brute force attack against AES is impossible in practice.

Is this really more secure than using bcrypt with a complexity of 11 or 12 ? The password "chain" is secure as its weakest part, so is there any point adding the extra 2 parts in ?

Instead of asking "is it more secure" in general terms as you do, we need to actually be specific and ask:

1. Are there any scenarios that it protects against that just bcrypt doesn't?
2. Are those scenarios likely enough risks that it's worth the additional complexity?

The use of an additional encryption step, in particular, protects against scenarios where the attacker manages to acquire the encrypted scrambled passwords but not the encryption key. If the attacker acquires both, then it doesn't do anything.

So it only provides additional security in scenarios where the defender can successfully arrange for that condition to be met. There are some plausible scenarios that meet that description:

• An attacker acquires the encrypted password hashes by executing a SQL injection or similar attack against a front-end web application, but the encryption key is not stored in the RDBMs where the entries are.
• The attacker gains access to a host that has all of the password entries, but no such host ever contains the encryption key.

The latter scenario can be arranged by having a Hardware Security Module or a special, hardened server (e.g., the Transit backend in Hashicorp's Vault) be the sole owner of the encryption keys, so that the other servers that possess the password database can only ever encrypt or decrypt password entries by sending the ciphertexts over to that specialized key owner to do it for them. But that requires extra cost and effort to acquire, develop, harden and/or configure; and it becomes an extra point of failure that is capable of bringing the whole system down.

So is it worth the extra effort and complexity? That's a judgment call.

Answer 3

The existing answers cover the usefulness of the encryption step in different scenarios, but nobody mentioned the hashing step yet.

Blowfish (on which bcrypt is based) mandates a maximum key length of 448 bits to make sure that every bit of the expanded key depends on every bit of the user key (password). While most bcrypt implementations happily accept longer keys, only the first 576 bits can affect the output at all.

In some scenarios, this can be rather important. Imagine using a 1024-bit/128-byte password, which has only 1 bit of entropy per byte; the password itself has 128 bits of entropy. However, using bcrypt with this password as key achieves somewhere between 56 and 72 bits of effective strength. That's obviously not desirable.

Using SHA-512 to hash the password and obtain a key for bcrypt means that every bit of the (non-expanded) key already depends on all bits of the password, so which parts of the expanded key depend on which parts of the key is no longer important. This means that the password can be arbitrarily long without decreasing security.