0

I've read several stackoverflow questions and notes about salt and password management but maybe too much as I'm not getting it or seeing the value.

My basic understanding is that they protect against rainbow tables but, when the salt is visible and stored with the database/password can't an attacker who gets access to the pwds just remove the salt and run against rainbow table?

I understand salts are supposed to be help against brute force, but from where, what is the scenario? Is it from someone trying to emulate a user login, maybe 1000's of time, like from your login form? But isn't that mitigated with basic throttling or captchas for invalid attempts?

To put another way it just doesn't make sense to me that the salt is stored so openly as seems to be the norm suggestion, when an attacker who gets access to the pwds would have access to salts as well and can just see and remove before running against rainbow table.

specifically I'm working with PHP and looking at using password_hash() and password_verify().

I have read this ticket but still not really clear: How does password salt help against a rainbow table attack?

To quote on of the answers: "A rainbow table attack always needs /etc/passwd (or whatever password database is used), or else how would you compare the hashes in the rainbow table to the hashes of the actual passwords?

As for the purpose: let's say the attacker wants to build a rainbow table for 100,000 commonly used english words and typical passwords (think "secret"). Without salt she would have to precompute 100,000 hashes. Even with the traditional UNIX salt of 2 characters (each is one of 64 choices: [a–zA–Z0–9./]) she would have to compute and store 4,096,000,000 hashes... quite an improvement."

Ok, but if they can ping against the pwds don't they have access to the salt and why wouldn't be just as easy for them to use something like password_verify() at that point just like I would when the user logs in?

Quote from accepted answer: "A public salt will not make dictionary attacks harder when cracking a single password. As you've pointed out, the attacker has access to both the hashed password and the salt, so when running the dictionary attack, she can simply use the known salt when attempting to crack the password."

I'm thinking a simple loop of this would work? Or, why not? Maybe that is my real question?

Additionally, for anyone else looking who gets here, I found this question more pertinent than the one my question is marked to duplicate, but still seems incomplete: Where do you store your salt strings?

Any help clearing my fog is greatly appreciated.

FINAL NOTE: Having completed more research and some testing and have concluded that random salting per pwd and openly storing salts with password hashes as with using php password_hash/verify does slow an attackers ability to crack the pwds but not to the degree as commonly specified like in the answer mentioned above in another question that states the benefit of even a basic 2 character salt forcing 4,096,000,000 computations vs just the 100,000 common pwds mentioned.

My problem is that this comparison does not seem to make sense as all an attacker has to really do is run the 100,000 common pwd thru password_verify and catch when/if verification return a true and move on to the next.

Slower? Yes but, depends greatly on your 'cost' setting as in my tests on a marginal virtualbox vm setup (2 processor 4069mb, 90% cap, 2015 Mac Book Pro Host) using a cost of 10 (a commonly recommended setting) 100 loops of password_verify takes 8 secondsish, does increase significantly around 14 cost, but this setup is nothing compared to what an attacker would have.

Said another way, it is confusing and I think inaccurate to think in terms of an attacker going for the nuclear option of rainbow table for all the salt options when all they seem to need to do is the same thing as they had been doing but just add running thru password-verify for their favorite plain text password list, they don't have to care about the salt or really even the cost and hash if they have some time. If your users' accounts are of any value, and they are, attackers probably have the time. But, at this point, I'm not sure what else to do, so moving on and probably going to embrace the salt until I learn of better methods.

Community
  • 1
  • 1
Geodin
  • 21
  • 7
  • you would have to create a new rainbow table for every salt. You cant just remove the salt and use an existing one –  May 04 '16 at 22:52
  • 1
    The salt is an integral part of the hash; it isn't simply the first few characters stored.... removing those first few characters still leaves the hash which has been built using that salt value, so you'd still need a rainbow table specific to that salt.... and as every password_hash() value is created with a different salt, each password would require its own rainbow table specific to that individual salt – Mark Baker May 04 '16 at 22:52
  • `"A public salt will not make dictionary attacks harder when cracking a __single__ password.`... but without salted passwords, or where the same salt is used for every pasword, then it's easy to build rainbow tables for that one password.... but if every password/hash uses a different then that one set of rainbow tables won't work for any other password/hash on the database.... and using password_verify has a time cost, so the attack will take a long time.... the whole point is that you're making it significantly more time costly to break any password, not impossible – Mark Baker May 04 '16 at 23:31
  • Thank you Mark, I appreciate the help. But apparently I need to do more research as I may be envisioning greater ability from hackers/attackers with this than is there. Still seems like it should be fairly trivial for someone focused on this stuff as an attacker to crack this by something like looping thru using password_verify (or again, something like it or it's underlying implementation) and their tables, maybe slower but doesn't seem like it would be that slow, and I don't understand how easily it gets once they've crack one/few. – Geodin May 04 '16 at 23:49
  • just a few thoughts, if you already the table of user passwords, the site is probably fuc*ed. if you cracked my password on site X it would not work elsewhere as i use a unique one for every site (thank you lastpass) –  May 04 '16 at 23:56
  • No, hashing and salting with password_hash/password_verify doesn't make a password unbreakable by brute force attack (there's no such thing); it just makes it very slow.... and means that each password has to be attacked individually, so breaking one password doesn't give any help with any other password, and each of those individual attacks is also very slow – Mark Baker May 05 '16 at 07:22
  • **Without a salt** you can just google for a precalculated hashes for tons of passwords. **With a single salt** you would have to build one single rainbow table using this salt and you would get all passwords. **With unique salts for each password** you would have to build dedicated rainbowtables for each password, so you get only one password per rainbowtable. This makes rainbowtables unpracticable, brute-forcing is faster, it doesn't make sense to complete the rainbowtable if you found the only password. Tried to explain this in my [tutorial](http://www.martinstoeckli.ch/hash/en/index.php). – martinstoeckli May 05 '16 at 12:52
  • Again, Thank you for the comments and help. I'm going to add one more edit to the question to frame my current understanding after doing more research and testing for anyone else that stumbles here somehow and then I'm moving on. – Geodin May 05 '16 at 15:44
  • The three main points in the tutorial are: 1.) salting 2.) key-stretching 3.) using a server side key; it should actually answer your questions. Salting alone will mitigate only the problem of building a rainbow table, to get all passwords in one step, nothing more nothing less. It is necessary, but with a salt alone you won't get safe password storage. On the other side, if you can only check 10 passwords per second, you can forget about brute-forcing in reasonable time, fast algorithms allow the check about [100Giga per second](http://hashcat.net/oclhashcat/#performance). – martinstoeckli May 06 '16 at 09:50

0 Answers0