We just implemented mod_auth_mysql V2.9.0 for our Apache V2.0.52 web server. We are also running MySQL V4.1.7 for our database server. We also have php v4.8.3 installed and our web applications are primarily written in php.
We set up mod_auth_mysql as per the instrauctions and, in testing, everything ran fine. Folks can enter user ids and passwords and they can be authenticated into out web server.
However, in a few instances, some passwords will not work. We have yet to determine a pattermn, but a password like "flagstaff" will not work at all. A password like "LaTrobe" will not work, but "latrobe" will work.
Our database definition for table users looks like this:
AuthMySQLHost turcotte.colorado.edu
AuthMySQLUser authuser
AuthMySQLPassword PaSsW0Rd
AuthMySQLDB auth
AuthMySQLUserTable users
AuthMySQLNameField user_name
AuthMySQLPasswordField user_passwd
AuthMySQLGroupTable groups
AuthMySQLGroupField user_group
AuthMySQLPwEncryption aes
AuthMySQLSaltField <asa>
require group user
</Directory>
We made sure that each user entry has a corresponding group entry. When we look at the password in the database, there are no trailing spaces. We are able to use aes_encrypt and aes_decrypt on the password, at will. Yet, the web server gives an authentication failed for certain passwords. We also verified that there was not a user name mismatch, and there is no problem there either. Finally, the group name for each account is also correct.
Anyway ideas would be most welcome.
Take care!
Nick Metrowsky
nmetro@cires.colorado.edu
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the delay in getting back to you, but I've been investigating this problem.
Your problem looks like it might be caused by trailing blanks being stripped. But if your definitions are correct, this shouldn't happen - a tinyblob field should not strip trailing blanks, and I didn't find anything on it in the MySQL change log or bug database.
Also, I tried the following mysql statement:
SELECT hex( AES_ENCRYPT( 'LaTrobe', 'asa' ) )
This gave me back a value of:
68E4FFB5F4CAA188455CC7919E51CFC3
which does not have a trailing blank (X'20'). If the values you are using are those listed in your message (I actually hope they aren't, for security reasons), it shouldn't be a problem.
Unfortunately, I can't test it here right now.
I would be interested in knowing what is in the password field for the failing id's. You should have 16 bytes (32 hex characters). Since this is binary data, you will have to use the HEX function to display it. Also, please ensure your password field is actually a tinyblob, and not one of the char types (I've dont that before :-) ).
Let me know what you find; if this doesn't find it we'll have to check some other things.
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Never mind the previous comments. I was able to set up a test system and duplicate the problem.
The problem comes in because of the binary data. In copying the encrypted password from the database structure to the program structure, we were using one of the Apache string functions. This works fine with character data, but not binary.
The problem with the password "flagstaff" is it has an embedded null character in the data. Of course, the string function things this is the end of the data, and doesn't copy the rest. It results in a password mismatch.
I went into the password fetch routine and changed it to work with binary data. I had to fetch the length of the data in the password field and use memcpy to copy it over.
I have a fixed version for you to test. If you can send me your email address (privately, if you like), I can send you the updated version.
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Everyone,
We just implemented mod_auth_mysql V2.9.0 for our Apache V2.0.52 web server. We are also running MySQL V4.1.7 for our database server. We also have php v4.8.3 installed and our web applications are primarily written in php.
We set up mod_auth_mysql as per the instrauctions and, in testing, everything ran fine. Folks can enter user ids and passwords and they can be authenticated into out web server.
However, in a few instances, some passwords will not work. We have yet to determine a pattermn, but a password like "flagstaff" will not work at all. A password like "LaTrobe" will not work, but "latrobe" will work.
Our database definition for table users looks like this:
+-------------+-------------+------+-----+-------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+-------------+------+-----+-------------------+-------+
| user_name | varchar(60) | | PRI | | |
| user_passwd | tinyblob | | | | |
| ciresid | int(11) | | | 0 | |
| timeEnter | timestamp | YES | | CURRENT_TIMESTAMP | |
+-------------+-------------+------+-----+-------------------+-------+
Our database definition table groups looks like this:
+------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| user_name | varchar(60) | | PRI | | |
| user_group | varchar(20) | | PRI | user | |
| ciresid | int(11) | | | 0 | |
+------------+-------------+------+-----+---------+-------+
The mod_auth_mysql.conf file for Apache looks like this:
<Directory /cires/www/intranet>
AuthName "Group authenticated zone"
AuthType Basic
AuthMySQLHost turcotte.colorado.edu
AuthMySQLUser authuser
AuthMySQLPassword PaSsW0Rd
AuthMySQLDB auth
AuthMySQLUserTable users
AuthMySQLNameField user_name
AuthMySQLPasswordField user_passwd
AuthMySQLGroupTable groups
AuthMySQLGroupField user_group
AuthMySQLPwEncryption aes
AuthMySQLSaltField <asa>
require group user
</Directory>
We made sure that each user entry has a corresponding group entry. When we look at the password in the database, there are no trailing spaces. We are able to use aes_encrypt and aes_decrypt on the password, at will. Yet, the web server gives an authentication failed for certain passwords. We also verified that there was not a user name mismatch, and there is no problem there either. Finally, the group name for each account is also correct.
Anyway ideas would be most welcome.
Take care!
Nick Metrowsky
nmetro@cires.colorado.edu
Hi, Nick,
Sorry for the delay in getting back to you, but I've been investigating this problem.
Your problem looks like it might be caused by trailing blanks being stripped. But if your definitions are correct, this shouldn't happen - a tinyblob field should not strip trailing blanks, and I didn't find anything on it in the MySQL change log or bug database.
Also, I tried the following mysql statement:
SELECT hex( AES_ENCRYPT( 'LaTrobe', 'asa' ) )
This gave me back a value of:
68E4FFB5F4CAA188455CC7919E51CFC3
which does not have a trailing blank (X'20'). If the values you are using are those listed in your message (I actually hope they aren't, for security reasons), it shouldn't be a problem.
Unfortunately, I can't test it here right now.
I would be interested in knowing what is in the password field for the failing id's. You should have 16 bytes (32 hex characters). Since this is binary data, you will have to use the HEX function to display it. Also, please ensure your password field is actually a tinyblob, and not one of the char types (I've dont that before :-) ).
Let me know what you find; if this doesn't find it we'll have to check some other things.
Jerry
Nick,
Never mind the previous comments. I was able to set up a test system and duplicate the problem.
The problem comes in because of the binary data. In copying the encrypted password from the database structure to the program structure, we were using one of the Apache string functions. This works fine with character data, but not binary.
The problem with the password "flagstaff" is it has an embedded null character in the data. Of course, the string function things this is the end of the data, and doesn't copy the rest. It results in a password mismatch.
I went into the password fetch routine and changed it to work with binary data. I had to fetch the length of the data in the password field and use memcpy to copy it over.
I have a fixed version for you to test. If you can send me your email address (privately, if you like), I can send you the updated version.
Jerry
Hi Jerry,
Thank you for the quick response. You can send it to me at nmetro@cires.colorado.edu.
Take care!
Nick
Copy of the new version sent.