I am currently learning about cybersecurity and trying to implement it in my next web application.
I have been reading some articles about hashing, specifically SHA2 and Blowfish.
In this article, it is recommended to add a hard-coded salt to passwords so an attacker retrieving the database will have it harder to brute-force a password. This makes sense since the hard-coded salt is not in the database and the attacker won't have access to it (as long as it runs on the server and not in the client).
However, if the salt is hard-coded, that means it is going to be the same for all users, so after the attacker breaks the first password from the database and determines the salt is "123", they can just apply that salt to all brute-force attempts by default.
The first solution for this problem that came to my mind was generating a salt before passing the string to BCrypt, and storing that randomly generated salt in a separate database. The attacker wouldn't have the extra salt if the main database is compromised, and breaking a password wouldn't let you know another user's salt.
However, even if doing this ensures the attacker will not have the extra salt, it might be redundant to add that extra salt before BCrypt, since the point of the salt is to avoid collisions, and BCrypt is already supposed to do that (read the answers here).
This could make sense if hashing the password string with SHA2 before passing it to BCrypt, since after breaking the Blowfish layer of the password from user1 (which is "1234") and the Blowfish layer of the password from user2 (which is also "1234"), you would still need to break the SHA2 layer for their passwords and, since an additional salt is applied, you wouldn't be able to tell they have the same password. Not having the additional salt could difficult the life of an attacker.
I am aware of the potential implementation flaws of hashing with SHA2 before BCrypt described in this question.
Thanks in advance.