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.

Share →

5 Responses to MySQL 5.6 has better command-line password security… or does it?

  1. gkodinovoro says:

    I agree that ideally the passwords should end up in some OS login protected key store (e.g. MacOSX keychain etc). But this would make mysql behave differently on different OSes. Thus we decided to go with a file.

  2. Don’t forget that 5.6 also tries to prevent passwords from being logged to files like the command history and the slow query log.

  3. Todd Farmer says:

    Hi Steve,

    You’re entirely right that the encrypted password stored on disk can be broken (and not with much difficulty, it should be said). That said, I think you’ve overlooked a couple of important security benefits. For starters, the mysql_config_editor program which encrypts the password also applies security best practices to the file security (where it is located and the permissions). Because the password isn’t stored in plain text any longer, it also helps prevent it from being copied and pasted into command-line arguments (which can then be extracted from OS process listing). No, it doesn’t suddenly make passwords safe to store, but it does help by applying best practices for users when storing passwords is a necessity.

    http://mysqlblog.fivefarmers.com/2012/08/16/understanding-mysql_config_editors-security-aspects/

    • Steve Meyers says:

      Those are some great points. You’re absolutely right that ensuring file security is a benefit that I should have included. I also should have stated that my main concern with solutions like this is that people will have a false sense of security, believing that their password is well encrypted.

      • Todd Farmer says:

        Hi Steve,

        I completely share your concern and appreciate your evangelism of smart security practices! I tried to make that same point in my blog post, and I’m glad to see it reinforced here.

Leave a Reply

%d bloggers like this: