Whats wrong with storing your salt in DB?
View Single Post
11-17-2007, 03:01 AM
La Vida es Sueño
Join Date: Sep 2007
I'm guessing the theory behind this is that if your password hash has been revealed then assumingly the attacker has access to the modification of a MySQL statement, and thus, modifying the MySQL statement to acquire the salt as well would be fairly straightforward.
However, salts are really to protect against inside jobs more than anything else. A system should be fairly secure and relying on the salt to secure your users' passwords if the system does get hacked, is clearly idiotic.
Even if an attacker has the salts for the passwords, they would still have to regenerate their entire database containing hashes to include the salt you are using
(hopefully multiple salts)
. Therefore you can see that by using a dynamic salt,
as discussed here
, increases the security by adding lots more computing time and CPU cycles in order to crack a string of password hashes. This is because the attacker's original hashes will never match, unless there is a hash collision,
as discussed here
, but that would still result in an incorrect password being thrown out - although it would still technically match because of an identical hash.
My conclusion is that you might as well store your salts in the database alongside the passwords. Also generate a unique salt for each individual password. By storing the salt in an external file you are inadvertently slowing your script down by making the PHP script access and read a file to memory.
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.
View Public Profile
Send a private message to Wildhoney
Visit Wildhoney's homepage!
Find More Posts by Wildhoney