I understand the concept. Don't store a clear text password for obvious reasons, hash it. Obscure it more by salting.

What I don't understand is the scenario in which it becomes practical. Assuming a hacker has access to the information in a user's table for example, they would have access to the hashed password and unique salt. Is the only piece of information missing is the hashing algorithm used? Couldn't they use a rainbow table attack and still brute force the password with these two pieces of information?

This post was edited by ROM on Sep 5 2017 12:32pm

Salted Password Hashing - Doing it Right
https://news.ycombinator.com/item?id=7285522
Dunno, haven't read it, but I assume the comments or the article probably has some interesting things discussed

Edit: lol double post

This post was edited by BlueHat on Sep 5 2017 02:24pm

It is interesting but more of a discussion of implementation and hashing algorithms.
But no answer to my question. My questions is more of a fundamental questions I guess.

If it is random enough it will take millions of years to find out what your password COULD BE through brute forcing. If you use a rainbow table and the customer is using an insecure/weak password it may be feasible, but it still may take a long time and a lot of compute power. If the password is truly random it will be impossible to determine the password because there are a huge number of possible inputs for every hash value. Encryption can be reversed, but hashing cannot.

see: https://stackoverflow.com/questions/6776050/how-long-to-brute-force-a-salted-sha-512-hash-salt-provided

edit: Also, a lot of hackers will give up when they see encrypted data or sell the encrypted data for a fraction of the normal value.

This post was edited by waraholic on Sep 5 2017 07:12pm

Ahh I see. Thank you for that link and explanation. It really clears things up.
So basically while it is possible its not feasible to brute force given a hashed password and salt.

That depends on hashing algorithm. If the algorithm is fast (especially md5, sha1) and there are no thousands of iterations then cracking password is usually trivial and fast. With a powerful gpu's you can try 100's of billions of combinations per second. Salt only prevents pre-computed cracking (rainbow tables), but if your database is leaked and you have user | hash | salt you can usually crack it by just attempting "test1salt" "test2salt" etc. Depending on application and how it applies the salt.

That's why you should be using pbkdf2 or simillar scheme with sha512. Slow enough to hinder any cracking attempts but fast enough to not ddos your service when people login normally.

The difference between 100 billion passwords/second and 10 passwords/second is real.

I'll look that up. Thanks.