bubble has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I am trying to get htaccess via AuthDBI. I can't seem to figure out how it checks the password. I have read the source of AuthDBI.pm. No luck. What I am trying to do is get a perlscript to fill a database with a table called users. Which includes row :username,password and groupname. What goes wrong is when I encrypt the password and put it in the database AuthDBI rejects all my logins. But when I set PerlSetVar Auth_DBI_encrypted off. All is fine. Pure logic I circumvented the encryption part and just do a unencrypted match.
sub simpelCrypt { my $p = @_; (1) my $salt = join '', ('.', '/', 0..9, 'A'..'Z','a'..'z')[rand 64 +, rand 64]; (2) #my $salt = ($p =~ /^(..)/); my $crypt = crypt($p, $salt); return $crypt; }
My (1) $salt gives me those errors with login. My (2) $salt gives me an empty row in the database. The solution might be trivial but, aren't they all. Thanks for your trouble

Replies are listed 'Best First'.
RE: AuthDBI salt ?
by DrManhattan (Chaplain) on Aug 01, 2000 at 17:45 UTC

    (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:

    1. AuthDBI fetches the (encrypted) password from the database
    2. It then encrypts the plaintext password given by the user with the ciphertext password as salt (the salt is stored in the first bytes of the ciphertext. The exact number of bytes depends on the algorithm you're using)
    3. Finally it compares the stored ciphertext with the new ciphertext

    Here's the relevant code from the section that checks a cached password:
    $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

Re: AuthDBI salt ?
by Anonymous Monk on Mar 02, 2001 at 16:44 UTC
    Hi bubble,

    the following snippet I 've found in the PERL Cookbook:

    if (crypt($password, $encrypted) ne $encrypted) { die "You are not $username\n"; } else { print "Welcome, $username\n"; }

    The conclusion seems obvious to me: you just have to encrypt the passwords in your database using an arbitrary salt.
    Did you finally succeed?

    Cheers, Sapristi
Re: AuthDBI salt ?
by bubble (Novice) on Aug 04, 2000 at 16:31 UTC
    The $salt needed to check get the module to check against the crypted in the database is $salt = substr ($p, 0, 2), with $p beeing the plaintext password that is inserted into the database. And when the encrypted directive is set to password It assumes you used this $salt.