As we all know, storing plaintext passwords is a very bad thing. If a database stores a plaintext password, if the data is leaked, then the user account is in danger. Because of this, back in 1976, industry came up with a set of standards for storing passwords securely using a one-way hashing mechanism (starting with Unix Crypt). Unfortunately, while this approach prevents you from reading the password directly, all the hashing mechanism does is prevent an attacker from brute-force cracking it in an offline environment, where the attacker simply traverses a list of possible passwords containing the correct password, hashes each possible password and then compares it to the obtained password (the one stored using the hashing mechanism). In this environment, secure hash functions such as SHA have a fatal flaw when used for password hashing, and that is that they are too fast. A modern commercial CPU can generate millions of SHA256 hashes a second. Some special GPU clusters can even compute at billions of times per second.

Over the years, Dropbox has made several upgrades to its password hashing methods in response to attacks. Their password storage scheme relies on three different layers of password protection, as shown in the following diagram.

Dropbox uses Bcrypt as its core hashing algorithm, with each user having an individual salt as well as an encrypted key (this key can also be a global one, often also called pepper), and the salt and key are stored separately. differs from the underlying Bcrypt algorithm in a number of important ways.

  • First, the user’s plaintext password is converted into a hash by the SHA512 algorithm. This step focuses on two prominent problems with Bcrypt. Some implementations of Bcrypt intercept user input to a size of 72 bytes to reduce password entropy, while others do not intercept user input leading to their vulnerability to DoS attacks, as they allow arbitrary length password input. By using SHA, some passwords that are indeed very long can be quickly converted to a fixed length of 512 bits, solving both of these problems, i.e., avoiding reducing password entropy and preventing DoS attacks.
  • Then, the value after SHA512 hashing is hashed again using the bcrypt algorithm, using a working factor of 10, with a separate salt for each user. unlike other hashing algorithms such as SHA, the Bcrypt algorithm is slow and it is difficult to accelerate by hardware and GPU. Setting the work factor to 10, it takes about 100 ms to execute bcrypt once on the server.
  • Finally, the result after hashing with Bcrypt is encrypted again using AES256 algorithm, using a key that is unified for all users, called pepper. pepper is a defense based on in depth considerations, and pepper is stored in a way that is difficult for an attacker to find (e.g. don’t put it in a table in the database). Thus, a hashed password encrypted by AES256 is useless to an attacker if only the password has been dragged from the database.

Why not use scrypt or argon2?

Dropbox had considered using Scrypt, but we have more experience with Dropbox. There have been discussions about which of these algorithms is better, and most experts in the security field agree that scrypt and bcrypt are comparable in terms of security.

Dropbox is considering using the argon2 algorithm in its next upgrade: since argon2 has not won the Password Hashing Competition when the current scheme was adopted. In addition, Bcrypt has not been found to have any significant attacks in existence since 1999.

Why use a global key (pepper) instead of a hash function

As mentioned earlier, using a global key is a defense measure after we weigh in depth and, moreover, pepper is stored separately. However, storing the pepper separately also means considering the possibility of pepper leakage. If only the peper is used to hash the password, then if the peper is leaked, there is no way to get the previously bcrypt-hashed password value from the inverse solution of the hashed result. As an alternative, Dropbox uses the AES256 encryption algorithm, which provides about the same level of security while allowing the original value to be decrypted back. Although the input to the AES256 encryption function is random, Dropbox adds an additional random initialization vector (IV) to enhance security. Next, Dropbox considers storing the pepper to a hardware security module (HSM), which is a rather complicated task but it can greatly reduce the risk of pepper leakage. Also, it is planned to enhance the strength of Bcrypt in the next upgrade.

Outlook

Dropbox believes that using SHA512, coupled with bcrypt and AES256 is one of the most secure and popular methods of password protection available. At the same time, as the saying goes, the Tao is higher than the devil. The password hashing process is just one of many initiatives to harden Dropbox. Dropbox also deploys additional protection measures - such as speed limits on the number of password attempts by brute force attackers, authentication codes, and a number of other methods.