I read this article about password hashing using bcrypt as the recommended method. The advice is similar to what they're saying on hacker news about not using something like SHA2+salt. There are other answers on the infosec StackExchange about why we shouldn't use something like SHA-256. The generally accepted knowledge is:
SHA2 is fast, which is bad (bcrypt is purposefully slow so that we can get around Moore's law)
As you know, if we use bcrypt, we to hash something with a cryptographically random salt, we might get this string:
$2a$13$ZyprE5MRw2Q3WpNOGZWGbeG7ADUre1Q8QO.uUUtcbqloU0yvzavOm, and the salt is contained in that string.
My question is a bit multifaceted:
If an attacker gains access to the database with write access, they could just re-write someone's password in the table with their own hash and login to that user's account, right? Unless that's not their specific objective (for example, maybe they don't want anyone to know that they accessed the database). Or if they have read-only access, I guess that's a different story.
Aside from the fact that bcrypt is purposefully slow, is there any other advantage to storing the salt in the same hash as the password as opposed to having both
user.saltin one record if I didn't use bcrypt? Or in that case is it generally best practice to store hashes and salts in separate tables/databases (then presenting the disadvantage of multiple table/database lookups as mentioned in one of the comments)?
We also get the issue that bcrypt presents minor (yes, within the milliseconds range) performance issues (purposefully) when performing lookups, which is negligible in most cases, but it seems the only protection we really get from bcrypt is making it difficult to batch process an entire user table and covertly log into users' accounts (or sell their information, or whatever). Why not just use something like SHA2+salt then?