On 14 June 2012 17:50, Ángel González <keis...@gmail.com> wrote: *snip*
> 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. If your salts are not stored with your password hashes, then an sql injection that would leak your password hashes would not leak the salts. The recent database leaks come to mind: had they only contained password hashes but no salts (I know the hashes were unsalted, but *had* they been salted ...) attackers would have faced an impossible task trying to bruteforce even just one hash. Otherwise, you'd be able to focus on a given account (an admin account comes to mind) and spend all your efforts on that using the typical options. As pointed out once or twice, for most people/purposes, it's a theoretical discussion. That doesn't mean it shouldn't be taken into consideration though (people rarely break into your house where you expect them to). > 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". And I'm obviously not advocating a shared salt (at least, I wasn't thinking I was, especially seeing as I asked for a parameter in function to make sure that salts would be more random). Regards Peter -- <hype> WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 </hype> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
