Re^3: Replacing crypt() for password login via a digest - looking for stronger alternative

[Bod]

Rainbow tables are hash-realpassword pairs and can be very fast in telling you the password given the hashed-password

Yes - I get that salting helps from attack using a rainbow table.

But passwords are typically rather short so not too difficult to crack by brute force. Assuming the password is made up only of upper case, lower case letters and numbers then there are only (!) 218,340,105,584,896 permutations. That is 62⁸. Whilst that's a lots of permutations, I read recently that 2011 technology could run through all those in 23 minutes. Imagine what 2021 technology can do and there is no need to go through them all. You stop when you get it right!

So, to take a simple example - let's say the hashed password was 1234abcdxxyyzz. Without salting you assume a minimum length of 3 characters so start at aaa then aab, aac, etc. If instead you have salts stored in the same table as the hashed password you just add the salt to the end and try the permutations. So instead of aaa you try aaaSaLT123, aabSaLT123, etc. until you get the result 1234abcdxxyyzz.

Or am I missing something? Is that not how it works?

[hippo]

But passwords are typically rather short so not too difficult to crack by brute force.

What you are describing here are not passwords in general but poor passwords. Good passwords are typically rather long so too difficult to crack by brute force.

Assuming the password is made up only of upper case, lower case letters and numbers then there are only (!) 218,340,105,584,896 permutations. That is 62⁸.

Again, good passwords do not just consist of letters and digits. Even if they did it seems you are assuming just Roman letters and Arabic digits. There are plenty of other character sets from which to choose.

If you don't want to get pwned, don't use poor passwords. If you don't want your users to get pwned don't let them use poor passwords.

[bliako]

I believe the difference (using average hardware) between brute-forcing (which involves hashing each candidate password) and rainbow-ing (which involves just a dictionary lookup) is a lot in terms of time. But I don't have the numbers nor the time to benchmark right now. Time is important in that a db breach will sooner or later be noticed (well...), so it's a race against the user getting notified by db admin and changing their password. Also note that salts can be mixed within the password. Or placed either at the beginning or the end or both. These methods require the hacker to also have access to the in-house algorithm for salting the password, i.e. where and how to intermix. Which depends on many factors.