Can I initially hash passwords with SHA instead of hashing them with bcrypt to decouple requests from slow crypto functions?

Question

I'm using bcrypt for some web service requests that hash multiple passwords. The problem is that these web service requests can take minutes to complete due to bcrypt. Not very user friendly.

My question is the following: Can I hash these passwords with SHA and persist them to the database, then have a decoupled queued worker come along and properly hash these passwords with bcrypt?

That way eventually these passwords will be hashed with bcrypt but the user doesn't have a painful experience in the process.

Currently, I'm using the .NET library BCrypt.Net.

Answer 1

Bcrypt is run many times to intentionally slow it down. Perhaps you need to adjust the number of rounds of bcrypt you are running? This answer has some information on it.

While what you propose may work, I can't say that implementing a variant of standard password handling is a good idea. While I have specific concerns, such as the SHA hash staying in the DB too long and the security of the encrypted queue, I generally don't see the need to vary from the standard. If it's taking too long, reduce the number of rounds used for execution. If it's inexplicably slow, figure out why. Don't just decide that you can do better than decades of security best practices. It's not likely to turn out well.

Perhaps you want to post another question (likely on StackOverflow) asking about help with finding the performance problem. That seems a much better idea.

Sorry that I can't agree with your proposal...

Answer 2

The depicted design would entirely undermine the security of bcrypt.

Your design could be simplified by simply eliminating the bcrypt part of the flow and rely only on the SHA hash. That simplification would not change the security of the design significantly, it would still be as insecure as simply applying a SHA hash.

Using a SHA hash with a salt would however be sufficient to protect good passwords. Only weak passwords benefit from using stronger password hashing.

You haven't fully described the problem you are trying to solve, so we cannot provide any solid advice on how to proceed. However two interpretations of your question comes to my mind, and each of them can be answered.

Are you trying to speed up bulk creation of users?

If you are trying to speed up bulk creation of new users and being slowed down by the password hashing algorithm, then I can propose two ways to improve that quite specific use case.

1. Use strong passwords and a mediocre password hash. If the passwords you generate for the users initially are strong, then you don't need the full security of bcrypt. An initial password with 128 bits of entropy passed through a password hash which does a single salted iteration of SHA-2 is secure enough. Once the user changes the initial password to something else, you can switch to a different password hashing algorithm. This can even be achieved using standard formats for password hashes such as the once used by the crypt function, in which the format starts with a specification of the used hash.
2. Use a password hash which support fast initial hashing, but is slower at verifying passwords. This can be achieved by applying a SHA-2 hash to concatenation of salt, password, and a short random bitstring. The random bitstring is not stored anyway, so it has to be brute-forced in order to verify a password. This brute-forcing replaces the usual iteration used in password hashes.

Are you trying to reduce CPU load on your server?

There are password hashing algorithms which can securely offload the CPU intensive part of the computation to the client without compromising security. This can even improve security by never allowing the server to see the actual password. The drawback of this approach is, that it requires client side support. A client can no longer just submit user name and password in order to log in.

Which hash to use?

Don't use anything weaker than SHA-2 in any new systems. Any legacy systems using SHA-1 for security related usage should be phased out or upgraded. Any legacy systems using MD5 for security related purposes should have been phased out a decade ago.

The SHA-2 family has six different variants. Don't go with a shorter output because you think it will be faster. In reality there are only two variants of the compression function. One has 256 bit internal state and is optimized for 32 bit CPUs. The other has 512 bit internal state and is optimized for 64 bit CPUs. If your CPU is 64 bits, then SHA-512 is both the fastest and likely to be the most secure.

For password hashing you should never hash without salt. I think that's the only completely objective advice that can be given on how to hash passwords. There is plenty of other advice to be given, but the rest is going to be depending on the threat scenario.

Answer 3

The risk here is that if an attacker manages to extract the SHA'd passwords from the database, then they can run a password guessing attack at a relatively fast speed. You should at least salt these password, but then you're increasing complexity which is generally at odds with security. A good secure system should be as simple as possible to make it so.

I don't think that bcrypt(sha-2(password)) reduces security in any meaningful way. Yes you could be reducing the search space from 576 bits to 256 (with SHA-256), however you only need 128 bits of entropy in order to have an "unbreakable" password using today's technology (and that of the foreseeable future). So this is a moot point.

Don't forget that to validate the passwords for log in you're going to have to SHA-2 it (fast) and then bcrypt it (slow) each time for comparison. Therefore your log in system will be slow, although here you are doing bcrypt rather than n * bcrypt, which I think where your problem lies with the batch process.

I think the solution to this is a system architecture issue rather than a security issue. Tune your bcrypt cost so that it takes about 1 second for a valid user to login. Then redesign your batch process so it is asynchronous and it bcrypts the passwords in the background. Have a notification event to return whether this process was successful or not, and if not which user IDs had failures. This will improve your user experience, making your system less secure will not. Memory is much more secure than the DB.