Avoiding cleartext passwords for mysql connection
Posted by DataCentric, 02-08-2011, 03:48 PM Hey guys, Any bright ideas on how to better secure stored mysql passwords in config files etc? I could hash it, but I have to keep the secret to put it to cleartext for the mysql connect string, so thats pointless. I'm thinking entire file encryption at this point, but I don't want to buy zend since its only one file I need to encrypt. Has anyone had to tackle this? PHP obfuscaters don't help, it has to be encrypted. Any good open source suggestions? I've seen a few but they are either buggy or no longer updated.
Posted by pmwebster, 02-08-2011, 07:45 PM I've always stashed these a directory up so no one else can read them. So if your site is in /home/user/public_html, I'll have the connect include in /home/user with the tightest permissions possible. You could use the same methodology with with hashing, keeping the secret located privately as well. Short of using zend however, I don't know of any real encryption that works, i've come across the same issue several times. Using what I mentioned above, I've never *knock on wood* had a problem in the past 6-7 years. I'm not sure what the project is, but you can also set mysql with permissions beyond 'all' (which I didn't think of for a while). Most sites really only need a read-only account to one database, where you can protect the backend editor with a different user that has write access. (the 'admin' section of course you can protect with .htaccess).
Posted by DataCentric, 02-08-2011, 09:18 PM Yea, its already using a locked down RO db account, stashed away a few directories etc. I work for a public company, so we have a lot of infosec related restrictions and have audits all the time. Unfortunately, regardless it has to be encrypted. Might have to bight the bullet and buy something.
Posted by prickett233, 02-09-2011, 02:05 AM You would need something like ioncube.com where the config file can be encrypted and only decrypted by PHP scripts that have been signed.
Posted by ImageLogic, 02-09-2011, 10:24 PM I've used mod_auth_sql (open source from Source Forge) that lets you stash the ID, password and even an optional "group" in your MySQL database. mod_auth_sql requires installing mod_perl (also open source) which in itself is a bit of an adventure. However, frequently used Perl scripts do execute noticeably faster because mod_perl does all sorts of tricks like using threads instead of forks and keeping precompiled code around for reuse. If you have lots of legacy Perl code mod_perl is quite capable of bringing out the flaws. Unfortunately, I have a suspicion that mod_auth_sql does not handle encryption or the "documentation" has delicately ommitted a crucial bit of configuration data (I guess that bit of knowledge is someone else's job security ). I've even tried mod_auth_sql's own forum but as yet haven't found a soul who has succeeded in using the robust AES encryption touted in the "documentation". This lack of a functioning encryption method may not be an issue for you if you're not handling money or crucial personal information. If your MySQL database is buried out of common reach, a plain text password may be enough and you'll get all the convenience of having the ID and password be just another bit of stored data. It's a breath of fresh air if you've fought with the limitations and risk of the .htaccess strategy. Hope this is helpful, Aza D. Oberman
Posted by YUPAPA, 02-10-2011, 08:23 AM Are you sure this does what he wants? He would like to hide / hash the plain text password stored in text files. By glancing the name of the module (mod_auth_sql), I am assuming it is something like mod_auth_ldap / mod_auth_cas that implements authentication to the backend (AD / LDAP) rather than encrypting files. I haven't looked into this further, correct me if I am wrong.
Posted by ImageLogic, 02-10-2011, 11:36 AM You make a good point YUPAPA. I inferred that the need for password encryption was because directories needed to be protectected; but, you are absolutely correct that there may be other reasons to store an encrypted bit of data. On the data encryption score I've had good luck loading and using CPAN's Crypt::CBC with Crypt::OpenSSL::AES doing the heavy lifting of encryption and decryption. I picked AES encryption because the standards are promulgated by the US National Institutes for Standards and Testing and have garnered a reputation for being particularly robust. The CBC implementation is particularlly attractive because it manages variable length data rather transparently. Here's the skeleton of a Perl implementation: use Crypt::CBC; use Crypt::OpenSSL::AES; our $cipher = Crypt::CBC->new( -key => 'A16ByteKey', -cipher => 'Crypt::OpenSSL::AES', -salt => '8ByteSalt' ==== Load a TINYBLOB field in a MySQL table with the result of GenerateAESPassword() ==== sub GenerateAESPassword { my $plaintext = shift; chomp($plaintext); $plaintext =~ s/^\s+//; # Strip leading blanks return $cipher->encrypt($plaintext); } ==== Read a TINYBLOB field from a MySQL table and recover the password with RecoverAESPassword() ==== sub RecoverAESPassword { my $userPasswd = shift; my $result = $cipher->decrypt($userPasswd); return $result; } I've used this encryption technique for a wide variety of data that needs to be kept secure. I've used it with a DBI layer on MySQL under CENTOS/Apache. The only big "gotcha" I can think of is that you absolutely, positively, must store the encrypted material in a "BLOB" type field. The data will be binary and the occasional NULL will surely muck up any string oriented handling. The "salt" value is not necessary, its role is as another level of obfuscation -- but there's no such thing as too much data security, so I use it too. I've not done any performance testing, but I'm sure the encryption and decryption takes its fair share of CPU cycles. I hope this is useful in case I'd missed the point earlier. Regards, Aza Last edited by ImageLogic; 02-10-2011 at 11:48 AM. Reason: I wrote "If" instead of "I've" and "enscription" instead of "encryption"