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

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

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

Replies are listed 'Best First'.
Re:^4 What's the idea of different salts in crypt()? by blakem (Monsignor) on Sep 21, 2001 at 03:30 UTC
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 =~ /^(..)/);` [download] Take a look at the last example in the node I replied to. -Blake	[reply] [d/l]
Re: Re:^4 What's the idea of different salts in crypt()? by mr_mischief (Monsignor) on Sep 22, 2001 at 01:46 UTC
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	[reply]