in reply to AuthDBI salt ?
(2) is a fantastically bad idea. It looks like an attempt to set the salt to the first two characters of the plaintext password, though it actually just sets it to 0 or 1. If it worked as apparently intended, any attacker looking at your passwords would immediately know the first two characters of the plaintext. Also, if your system uses something other than DES for its crypt(), two bytes of salt won't be enough.
As for how AuthDBI checks the passwords, here's what the pod says:
Finally the passwords (multiple passwords per userid are allowed) are retrieved from the database. The result is put into the environment variable REMOTE_PASSWORDS. Then it is compared to the password given. If the encrypted directive is set to 'on', the given password is encrypted using perl's crypt() function before comparison. If the encrypted directive is set to 'off' the plain-text pass- words are compared.
So with encrypted passwords set 'on', it works like this:
$salt = $Attr->{encryption_salt} eq 'userid' ? $user_sent : $passw +d_cached; my $passwd_to_check = $Attr->{encrypted} eq 'on' ? crypt($passwd_s +ent, $salt) : $passwd_sent; # match cached password with password sent $passwd = $passwd_cached if $passwd_to_check eq $passwd_cached;
Looks like it uses the userid as a salt if you have Auth_DBI_encryption_salt set to 'userid', which strikes me as kind of silly.
Store your passwords in crypted form in your database, using (1) to generate your salt (though you should verify that your system's crypt() only needs two bytes of salt), make sure Auth_DBI_encryption_salt isn't set to 'userid', and you should be alright.
-Matt
|
|---|