I was intrigued by a post from David Stokes entitled MySQL and Password Security. It discusses some new options for command line password security in MySQL 5.6. First, I want to establish that it doesn’t really provide “security”, but then I’ll explain why that doesn’t matter.
MySQL 5.6 appears to encrypt the password in a binary file. The password information is then read by MySQL clients, decrypted, and passed to the server. But how does it decrypt the password? In order for it to do so reliably, the encryption must use a known key. Anybody who really wanted to recover your plain text password could do so. In the security world, this is known as “security through obscurity”, and is generally not considered a best practice.
In this case, it’s probably the best option of a lot of bad options. Previously, the password was stored in plain text. If it’s encrypted, even with a known key, then at least it requires a little more effort for someone to recover the password. Since this system needs to work with cron jobs and other automated tasks, there needs to be a way to access the password without human intervention.
Security-conscious web developers face a similar problem. It is impossible to have a web process access the database if the web process does not have access to the credentials required. The credentials can be obfuscated, put in “more secure” locations, or even more drastic steps, but the code must still be able to get access to those credentials in their original form.
So even though this is a case of “security through obscurity”, it’s probably the best of the realistic solutions to the problem.