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.
- 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.
- 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.