As of November 27, 2010 I am using CENTOS 5.5 (Linux 2.6.18-194.11.3.el5 kernel), Apache 2.2.3, mySQL 5.0.77, current mod_auth_mysql, current CPAN Crypt::OpenSSL::AES and current Crypt::SaltedHash.
In my configuration mod_auth_mysql works just fine with plain text passwords drawn from the mySQL database when AuthMySQLPwEncryption is set to "none".
However any attempt to use Crypt::OpenSSL::AES encrypted passwords or Crypt::SaltedHash SHA-1 results in a mod_auth_mysql challenge dialog that never admits the correct ID & password.
If I access the SQL file, recover the encrypted password, and use Crypt::OpenSSL::AES to decrypt, I succeed in recovering the correct unadulterated password.
If I access the SQL file, recover the encrypted password, and verify the plain text password using Crypt::SaltedHash, only the correct plain text password verifies.
I didn't really know what to do with the AES key so I tried is as the required AuthMySQLSaltField - although it clearly isn't a salt value. Oddly enough I could not find a CPAN Crypt method that would take a salted AES value. The mod_auth_mysql is a tad vague about what should go in the required AuthMySQLSaltField for AES encrypted password.
So the next step was to try the venerable SHA-1. To do so I used CPAN's Crypt::SaltedHash to generate the encrypted password in the mySQL file . In httpd.conf parameters above I deleted AuthMySQLSaltField and changed to "AuthMySQLPwEncryption sha1". The encrypted password could be read and properly validated from the mySQL database using Crypt::SaltedHash's "validate()" method; however, mod_auth_mysql rejected the same password.
I found no errors in the Apache or Perl logs.
Has anyone actually used encryption with mod_auth_mysql? Every example I've seen thus far skirts the encryption issue.
I'd really appreciate knowing what I could use to generate an AES encryption acceptable to mod_auth_mysql and what to do with AuthMySQLSaltField when using AES encryption - which appears to use a key rather than salt. Alternately I'd like to know what Perl method will generate an acceptable salted SHA-1 encrypted password.
Regards,
Aza D. Oberman
Washington, DC USA
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We redid the http.conf settings to dial in an 8 byte salt value. We ran AES_ENCRYPT() and AES_DECRYPT() from the command line and hex looks fine.
Yet any attempt to authenticate via mod_auth_mysql is refused and the now famous "mysql invalid encryption method aes" is generated when an authorization is attempted.
The whole thing works fine provided no encryption is used ("AuthMySQLPwEncryption none").
Any suggestions?
Aza
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've only used "Auth_MySQL_Encryption_Types Apache" but it works great.
The only comments I can add are that it seems odd that you're using directives with no underscores. I would double-check those. On Debian Lenny, /usr/share/doc/libapache2-mod-auth-mysql/DIRECTIVES.gz lists their syntax as one of:
Auth_MySQL_* and AuthMySQL_*
eg.
Auth_MySQL_Encryption_Types
I found odd behaviour when auth_basic was also enabled at the same time. Make sure all other auth_ mods are disabled when you test your setup.
Hope that helps,
Imran-UK
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the suggestion, Imran. Wrong directives certainly would muck up the works and leave me up to my skirts in unintended defaults.
I'm running version 3.0.0 of mod_auth_mysql and not familiar with it's quirks, so your observation sent me scrambling back to the documentation. On this side of the pond http://modauthmysql.sourceforge.net/CONFIGURE presents the "AuthMySQLPwEncryption" encryption directive without under scores ( "_") and makes no mention of "Auth_MySQL_Encryption_Types"!
I also notice that in "Latest News" at http://modauthmysql.sourceforge.net/ the entry for version 2.6.0 touts using "AuthMySQLPwEncryption" in lieu of the previous generation's "AuthMySQLCryptedPasswords," "AuthMySQLScrambledPasswords" and "AuthMySQLMD5Passwords "
Turning to the possibility that I have conflicting settings (which would also muck things up) I looked for mention of Auth_MySQL_Encryption_Types in the on-line documentation but found no mention. The CONFIGURE doc installed on the server (CENTOS/Apache) was also mum on the subject.
Is it possible you are running a different version of mod_auth_mysql? Would you mind sharing your httpd.conf mod_auth_mysql configuration? I've winnowed mine down to:
I was using CPAN's Crypt::OpenSSL::AES to encrypt the password and then stuffing the result in a TINYBLOB in MySQL. I'm able to recover and decode the password with no problems but mod_auth_mysql simply rejects any attempt to sign in. I'm now trying the MySQL ENCRYPT_AES function to do the encryption since one AES encription strategy can clearly differ from another in matters of salting and padding.
Again, thanks for your thoughtful suggestions Imran!
Your fellow pilgrim,
Aza
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is clearly something amiss with mod_auth_mysql or it's "documentation" when AES encryption is used.
I set up the database and got mod_auth_mysql working fine with an unencrypted password.
I then used SSH to go to the remote server and open the MySQL monitor and overwrite the plain text password with an AES encrypted one, thusly:
# mysql -h localhost -u root -pPaSSwOrD
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 12
Server version: 5.0.77 Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> use "myDataBase";
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
mysql> UPDATE myTable SET user_passwd=AES_ENCRYPT('caj01','jl7RFtVoSAq47kwq') WHERE account='01cajon';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
I now went to httpd.conf and changed "AuthMySQLPwEncryption none" to "AuthMySQLPwEncryption aes" and rebooted the entire server.
Next came a quick dump of the database and sure enough the plain text password "caj01" had been changed to "z襨ztR@[?գᩧ?/td>
" (not reproducible here in plain text but clearly binary).
Then I fired up my browser (IE) and went to the protected directory on the Web site. The mod_auth_mysgl challenge came up as expected, but try though I might the password was rejected.
So clearly mod_auth_mysql cannot manage AES encryption from a CPAN module or from MySql's own AES_ENCRYPT() - or there is some as yet unclearly documented way to do this.
What's interesting is that thus far *no one* has come forward on this forum, or other forums where I've shared my dilemma, to say they'd succeeded in using mod_auth_mysql with AES encryption. If you've been fortunate enough to have made AES encryption work with mod_auth_mysql would you be so kind as to share two things:
1) Your httpd.conf settings; and,
2) How you encrypted the password.
Regards,
Aza
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
$ aptitude show libapache2-mod-auth-mysql
Package: libapache2-mod-auth-mysql
State: installed
Automatically installed: no
Version: 4.3.9-11
Priority: optional
Section: net
Maintainer: Joey Schulze <joey@debian.org>
Uncompressed Size: 119k
Depends: libc6 (>= 2.7-1), libmysqlclient15off (>= 5.0.27-1), apache2.2-common (>= 2.2.3-3)
Description: Apache 2 module for MySQL authentication
A module for the Apache 2 web server which enables HTTP authentication against information stored in a MySQL database.
(although I don't know if this maps to the actual Apache mod version)
A snippet of my config from my non-production server:
<Directory "/var/www/foo">
AuthName "My Login"
AuthType Basic
Auth_MySQL on
Auth_MySQL_Host localhost
Auth_MySQL_User www-data
Auth_MySQL_Password bar
Auth_MySQL_DB mydb
Auth_MySQL_Password_Table user
Auth_MySQL_Username_Field name
Auth_MySQL_Password_Field password
Auth_MySQL_Encryption_Types Apache
require valid-user
</Directory>
Did you check if any other auth_ mods are enabled at the same time like I suggested?
Here's a bit about that from USAGE.gz in the doc dir:
Disable other Auth methods
For some reason Apache has problems handing over authority to this
module if this is requested an another auth module is also loaded.
If you have another authentication module loaded, you'll have to
disable it the hard way.
AuthBasicAuthoritative Off
AuthUserFile /dev/null
The following option is not sufficient
Auth_MySQL_Authoritative On
If you experience similar problems with group membership, try
repeating the same procedure with AuthGroupFile.
===
It may be worth contacting the CentOS package maintainer for help or simply doing a Google and see if anything has got this combo of mod and AES working.
Good luck!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks IMRANC. I'm on another tack that looks promising at the moment.
My goal was to satisfy an itch: "How can mod_auth_mysql" check the unencrypted ID against the encrypted ID in the database *without* knowing the AES key?" I don't think AES uses a public/private key strategy.
I dug into the source and at the moment I suspect that at least one of the directives is dual purpose and quite misleading. Testing that hypothesis will have to wait because it also looks like the 3.0.0 build for at least CENTOS no longer automatically applies the "AES" compiler time option as suggested in the news section and an earlier response to a help inquiry.
My goal at the moment is to get mod_auth_mysql recompiled with the suitable options. That entails figuring out what options are part of the default CENTOS build - something that's not immediately obvious at the moment.
More as it happens,
Aza
I also suspec that at least one of the directives is a
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
YUPAPA suggested recompiling with the AES option. That's precisely what I've been trying to do - to no avail so far.
The mod_auth_mysql tar consists of configuration instructions, build instructions, a list of changes and one "C" source file. No "make" file or any single itemization of compiler directives. OK, it's hack time.
A review of the code shows two relavent compile time options "AES" and "APACHE2". The build instructions mention that it may be necessary to explicitly identify the path to the MySQL headers and libraries - and that one may have to hunt for my_aes.h and rijndael.h files. Furthermore, the Apache crypt.h file was thought to have been superceeded by unistd.h. The compile time option -DCRYPT would force the use of crypt.h instead of unistd.h.
I opened a fresh subdirectory, stuffed the "mod_auth_mysql.c" source in the directory. With my fresh subdirectory as the current directory I launched:
"apxs -c -DAES -L/usr/lib/mysql/ -I/usr/include/mysql -lmysqlclient -lm -lz mod_auth_mysql.c"
After hauling down the missing my_aes.h and rijndael.h files, the gist of a page of error messages seems to be that "APR_XtOffsetOf" can't be found. Wonderful. Where the heck is that ? (BTW, it's not mentioned in crypt.h or unistd.h.)
The mixed case suggests it's a Macro somewhere. The "APR" suggests it's part of Apache but where?
Thinking it might be a version thing, since I'm running Apache2, I dialed in "-DAPACHE2" causing the compiler to point out that it already was compiling for Apache2.
Does anyone here have a notion where "APR_XtOffsetOf" is defined or implemented?
Regards,
Aza
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, it turns out that RPM or YUM installations of mod_auth_mysql 3.0.0 do *NOT* incorporate AES support (contrary to the "news" statements elsewhere on this site). Each installation errors with "mysql invalid encryption method aes" when a sign-in is attempted.
MySQL AES_ENCRYPT and AES_ENCRYPT are working fine. This indicates that the MySQL AES support is in place and working.
Manually compiling and installing mod_auth_mysql is possible, but it looks like one has to hack the "C" code to use APR_OFFSETOF instead of APR_XtOffsetOf. The compile and install from that point forward are uneventful.
Unfortunately, the compile and install wasn't able to link properly with the MySQL lib. Even with an explicit library path my_aes_encrypt() would not link in from the MySQL library. my_aes_encrypt() is the underlieing function used by MySQL's AES_CRYPT which works just fine.
Not that I am somehow the pinnacle of doing installations under CENTOS, but I've reluctantly concluded that mod_auth_mysgl simply can't handle a robust secure password encryption technique like AES. It's fine with plain text and perhaps with some unfortunately more vulnerable encryption techniques, but it can't run with the big dogs any more.
Sad to see such a promising tool begin to fade.
Thanks to all of you for your suggestions and generous help.
Regards,
Aza
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've forgotten exactly why I was trying to use mod_auth_mysql but there's no point in not adding another tool to my repertory.
Incidental to your main point in the article linked to, you observe that search engine 'bots are indeed wandering deeper in websites than one might expect. It suggests that folks are getting more aggressive about gathering resell-able information - and traditional .htaccess security may be more permeable than one would want.
I've also been hearing more war stories about popular MySQL based web design kits getting hacked at the database. I'd written off the web site kit hacks as the result of weak passwords. After all, there is a single administrative point of entry and a brute force script can sit there all day trying various combinations.
But the same thing (single point of entry) can be said for MySQL. It's generally in a default location and has a specific point of entry. BUT, the database is a juicer target because that's where names addresses and account information are.
It just may be that what I've really been hearing about is not script kiddies but a hacker who's thumbing through the raw database and unwinding some of the less securely encrypted passwords.
So I plan to check out your road map for revising and recompiling mod_auth_mysql
Thanks for sharing your thoughts,
Aza
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed it is a blast from the, but I could not help post the solution since mod_auth_mysql itself is not to be blamed for the missing AES encryption module, but rather Fedora rpm package. For the life of me I can not explain why they roll out the rpm with this feature turned off, as it is part of the module.
I stumbled on your article when I recently upgraded my Fedora 14 installation to Fedora 15, and in the process reset my mod_auth_mysql rpm, so suddenly it stopped working. After a while I remember my own article about this same problem and thought I would share it with you. The module mod_auth_mysql is extremely useful and quite flexible and one could go crazy with some funky auth configurations.
I am not sure though if I agree with you 100% about MySQL being the single point of entry. If a hacker attacks MySQL directly through TCP and the default port 3306, then yes I agree with you. On the other hand, anyone opening up MySQL to the world without serious security in place (such restrictions based on IP, etc), is asking for trouble and deserves to be hacked.
If you are talking about traditional LAMP/WAMP/XAMPP stacks, where MySQL is at the bottom of the food chain, you have to take into account Apache, PHP and finally MySQL. Apache like any other software has security holes. PHP suffers from the same problem which is why both products are constantly updated. However, the biggest problem of all comes from our own code which can contain lots of mistakes that let others exploit security breaches.
In the case of own code, in my humble opinion, it is less likely to suffer hacking since it is closed to the outside world. We are the only ones privy to the code. The real danger comes from open source packages such as MantisBT, phpMyAdmin, OSCommerce, Wordpress, etc. Those packages are downloaded by hackers, studied at leisure for badly written code or security exploits, and hacked to death. One then is at the mercy of these packages to release security updates in a timely manner and for our webmasters to update our websites just as quickly.
Finally, with regards to search engines becoming extremely pervasive, I can only comment on Google for now. I think their approach is pretty much ruthless. Their response to me was quite simple, "we index everything", which I find highly offensive and extremely dangerous. I have a personal server that I use for local development, and the sites I develop have to be accessible from the outside, so my clients (or colleagues, or collaborators) can view them. I was shocked to discover the sites were indexed by Google WITHOUT my express permission. And to be honest, I take back my comment about them finding me through DNS, it is wrong. I now suspect they found me through Google Analytics or Google Adsense code. If they have, then I consider this a serious breach of privacy, and I completely reject and refuse to accept the responsibility of blocking search bots. I find it outrageous, but what can I do? They are huge and I am peanuts in comparison.
Anyway, those are my two cents worth…
Cheers,
Michael.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you've put more thought into this than I have, Michael.
My take was rather simplistic. Most of what's out there beating on the server doors for nefarious reasons are reportedly scripts. The popular press (Washington Post in my case) gives me the impression that kids set their computers to work in the morning, go to school, and come home in the evening to see what's now accessible. Ergo the term "Script Kiddies'.
Granted some of the scripts reflect some serious work but not necessarily by the person running the script. The less serious ones simply look for a default "admin" function and try various ID/Password combinations. Those easily identified user portals to a package is what I crudely meant by a "single point of entry". And you are on-point to suggest that when simple steps like renaming, changing ports, non-obvious passwords and so forth are available, folks who get hacked this way have only themselves to blame.
Why the AES encryption module isn't loaded by default is indeed puzzling. AES enjoys a reputation as one of the more robust encryption schemes. Surely a solid encryption scheme would contribute mightily to the positive feelings towards any installation.
As for the outfits harvesting and reselling information about people; I totally agree with your observations, Michael. The whole process seems like the old adage "Garbage in, Gospel out" when we consider how shaky much of the information on the Internet is. That gets pretty dangerous when reputations are involved.
Thanks for your contributions. They are useful and engaging.
Aza
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As of November 27, 2010 I am using CENTOS 5.5 (Linux 2.6.18-194.11.3.el5 kernel), Apache 2.2.3, mySQL 5.0.77, current mod_auth_mysql, current CPAN Crypt::OpenSSL::AES and current Crypt::SaltedHash.
In my configuration mod_auth_mysql works just fine with plain text passwords drawn from the mySQL database when AuthMySQLPwEncryption is set to "none".
However any attempt to use Crypt::OpenSSL::AES encrypted passwords or Crypt::SaltedHash SHA-1 results in a mod_auth_mysql challenge dialog that never admits the correct ID & password.
If I access the SQL file, recover the encrypted password, and use Crypt::OpenSSL::AES to decrypt, I succeed in recovering the correct unadulterated password.
If I access the SQL file, recover the encrypted password, and verify the plain text password using Crypt::SaltedHash, only the correct plain text password verifies.
My httpd.conf for AES encrypted password contains the following:
<Directory /home/capmkt/https/providersonly>
AuthType Basic
AuthName "Providers, please log in:"
AuthMySQLHost localhost
AuthMySQLUser accessCheck
AuthMySQLPassword check
AuthMySQLPwEncryption aes
AuthMySQLSaltField <Hp7YZtVjSAS47kwq>
AuthMySQLDB shows_enrollees
AuthMysqlUserTable accounts
AuthMySQLNameField account
AuthMySQLPasswordField user_passwd
AuthMySQLEnable on
require valid-user
</Directory>
I didn't really know what to do with the AES key so I tried is as the required AuthMySQLSaltField - although it clearly isn't a salt value. Oddly enough I could not find a CPAN Crypt method that would take a salted AES value. The mod_auth_mysql is a tad vague about what should go in the required AuthMySQLSaltField for AES encrypted password.
So the next step was to try the venerable SHA-1. To do so I used CPAN's Crypt::SaltedHash to generate the encrypted password in the mySQL file . In httpd.conf parameters above I deleted AuthMySQLSaltField and changed to "AuthMySQLPwEncryption sha1". The encrypted password could be read and properly validated from the mySQL database using Crypt::SaltedHash's "validate()" method; however, mod_auth_mysql rejected the same password.
I found no errors in the Apache or Perl logs.
Has anyone actually used encryption with mod_auth_mysql? Every example I've seen thus far skirts the encryption issue.
I'd really appreciate knowing what I could use to generate an AES encryption acceptable to mod_auth_mysql and what to do with AuthMySQLSaltField when using AES encryption - which appears to use a key rather than salt. Alternately I'd like to know what Perl method will generate an acceptable salted SHA-1 encrypted password.
Regards,
Aza D. Oberman
Washington, DC USA
With no response here we worked on.
We redid the http.conf settings to dial in an 8 byte salt value. We ran AES_ENCRYPT() and AES_DECRYPT() from the command line and hex looks fine.
Yet any attempt to authenticate via mod_auth_mysql is refused and the now famous "mysql invalid encryption method aes" is generated when an authorization is attempted.
The whole thing works fine provided no encryption is used ("AuthMySQLPwEncryption none").
Any suggestions?
Aza
Hi Aza,
I've only used "Auth_MySQL_Encryption_Types Apache" but it works great.
The only comments I can add are that it seems odd that you're using directives with no underscores. I would double-check those. On Debian Lenny, /usr/share/doc/libapache2-mod-auth-mysql/DIRECTIVES.gz lists their syntax as one of:
Auth_MySQL_* and AuthMySQL_*
eg.
Auth_MySQL_Encryption_Types
I found odd behaviour when auth_basic was also enabled at the same time. Make sure all other auth_ mods are disabled when you test your setup.
Hope that helps,
Imran-UK
Thanks for the suggestion, Imran. Wrong directives certainly would muck up the works and leave me up to my skirts in unintended defaults.
I'm running version 3.0.0 of mod_auth_mysql and not familiar with it's quirks, so your observation sent me scrambling back to the documentation. On this side of the pond http://modauthmysql.sourceforge.net/CONFIGURE presents the "AuthMySQLPwEncryption" encryption directive without under scores ( "_") and makes no mention of "Auth_MySQL_Encryption_Types"!
I also notice that in "Latest News" at http://modauthmysql.sourceforge.net/ the entry for version 2.6.0 touts using "AuthMySQLPwEncryption" in lieu of the previous generation's "AuthMySQLCryptedPasswords," "AuthMySQLScrambledPasswords" and "AuthMySQLMD5Passwords "
Turning to the possibility that I have conflicting settings (which would also muck things up) I looked for mention of Auth_MySQL_Encryption_Types in the on-line documentation but found no mention. The CONFIGURE doc installed on the server (CENTOS/Apache) was also mum on the subject.
Is it possible you are running a different version of mod_auth_mysql? Would you mind sharing your httpd.conf mod_auth_mysql configuration? I've winnowed mine down to:
<Directory /home/capket/public_html/excellersonly>
AuthName "Capket Exceller Area"
AuthType Basic
AuthMySQLHost localhost
AuthMySQLUser shows_exell
AuthMySQLPassword 2exe11
AuthMySQLDB shows_excellers
AuthMySQLUserTable accounts
AuthMySQLNameField account
AuthMySQLPasswordField user_passwd
AuthMySQLGroupField user_group
AuthMySQLPwEncryption aes
AuthMYSQLEnable on
require valid-user
</Directory>
I was using CPAN's Crypt::OpenSSL::AES to encrypt the password and then stuffing the result in a TINYBLOB in MySQL. I'm able to recover and decode the password with no problems but mod_auth_mysql simply rejects any attempt to sign in. I'm now trying the MySQL ENCRYPT_AES function to do the encryption since one AES encription strategy can clearly differ from another in matters of salting and padding.
Again, thanks for your thoughtful suggestions Imran!
Your fellow pilgrim,
Aza
There is clearly something amiss with mod_auth_mysql or it's "documentation" when AES encryption is used.
I set up the database and got mod_auth_mysql working fine with an unencrypted password.
I then used SSH to go to the remote server and open the MySQL monitor and overwrite the plain text password with an AES encrypted one, thusly:
# mysql -h localhost -u root -pPaSSwOrD
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 12
Server version: 5.0.77 Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> use "myDataBase";
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
mysql> UPDATE myTable SET user_passwd=AES_ENCRYPT('caj01','jl7RFtVoSAq47kwq') WHERE account='01cajon';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
I now went to httpd.conf and changed "AuthMySQLPwEncryption none" to "AuthMySQLPwEncryption aes" and rebooted the entire server.
Next came a quick dump of the database and sure enough the plain text password "caj01" had been changed to "z襨ztR@[?գᩧ?/td>
" (not reproducible here in plain text but clearly binary).
Then I fired up my browser (IE) and went to the protected directory on the Web site. The mod_auth_mysgl challenge came up as expected, but try though I might the password was rejected.
So clearly mod_auth_mysql cannot manage AES encryption from a CPAN module or from MySql's own AES_ENCRYPT() - or there is some as yet unclearly documented way to do this.
What's interesting is that thus far *no one* has come forward on this forum, or other forums where I've shared my dilemma, to say they'd succeeded in using mod_auth_mysql with AES encryption. If you've been fortunate enough to have made AES encryption work with mod_auth_mysql would you be so kind as to share two things:
1) Your httpd.conf settings; and,
2) How you encrypted the password.
Regards,
Aza
My version:
$ aptitude show libapache2-mod-auth-mysql
Package: libapache2-mod-auth-mysql
State: installed
Automatically installed: no
Version: 4.3.9-11
Priority: optional
Section: net
Maintainer: Joey Schulze <joey@debian.org>
Uncompressed Size: 119k
Depends: libc6 (>= 2.7-1), libmysqlclient15off (>= 5.0.27-1), apache2.2-common (>= 2.2.3-3)
Description: Apache 2 module for MySQL authentication
A module for the Apache 2 web server which enables HTTP authentication against information stored in a MySQL database.
(although I don't know if this maps to the actual Apache mod version)
A snippet of my config from my non-production server:
<Directory "/var/www/foo">
AuthName "My Login"
AuthType Basic
Auth_MySQL on
Auth_MySQL_Host localhost
Auth_MySQL_User www-data
Auth_MySQL_Password bar
Auth_MySQL_DB mydb
Auth_MySQL_Password_Table user
Auth_MySQL_Username_Field name
Auth_MySQL_Password_Field password
Auth_MySQL_Encryption_Types Apache
require valid-user
</Directory>
Did you check if any other auth_ mods are enabled at the same time like I suggested?
Here's a bit about that from USAGE.gz in the doc dir:
Disable other Auth methods
For some reason Apache has problems handing over authority to this
module if this is requested an another auth module is also loaded.
If you have another authentication module loaded, you'll have to
disable it the hard way.
AuthBasicAuthoritative Off
AuthUserFile /dev/null
The following option is not sufficient
Auth_MySQL_Authoritative On
If you experience similar problems with group membership, try
repeating the same procedure with AuthGroupFile.
===
It may be worth contacting the CentOS package maintainer for help or simply doing a Google and see if anything has got this combo of mod and AES working.
Good luck!
Thanks IMRANC. I'm on another tack that looks promising at the moment.
My goal was to satisfy an itch: "How can mod_auth_mysql" check the unencrypted ID against the encrypted ID in the database *without* knowing the AES key?" I don't think AES uses a public/private key strategy.
I dug into the source and at the moment I suspect that at least one of the directives is dual purpose and quite misleading. Testing that hypothesis will have to wait because it also looks like the 3.0.0 build for at least CENTOS no longer automatically applies the "AES" compiler time option as suggested in the news section and an earlier response to a help inquiry.
My goal at the moment is to get mod_auth_mysql recompiled with the suitable options. That entails figuring out what options are part of the default CENTOS build - something that's not immediately obvious at the moment.
More as it happens,
Aza
I also suspec that at least one of the directives is a
YUPAPA suggested recompiling with the AES option. That's precisely what I've been trying to do - to no avail so far.
The mod_auth_mysql tar consists of configuration instructions, build instructions, a list of changes and one "C" source file. No "make" file or any single itemization of compiler directives. OK, it's hack time.
A review of the code shows two relavent compile time options "AES" and "APACHE2". The build instructions mention that it may be necessary to explicitly identify the path to the MySQL headers and libraries - and that one may have to hunt for my_aes.h and rijndael.h files. Furthermore, the Apache crypt.h file was thought to have been superceeded by unistd.h. The compile time option -DCRYPT would force the use of crypt.h instead of unistd.h.
I opened a fresh subdirectory, stuffed the "mod_auth_mysql.c" source in the directory. With my fresh subdirectory as the current directory I launched:
"apxs -c -DAES -L/usr/lib/mysql/ -I/usr/include/mysql -lmysqlclient -lm -lz mod_auth_mysql.c"
After hauling down the missing my_aes.h and rijndael.h files, the gist of a page of error messages seems to be that "APR_XtOffsetOf" can't be found. Wonderful. Where the heck is that ? (BTW, it's not mentioned in crypt.h or unistd.h.)
The mixed case suggests it's a Macro somewhere. The "APR" suggests it's part of Apache but where?
Thinking it might be a version thing, since I'm running Apache2, I dialed in "-DAPACHE2" causing the compiler to point out that it already was compiling for Apache2.
Does anyone here have a notion where "APR_XtOffsetOf" is defined or implemented?
Regards,
Aza
Well, it turns out that RPM or YUM installations of mod_auth_mysql 3.0.0 do *NOT* incorporate AES support (contrary to the "news" statements elsewhere on this site). Each installation errors with "mysql invalid encryption method aes" when a sign-in is attempted.
MySQL AES_ENCRYPT and AES_ENCRYPT are working fine. This indicates that the MySQL AES support is in place and working.
Manually compiling and installing mod_auth_mysql is possible, but it looks like one has to hack the "C" code to use APR_OFFSETOF instead of APR_XtOffsetOf. The compile and install from that point forward are uneventful.
Unfortunately, the compile and install wasn't able to link properly with the MySQL lib. Even with an explicit library path my_aes_encrypt() would not link in from the MySQL library. my_aes_encrypt() is the underlieing function used by MySQL's AES_CRYPT which works just fine.
Not that I am somehow the pinnacle of doing installations under CENTOS, but I've reluctantly concluded that mod_auth_mysgl simply can't handle a robust secure password encryption technique like AES. It's fine with plain text and perhaps with some unfortunately more vulnerable encryption techniques, but it can't run with the big dogs any more.
Sad to see such a promising tool begin to fade.
Thanks to all of you for your suggestions and generous help.
Regards,
Aza
Hi, please read this article: http://www.xtreme-vision.net/linux/mod_auth_mysql-with-aes-encryption-on-fedora-14-x64. It describes your problem and the solution.
Regards,
Michael.
Wow that's a blast from the past, Michael!
I've forgotten exactly why I was trying to use mod_auth_mysql but there's no point in not adding another tool to my repertory.
Incidental to your main point in the article linked to, you observe that search engine 'bots are indeed wandering deeper in websites than one might expect. It suggests that folks are getting more aggressive about gathering resell-able information - and traditional .htaccess security may be more permeable than one would want.
I've also been hearing more war stories about popular MySQL based web design kits getting hacked at the database. I'd written off the web site kit hacks as the result of weak passwords. After all, there is a single administrative point of entry and a brute force script can sit there all day trying various combinations.
But the same thing (single point of entry) can be said for MySQL. It's generally in a default location and has a specific point of entry. BUT, the database is a juicer target because that's where names addresses and account information are.
It just may be that what I've really been hearing about is not script kiddies but a hacker who's thumbing through the raw database and unwinding some of the less securely encrypted passwords.
So I plan to check out your road map for revising and recompiling mod_auth_mysql
Thanks for sharing your thoughts,
Aza
Indeed it is a blast from the, but I could not help post the solution since mod_auth_mysql itself is not to be blamed for the missing AES encryption module, but rather Fedora rpm package. For the life of me I can not explain why they roll out the rpm with this feature turned off, as it is part of the module.
I stumbled on your article when I recently upgraded my Fedora 14 installation to Fedora 15, and in the process reset my mod_auth_mysql rpm, so suddenly it stopped working. After a while I remember my own article about this same problem and thought I would share it with you. The module mod_auth_mysql is extremely useful and quite flexible and one could go crazy with some funky auth configurations.
I am not sure though if I agree with you 100% about MySQL being the single point of entry. If a hacker attacks MySQL directly through TCP and the default port 3306, then yes I agree with you. On the other hand, anyone opening up MySQL to the world without serious security in place (such restrictions based on IP, etc), is asking for trouble and deserves to be hacked.
If you are talking about traditional LAMP/WAMP/XAMPP stacks, where MySQL is at the bottom of the food chain, you have to take into account Apache, PHP and finally MySQL. Apache like any other software has security holes. PHP suffers from the same problem which is why both products are constantly updated. However, the biggest problem of all comes from our own code which can contain lots of mistakes that let others exploit security breaches.
In the case of own code, in my humble opinion, it is less likely to suffer hacking since it is closed to the outside world. We are the only ones privy to the code. The real danger comes from open source packages such as MantisBT, phpMyAdmin, OSCommerce, Wordpress, etc. Those packages are downloaded by hackers, studied at leisure for badly written code or security exploits, and hacked to death. One then is at the mercy of these packages to release security updates in a timely manner and for our webmasters to update our websites just as quickly.
Finally, with regards to search engines becoming extremely pervasive, I can only comment on Google for now. I think their approach is pretty much ruthless. Their response to me was quite simple, "we index everything", which I find highly offensive and extremely dangerous. I have a personal server that I use for local development, and the sites I develop have to be accessible from the outside, so my clients (or colleagues, or collaborators) can view them. I was shocked to discover the sites were indexed by Google WITHOUT my express permission. And to be honest, I take back my comment about them finding me through DNS, it is wrong. I now suspect they found me through Google Analytics or Google Adsense code. If they have, then I consider this a serious breach of privacy, and I completely reject and refuse to accept the responsibility of blocking search bots. I find it outrageous, but what can I do? They are huge and I am peanuts in comparison.
Anyway, those are my two cents worth…
Cheers,
Michael.
I think you've put more thought into this than I have, Michael.
My take was rather simplistic. Most of what's out there beating on the server doors for nefarious reasons are reportedly scripts. The popular press (Washington Post in my case) gives me the impression that kids set their computers to work in the morning, go to school, and come home in the evening to see what's now accessible. Ergo the term "Script Kiddies'.
Granted some of the scripts reflect some serious work but not necessarily by the person running the script. The less serious ones simply look for a default "admin" function and try various ID/Password combinations. Those easily identified user portals to a package is what I crudely meant by a "single point of entry". And you are on-point to suggest that when simple steps like renaming, changing ports, non-obvious passwords and so forth are available, folks who get hacked this way have only themselves to blame.
Why the AES encryption module isn't loaded by default is indeed puzzling. AES enjoys a reputation as one of the more robust encryption schemes. Surely a solid encryption scheme would contribute mightily to the positive feelings towards any installation.
As for the outfits harvesting and reselling information about people; I totally agree with your observations, Michael. The whole process seems like the old adage "Garbage in, Gospel out" when we consider how shaky much of the information on the Internet is. That gets pretty dangerous when reputations are involved.
Thanks for your contributions. They are useful and engaging.
Aza