Re^2: Replacing crypt() for password login via a digest

The salt (as in "a set of random bytes") is ~~appended or prepended~~ mixed into the password and the result is then hashed. Hashing is a one way function. Rainbow tables are hash-realpassword pairs and can be very fast in telling you the password given the hashed-password (as fast as a perl-hashtable=dictionary lookup-by-key, which is, in theory, O(1)). So, if your hashed-password contains a random set of values intermixed with the real password, then the given rainbow does not work anymore! Or at least you will need a different rainbow table for each possible salt (for example, 60^10 for a 60-characters-range, 10-byte-long salts). For these reasons, salts can be stored in your hacked db alongside the password and even in plain text. The cost for the hacker will be enormous. But of course not impossible.

there are a few points that need to be clarified, which I don't know. 1) Should the character set of the salt be the same as the password or what it should be, should it match the statistical distribution of the password? I guess it does not matter, but I am not an expert. 2) Is it really paranoid to store salts in a different db, even in a different host? 3) how about hashing them? I think that would work if salt length is random and character-range in 0-255, so as hacker not to be able to know if unhashing of salt succeeded.

What I am sure about is to never use the built-in RNG for encryption ops! It is looking for trouble big time. Use one of the so-called "cryptographically secure RNG".

bw, bliako

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

Replies are listed 'Best First'.
Re^3: Replacing crypt() for password login via a digest - looking for stronger alternative by Bod (Parson) on Jun 19, 2021 at 16:47 UTC
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?	[reply] [d/l] [select]
Re^4: Replacing crypt() for password login via a digest - looking for stronger alternative by hippo (Archbishop) on Jun 19, 2021 at 18:06 UTC
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. 🦛	[reply]
Re^4: Replacing crypt() for password login via a digest - looking for stronger alternative by bliako (Abbot) on Jun 24, 2021 at 13:19 UTC
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.	[reply]