encryption not processed right, I think...

[anocelot]

OK.  I think I have everything installed correctly.  I'm running Mac OS 10.3 server, and when I specify:
authmysqlpwencryption none
in my httpd.conf, apache lets me in.  When I try to turn on MD5 encryption, I get an error in the log that states:
"user joeuser: password mismatch"

(Of course, I've modified the password field and set it with:

update theusers.userlogin set password = md5('blah') where username='joeuser';

so it's not still a plaintext password).  Is there a different function in mysql I should be using to encrypt passwords with md5?  Should I be using a different directive in my httpd.conf file to do this?

Here's the important part of my config file:

AuthName                        "System Authorization Required"
AuthType                        Basic
require user                    joeuser
AuthMySQLEnable                 On
AuthMySQLHost                   localhost
AuthMySQLUser                   user
AuthMySQLDB                     theusers
AuthMySQLUserTable              userlogin
AuthMySQLNameField              username
AuthMySQLPasswordField          password
AuthMySQLPwEncryption          MD5
AuthMySQLAuthoritative          On

[Jerry Stuckle]

Hi, anocelot,

MD5 encryption should work just fine like you have it.

Let's start with something easy.  What is the definition of the userlogin table in MySQL?

Jerry

[anocelot]

MySQL deffs:

mysql> desc userlogin;
+----------+---------+------+-----+---------+----------------+
| Field    | Type    | Null | Key | Default | Extra          |
+----------+---------+------+-----+---------+----------------+
| recid    | int(11) |      | PRI | NULL    | auto_increment |
| username | text    | YES  |     | NULL    |                |
| password | text    | YES  |     | NULL    |                |
+----------+---------+------+-----+---------+----------------+
3 rows in set (0.01 sec)

Actual data:
mysql> select * from userlogin;
+-------+----------+-------------------------------------------+
| recid | username | password                                  |
+-------+----------+-------------------------------------------+
|     1 | joeuser | 6f1ed002ab5595859014ebf0951522d9          |
+-------+----------+-------------------------------------------+
1 row in set (0.00 sec)

Just for reference:

mysql> select md5('blah');
+----------------------------------+
| md5('blah')                      |
+----------------------------------+
| 6f1ed002ab5595859014ebf0951522d9 |
+----------------------------------+
1 row in set (0.00 sec)

[Jerry Stuckle]

Hi, anocelot,

Sorry for the delay - I've been pretty busy here.

I tried it on my Linux system with password="blah" and it worked just fine.  As a check, I also checked the database and I have the same MD5 hash string as you do.

I normally define the MD5 password field as VARCHAR(32), but for another test I redefined it as TEXT.  That worked OK, also.

It looks like MD5 encryption in MySQL is consistant, at least.

To check the MD5 hash, we use the ap_md5() function call and compare it against the hash value retrieved from the database.  It looks like possibly the Apache function is returning a different hash value. 

I checked the Apache web site, and didn't get any hits on the ap_md5 function.  I also looked at the code in /server/util_md5.c file and there were no notes indicating a change to the code.

Which brings up another question - which version of Apache are you using? 

I dont' have time tonight, but tomorrow I'll try to get some debug code worked up to print the value hashed with ap_md5() in your Apache error log.  This should give us more information on exactly what's occurring.

Jerry

[Jerry Stuckle]

Anocelot,

Sorry for the delay.  I'm still looking at the best place to put a patch to give us the information we need.  But I had to fly down to Atlanta for a conference this weekend, and I'm a bit busy (it's midnight here and I just got back to my room).

I'll work on this again during my free time tomorrow and see if I can get something for you.  I'm trying to keep it as short as possible - but the problem is where I need to stick the macro I don't have access to the resources I need.  And I can't change that without affecting a lot more code.

So I'm looking for a way to get the info without filling the log file with meaningless messages.

I'll keep you updated on what I come up with.

Jerry

[Jerry Stuckle]

Hi, Anocelot,

Here's a patch for you to try:

---- CUT HERE ----

smartechhomes:/home/development/mod_auth_mysql-2.9.0# cat patch
--- mod_auth_mysql.c    Fri Jun 10 17:36:28 2005
+++ mod_auth_mysql.debug        Fri Jun 10 17:36:10 2005
@@ -1060,6 +1060,10 @@
     return OK;
   }

+  LOG_ERROR_1(APLOG_ERR, 0, r, "MYSQL_DEBUG: Calling function for %s", enc_data->string);
+  if (strcmp(enc_data->string, "md5") == 0)
+    LOG_ERROR_2(APLOG_ERR, 0, r, "MySQL DEBUG: retrieved pw=%s, encrypted pw=%s", real_pw, ap_md5(r->pool, (const unsigned char*) sent_pw));
+
   passwords_match = enc_data->func(r->pool, real_pw, sent_pw, salt);

   if(passwords_match) {
smartechhomes:/home/development/mod_auth_mysql-2.9.0#

---- CUT HERE ----

Sorry if it wraps; if it's a problem I'll place another copy in the PATCHES section.

This will output two messages to your Apache error log.  The first message will be the actual method we're using to encrypt the incoming string - it shoud be "md5".  If not, we need to see why that's not working correctly.

The second message will only appear if we are using MD5 encrption.  It will output two values: the first is the value retrieved from the database; the second is the value we obtained in the module by calling the ap_md5() function.  Both are md5 values, and they should match. 

Please apply the patch and let me know what your Apache error log shows.

Thanks,
Jerry

[anocelot]

AHA!  Got it - and boy do *I* feel stupid.  I'm not sure why this happened, but when I ran the most recent Mac OS 10.3.9 security update, apparently everything was fixed (it works now).  This concerns me, actually, as I didn't see anything in the official list of fixes provided by this security update that would indicate there was any system being affected that would fix this or create long run-on sentences.

(I do need to talk with the other people that have access to this box and see if any of them ran some other updaters with out me knowing - causing vast quantities of interactions which will likely result in maditory anger management training in the near future).

Kudos to Jerry for his effort, and I'm really sorry I ended up not using that patch!!!

(Please dont kill me!)

[Jerry Stuckle]

Anocelot,

Glad to hear it's working now!  But don't feel stupid - there's no way you could have known an upgrade would fix the problem.

And actually, I'm glad you didn't have to use the patch.  It means things are working as they should!

Jerry

[anocelot]

Thanks Jerry!