Reputation:
Okay. Say for example that i set the salt for a password to "hello." Can't someone just look at the source code and discover the salt? If so, how would I hide it? Thanks.
Upvotes: 1
Views: 203
Reputation: 837886
Salts are are usually stored in plain text alongside the password hash. The main reason they are there is to make it more difficult to use precomputed rainbow tables and more difficult to perform a dictionary attack on all the passwords in the database.
You should also use a different randomly generated salt for each password, rather than a single salt for your entire application. This means that each password must be cracked separately.
Upvotes: 7
Reputation: 20765
1) Don't use the same salt for multiple accounts. If you can't show your source-code and trust that your passwords are still secure, you've done it wrong.
Upvotes: 1
Reputation: 60008
First of all: Security is HARD. Don't try and do it yourself, because you will screw it up. Use a well-established library to handle user authentication.
Secondly, you seem to misunderstand the purpose of a salt. The salt is just there to prevent easy reversing of password hashes - there should be a unique salt for each user, but it's fine to store the salt in the same place as the hashed password.
Upvotes: 5
Reputation: 32831
Hopefully, your "source code" is running on a web server, and not on the client side (javascript) where anybody can see it.
Upvotes: 0
Reputation: 159855
Salts are best when they are dynamic (say the member's join date). Even if the attacker knows the way you compute the hash, they have to brute force each salted and hashed password -- which takes a lot of time, for (in general) little reward.
That being said, if the attacker is looking at your code server-side, you already have a much larger problem.
Upvotes: 3