Whats wrong with storing your salt in DB?
 

Apparently if you store your salt in db the cracker has more change of cracking passwords then again if they can get a hold of your db then they have access to cpanel right, then they have access to your files, and if you didn't store salts in db but in the files what makes it so they just wont use the salt from the file, which would take shorter time to crack passwords if they get your hashed pw's from your db, then when you have a whole bunch of random salts the cracker would take forever to crack the hashes, what makes this safe anyways? Either way theres no real way to hash your passwords to make them safe. Like in "Pro PHP Security" said, "nothing on the internet is un-vulnerable".

Almost always they will never get access to the cpanel, because they won't know the url to it. Also people shouldn't use the same name/password combination for both, at least I've never worked for anyone who hasn't and I don't. About the book, I wouldn't rely on one source for a single thing, try reading several blogs on this subject.

my theory is if they have access to your file system you're screwed anyways, as the user DB and PW have to be stored somewhere.. which is why web interfaces for your files isn't exactly something you put on your front page reading "Feel free to browse my server's files." ;)


I usually put the salt in a class below the web view, called up privately. And I agree, nothing is safe on the internet. There's only unsecure, and obscured. :)

The way I do it is the same way Chris Snyder and Michael Southwell do it in there book "Pro PHP Security", I've been doing it this way before reading this book and apparently I don't do it right heh.. I guess them guys don't do it right either. Then again a lot of people use that method to store salts.

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.

WildHoney took the words right out of my mouth. The point of salts is to provide a secure encryption key, and it is always best to make it dynamic. I remember on one site a while back, I stored the salt with the password in the DB. I used an md5 function to generate a random key based upon the current time (md5(time)) and than uploaded that to its own column. Although that was a couple of years ago and there are course better methods of encryption now. :)

exactly lol and then again, if they do have the salts, how do they even know how i coded it into the script lol? Or how many times I used the salt for the password? Shit or even if I reversed the password and the salt all together?

My salt is 7 characters salt stored in DB and in the password row, the password is md5 of salt and the password.

The salt is randomly generated, either when the user is created or if the user changes the password.

However, if the hacker has access to my MySQL server, he can modify the salt and regenerate the password field with md5 hash generators that is ONLY if he knew how I generate the passwords within the code.

Edit: Adam is it good practice to use more than 1 salt ?

How I see is, if you have one salt regardless, and the hacker has only access to your db, it wouldn't matter if they change the hash they can delete everything lol...daily backups ftw, and again salt could be positioned in anyway you could have it added to your hash using substr, you could hash it into your md5 at any position, in any form backwords, half of the hash you could even flip the hash and include it twice. It doesn't matter they won't have your password :). So if they have pw to your db then yah you could be screwed, they can delete everything thats about it, and waste there time not cracking there passwords lol...Most crackers or script kiddies are only worried about yah I defaced your website, they don't care about anything else. Have you read on ha.ckers.org? Nice blog some good articles.

I've not actually read ha.ckers.org, no, but I shall have myself a peep in a moment! One thing salts do protect against is matching a user across many websites. I know when OINK was taken by British and Dutch police, users of another torrent site were told to change their passwords in fear of being matched up if the other site was taken down, or had their account security breached if OINK didn't use salts. Either way, salts would have been the answer to protecting against both.

In addition, I was quite fascinated with your idea on placing the salt anywhere in the password and so I've come up with 2 functions. 1 function is a PHP function to easily generate that, and the other is a MySQL function to be used in the SELECT statement when checking to see if it is a valid password.

As passwords can be variable lengths before they're hashed, I have set the 3rd argument to take a percent value and then it will work out the position based on the password's length. The function will return all the data you require to enter into your member table.


You can then access the items it returns like so:


You need to enter all those into the member table. So you should have at least 3 columns in your table: password, position and salt. The MySQL query I came up with is this:


I had to add 1 to the position column as it appears the INSERT works from a different base number when compared PHP's substr. They do say you learn something new everyday!

...And that's my implementation! Passwords just became a whole lot securer. Maybe. Or maybe it was a beautiful exercise in futility. Not too sure on that front! It sure does look beautiful though.