We use the industry-grade and battle-tested bcrypt algorithm to securely hash and salt passwords. We also want this function to be adaptive so that we can compensate for future faster hardware by being able to make the function run slower and slower over time.Īt Auth0, the integrity and security of our data are one of our highest priorities. Instead of a fast function, we need a function that is slow at hashing passwords to bring attackers almost to a halt. Modern hardware in the form of CPUs and GPUs could compute millions, or even billions, of SHA-256 hashes per second against a stolen database. How fast a cryptographic function can calculate a hash has an immediate and significant bearing on how safe the password is.įaster calculations mean faster brute-force attacks, for example. However, one design problem with the SHA families is that they were designed to be computationally fast. There are plenty of cryptographic functions to choose from such as the SHA2 family and the SHA - 3 family.
The ideal authentication platform would integrate these two processes, hashing and salting, seamlessly. A better way to store passwords is to add a salt to the hashing process: adding additional random data to the input of a hashing function that makes each password hash unique. However, we also explored that hashing alone is not sufficient to mitigate more involved attacks such as rainbow tables.
Instead, we want to provide a one-way road to security by hashing passwords. In previous posts to this Authentication Saga, we learned that storing passwords in plaintext must never be an option.
0 kommentar(er)
