问题
Is it okay and isn't useless? It could be saved in another table or even another database.
What do you think?
P.S. For higher security, I have the constant salt "peanuts" too. It's constant value saved in configuration file (not in database). So if hacker want to somehow hack password, he need access to file server and database as well.
回答1:
Yes, it's okay to store the per-user salt in the same table which stores the password hash (not the password itself) - even if the adversary gets access to the raw database data, he'd still need to try each user's salt+password separately; storing the salt in another table is not really adding any significant security (if you assume the adversary has access to the database, it doesn't make much sense to me to assume he only has access to one part of it).
If you're using salt+peanuts+password to create the password hash, then I'd say that your design is safer than 80% of the systems out there - which is to say, reasonably safe without going overboard with paranoia.
Note however, that if you're actually storing the password in recoverable form (encrypted or plaintext), you're throwing any security out of the window - the whole point of salts and hashing is that you are not storing the password in recoverable form. If you do store the password, that is the weakest link of your system, which is then completely insecure. To make things clear: the user table should only contain the salt and hash of salt+peanuts+password, never the password itself.
回答2:
You want to store 1) the per-user salt and 2) the result of hashing password+salt). You do not want to store the password itself.
来源：https://stackoverflow.com/questions/6372103/is-it-okay-to-save-users-salt-in-the-same-table-as-password-hash