Fast algorithms versus expensive algorithms

Some password encoding algorithms, like the SHA-1 and SHA-2 schemes, can be cheap to compute, while others like PBKDF2, Argon2, bcrypt, and scrypt can be expensive to compute.

The more expensive a password storage scheme is, the more effort that an attacker must expend when trying to crack passwords encoded with that scheme.

However, the higher resistance to password cracking attacks does not come for free. If it is more expensive for attackers to generate encoded password representations, it is also more expensive for the server to generate them in response to legitimate requests. Because the server has to generate these encoded representations whenever it is processing a bind request to authenticate a user, or when processing an add, modify, or password modify request used to set a new password, using these storage schemes can significantly affect server performance.

You can tune each of these expensive schemes in some way to adjust the performance impact that it will have. If you plan to use one of them, determine what level of authentication and password change performance (in terms of number of operations per second) that you will need, and the minimum cost factor that you are willing to accept for the password storage scheme. Then, benchmark the system to make sure that your environment can meet those demands or to determine how much additional hardware you might require to do so.

This performance impact can be even more significant when importing data that contains clear-text passwords. Ideally, if you’re migrating data from another system, that system also has been storing passwords in a relatively secure manner, and you will therefore not have access to their clear-text representations. However, if you do have access to the clear-text passwords, or if you’re importing sample data for testing purposes, then you can find the import proceeding at a crawl because of the expensive password processing. If you’re just using sample data for testing purposes, then pre-encode the passwords so that the import can proceed as quickly as possible. If you’re using real-world data, then you might want to use a faster password storage scheme (like one of the SHA-2 schemes) for the import, and then configure that scheme as deprecated (as described in the next section) so that the passwords are gradually migrated to the preferred encoding.

Alternatively, you might decide that the potential benefit you get from using an expensive password storage scheme as increased resistance to password cracking attacks is not worth the added processing cost that it incurs for legitimate processing. This can be a completely valid conclusion to reach in some environments, especially if you take steps to help ensure that users are required to choose strong passwords and continue to monitor the strength of those passwords over time. Using a more expensive encoding might require an attacker to expend thousands of times more resources to crack passwords than if they had used a fast encoding, but this additional cost is largely irrelevant if users have weak passwords that can be quickly guessed by attackers.

On the other hand, using a very fast algorithm might not incur that much risk for sufficiently strong passwords. For example, if a ten-character password is comprised of a random combination of uppercase and lowercase letters, numeric digits, and ASCII symbols, a set of 95 characters, then there are 9510 = 59,873,693,923,837,890,625 possible combinations of those characters. Even if an attacker can make one hundred billion guesses per second, it would still take nearly nineteen years for them to try every option. Realistically, users probably aren’t going to have ten-character completely random passwords, but you can still do things like encourage password managers, encourage passphrases, discourage password reuse, and prohibit known-weak passwords. You can also use two-factor authentication so that gaining access to a user’s account requires more than just cracking their password.

Ideally, you might find that the constraints of your budget and performance requirements do not prohibit the use of expensive encoding and that you can enjoy the best of both worlds: strong passwords encoded in a secure manner and protected by an additional authentication factor