Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Re: What's the idea of different salts in crypt()?

by blakem (Monsignor)
on Sep 20, 2001 at 11:03 UTC ( [id://113537]=note: print w/replies, xml ) Need Help??


in reply to Re: What's the idea of different salts in crypt()?
in thread What's the idea of different salts in crypt()?

I've seen people use the password as the salt before, but I have some hesitations about it. This seems to defeat the two arguments I've heard for salts.

  • Same plaintext yields different ciphertext.
    Obviously if the salt is determined by the plaintext, this idea flys out the window.
  • Greatly expands the ciphertext dictionary needed to check for common passwords.
    If the cracker figures out that your salts are based on the plaintext, the dictionary needed is exactly the same size as if there were no salts used at all.
Of course, I've never quite gotten the concept of salts anyway.... They seem like a poorly thought out concept left over from the 70s. Use one of the modules mentioned above instead.

-Blake

  • Comment on Re: Re: What's the idea of different salts in crypt()?

Replies are listed 'Best First'.
Re: Re: Re: What's the idea of different salts in crypt()?
by mr_mischief (Monsignor) on Sep 20, 2001 at 19:36 UTC
    It think you're confusing when to apply the advice to use the whole password. You don't use the plaintext password to create a salt when encrypting the password. You give the crypt function the whole encrypted password, salt and hashed password together as appears in the file, as the salt when authenticating a freshly entered plaintext password. This allows the crypt function to pull out as many bytes for the salt as the native crypt uses, whether that be the two for DES or some longer value. The rest is generally simply discarded by the crypt function. This way, you can write password authentication code which will work so long as the algortihm being used for authentication is the same as the one used for password creation and the two use the same interface. There's no need this way for the application to know beforehand how many bytes need to be given for the salt.

    That being said, let me repeat that when generating the salt, the plaintext password should play absolutely no role.

    Chris
    911
      The code I was commenting on does exactly that... it uses the plaintext password when generating the salt. In effect it is doing something like:
      my ($salt) = ($plaintextpassword =~ /^(..)/);
      Take a look at the last example in the node I replied to.

      -Blake

        In my estimation, that's quite less than completely effective. You were right to question that.

        However, the node you replied to used the first two of the entered password as the salt, then returned the remainder of the password, without that salt. This actually keeps the salt from needing to be stored at all, as it is supplied again every time the password is entered for authentication. This does, however, shorten the input to the plaintext portion of the hash by two bytes. I've not the expertise to surmise the net effect of this scheme without some serious consideration. Perhaps someone else can weigh the pros and cons easier than I.

        Chris
        911

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2024-04-25 14:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found