Menu
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.
889
Since the whole purpose of a salt is to prevent password attacks with precomputed tables (e.g. rainbow tables), storing the salt along with the hashed password is actually harmless.
The easiest way is to put the salt in front of the password and hash the combined text string. The salt is not an encryption key, so it can be stored in the password database along with the username – it serves merely to prevent two users with the same password getting the same hash.
Salting is important because it adds a whole new level of required computational power in order to expose the hash. By adding a salt, you effectively render any lookup table useless. Hashing a password is not 100% secure as hashing alone is not that difficult to break.
Salting is one such protection. A new salt is randomly generated for each password. Typically, the salt and the password (or its version after key stretching) are concatenated and fed to a cryptographic hash function, and the output hash value (but not the original password) is stored with the salt in a database.
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.
145
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.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
