Inside Dropbox’s Password Storage Architecture
Storing passwords as plain text has been a recognized vulnerability for decades—since 1976, the industry has leaned on one-way hashing as the standard defense. But hashes alone aren’t a silver bullet. Any hash that gets into an attacker’s hands can be brute-forced offline by hashing candidate passwords and comparing results. The problem is compounded by the fact that general-purpose hash functions like SHA are designed for speed: a commodity CPU can churn out millions of SHA256 hashes per second, and GPU clusters push that into the billions.
Dropbox has iterated on its password storage scheme multiple times over the years. The current design layers three distinct cryptographic protections: a pre-hash with SHA512, a bcrypt hash with a per-user salt, and an AES256 encryption step using a global key. For clarity, binary encoding is omitted from the diagram and descriptions below.
Why SHA512 Comes First
Bcrypt serves as the core hashing algorithm, but it has two known quirks that the SHA512 pre-hash addresses. Some bcrypt implementations truncate input at 72 bytes, reducing password entropy for longer passphrases. Other implementations skip truncation entirely, making them susceptible to denial-of-service attacks via arbitrarily long inputs. Applying SHA512 first converts even very long passwords into a fixed 512-bit value, eliminating both issues before bcrypt processing.
After the SHA512 pass, the result is fed into bcrypt with a cost factor of 10 and a unique, per-user salt. Bcrypt is intentionally slow and resistant to acceleration via GPUs or custom hardware—a deliberate contrast to fast hashing functions. On Dropbox’s servers, the full sequence (SHA512, bcrypt, and the subsequent encryption step) takes roughly 100 milliseconds.
The Role of the Global Pepper
The final step encrypts the bcrypt output with AES256 using a secret key that’s shared across all password hashes—what Dropbox calls a “global pepper.” This key is stored separately from the database, acting as a defense-in-depth measure. If the password storage alone is compromised, the encrypted hashes are useless without the pepper.
Choosing encryption over hashing for the pepper is a deliberate design decision. If the pepper were used in a hash, rotating it would be impractical. Encryption, however, allows for key rotation while maintaining the same security posture. The encryption input is randomized, and each operation includes a random initialization vector (IV) for additional protection.
Algorithm Choices and Future Plans
Dropbox considered scrypt before settling on bcrypt, but opted for the algorithm it had more operational experience with. Most security experts consider the two to provide comparable protection. Argon2, the winner of the Password Hashing Competition, wasn’t a viable option at the time—the contest had yet to conclude. While argon2 is well-regarded, Dropbox notes that bcrypt has been in use since 1999 without any significant vulnerabilities surfacing.
Looking ahead, Dropbox is exploring storing the global pepper in a hardware security module (HSM). The engineering effort is substantial at their scale, but it would meaningfully reduce the risk of pepper compromise. The company also plans to increase the bcrypt cost factor in its next iteration of the scheme.
Password hashing is only one component of Dropbox’s broader security posture. The company also deploys rate-limiting on password attempts, captchas, and various abuse mitigations to counter online brute-force attacks. These layered defenses, like the cryptographic protections in the storage scheme, are built to evolve as attacker capabilities grow.
