|
in reply to Re: Re: What's the idea of different salts in crypt()?
in thread 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 |
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 =~ /^(..)/);
Take a look at the last example in the node I replied to.
-Blake
| [reply]
[d/l] |
|
|
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] |
|
