Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

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

by Bod (Parson)
on Jun 13, 2021 at 18:46 UTC ( [id://11133826]=note: print w/replies, xml ) Need Help??


in reply to Replacing crypt() for password login via a digest - looking for stronger alternative

In the comments of the article you refer to it says...

In a more real life scenario, $shash would likely be retrieved from the DB you use to maintain credentials.

When passwords are leaked, I have always assumed that someone has somehow maliciously extracted the data from the User (or equivalent) database table. From this they have got a list of email addresses and password hashes. But if the database table also has the salts in it, is it any more secure than just using a strong encryption algorithm without salting?

Personally I keep name and email address data in a different table to the user ID and encrypted passwords. That table exists in a different schema, albeit within the same RDBMS.

Replies are listed 'Best First'.
Re^2: Replacing crypt() for password login via a digest - looking for stronger alternative
by bliako (Monsignor) on Jun 18, 2021 at 07:30 UTC

    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

      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 628. 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?

        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 628.

        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.


        🦛

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11133826]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (4)
As of 2024-03-29 00:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found