On 14/06/12 16:26, Peter Lind wrote: > 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. 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. > > 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. May I ask how would you end up at the situation where the attackers have the password hashes but not the salt?
Any process which needs to read the password hashes will also need knowledge of the salt. Thus an attacker would most likely also know both. That's precisely how salts are designed to work. I admit you could have a common salt for all users stored in php and only a leak of the database. But such salt would most likely be provided by the user, generated using a different program... expected to be secure. Using a shared salt is worse than a uniqe salt per user, so that's not something to promote either. You wouldn't be "educating in the right way". -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
