It’s universally acknowledged that it’s a bad idea to store plain-text passwords. If a database containing plain-text passwords is compromised, user accounts are in immediate danger. For this reason, as early as 1976, the industry standardized on storing passwords using secure, one-way hashing mechanisms (starting with Unix Crypt). Unfortunately, while this prevents the direct reading of passwords in case of a compromise, all hashing mechanisms necessarily allow attackers to brute force the hash offline, by going through lists of possible passwords, hashing them, and comparing the result. In this context, secure hashing functions like SHA have a critical flaw for password hashing: they are designed to be fast. A modern commodity CPU can generate millions of SHA256 hashes per second. Specialized GPU clusters allow for calculating hashes at a rate of billions per second.
Over the years, we’ve quietly upgraded our password hashing approach multiple times in an ongoing effort to stay ahead of the bad guys. In this post, we want to share more details of our current password storage mechanism and our reasoning behind it. Our password storage scheme relies on three different layers of cryptographic protections, as the figure below illustrates. For ease of elucidation, in the figure and below we omit any mention of binary encoding (base64).