Peter, > I would say it really depends upon the project. The salt can not only > protect against rainbow tables and password hash collisions, if it is > unknown to an attacker then it essentially acts to further strengthen > the hash by vastly expanding the keyspace.
That's not true. There are two types of secure algorithms in cryptography. Those that are kept secure by a secret, and those that are secure by effort. Hashing is an effort based algorithm. It's difficult to reverse, so you need to brute force, expending a lot of effort in the process... Salts are designed to make that brute forcing non-amortizable, only (meaning that the effort put in to brute force one hash can't be applied to another). The way they are used in the algorithms shows that. They are even stored directly with the hash in a number of implementations (crypt being a key one). That should point out how the security that a salt adds does not depend on it being secret. > Supposing an attacker is > trying to get at the password for just one user account (say, admin) > and the hashed password is available - if the salt can be > predicted/guessed, then the keyspace is reduced to that of an unsalted > password and you can run a dictionary attack on the hash. If, on the > other hand, the salt is unpredictable and you don't have access to it, > there is no way to run a dictionary attack (offline, that is). The > security here depends upon storage as well, but the point remains - a > salt isn't by default something you can make public knowledge. Then it's not a salt. And unless you *really* know what you're doing, it's not worth it, and at best you're not making it more secure (and at worst, you're significantly reducing the security). Remember, security through obscurity is not security. Check out this post, and the comments from experts: http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html > It might be a theoretical concern for most people and the people > really wanting the extra level of security would probably know well > enough how to get exactly what they need - but if provisions are made > so you could reuse the same function you might also be able to educate > developers better. I.e. make it easy to do the right thing and more > people will do it. No, if people want the extra level of security, they should then encrypt the hash with a secure key before storing it. Note that 2 algorithms would be in place, one proof of work, and one dependent upon a secret. Trying to combine them because one parameter looks like it could be a secret is not the way to go... Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
