The recent release of 5.6.6 includes a new utility, mysql_config_editor, which makes it easier to interact with MySQL clients securely. At the same time, it’s easy to overstate the security benefits of using this new tool, and unfortunately, I think a couple of statements in the release notes and documentation go a step too far (something we’re in the process of correcting). Ronald quoted one of them in his blog:
MySQL now provides a method for storing authentication credentials securely in an option file named .mylogin.cnf.
This enhancement really isn’t about securing passwords at a file-system level. Don’t assume that the encryption used will prevent attackers from getting passwords stored in the .mylogin.cnf file if they have read access to it – it absolutely will not. There are multiple ways to extract the password out of this file, some more complex than others. Don’t make the mistake of believing that the password storage is safe just because the contents are encrypted.
So, if this enhancement isn’t about secure storing of passwords, what is it about? It makes secure access via MySQL client applications easier to use. For example, it helps eliminate the need to include a password as an argument to mysql or other command-line clients:
shell> mysql -hproduction -uroot -pmypass
shell> mysql --login-path=production
(assuming we used mysql_config_editor to set up a “production” configuration)
That’s obviously more secure if somebody can view the running processes – you don’t want to expose your password like that. Of course, you could always just include the -p argument and enter the password interactively (that doesn’t echo it to the screen or display it in any process list. But that doesn’t help with scripts or batch jobs where interactive password entry isn’t an option. So, great – this enhancement helps eliminate the need for including the password where it can’t be entered interactively. Sounds great – but this mechanism has long existed in MySQL through the use of configuration files (and you can have as many different configuration files as you want dedicated to various connections). You can easily put the password under the [client] header, and invoke clients like so:
shell> mysql --defaults-file=~/production.cnf
Again, assuming there’s ~/production.cnf file that has the connection attributes needed defined in the [client] section.
So, if it’s already possible to eliminate passwords for both interactive and batch use cases, why is this needed? The most immediate answer is that this makes it easier to get password storage – when you do it – right. In the above example with the production.cnf file, you have to create that file yourself and ensure that it has appropriate privileges assigned. That’s not the case when you use mysql_config_utility. Quoting from the manual:
The login file must be readable and writable to the current user, and inaccessible to other users. Otherwise, mysql_config_editor ignores it, and the file is not used by client programs, either.
So one of the principal benefits of mysql_config_editor is ease-of-use – you can rely on it to store your password in a file that is not readable by other users. That’s not to say that you could not have done exactly the same thing yourself by setting appropriate file permissions on a .cnf file of your own making, but using the tool eliminates the possibility that it gets overlooked. Note that I believe that this aspect of the feature may not be working properly for Windows at this stage, and I’m in the process of validating and reporting a bug on this.
Now you may be wondering: If the file encryption doesn’t protect against attackers having file system access, what does it protect against? It eliminates a password storage location that might be misused by a user in a fit of urgency. If a user can’t get access (their own) plain-text passwords from .mylogin.cnf, it may throw just one more hurdle preventing passwords from being copied and pasted into other files (which would have the same need for file system restrictions) or command-line parameters. In short, it reduces the possibility that users may unintentionally use their own passwords in an insecure manner.
All that said, the feature does have some nice ease-of-use aspects that aren’t explicitly security-related. For example, you don’t even have to store passwords using the utility, and use it as a collection of all your hard-to-remember server locations, and still enter the password interactively:
shell> bin\mysql_config_editor print --all [slave1] host = some.really.obscure.slave.host [slave2] host = another.really.obscure.slave.host shell> bin\mysql --login-path=slave1 --user=something -p Enter password: ****
The options you specify as client application arguments will overwrite whatever is stored in .mylogin.pass:
shell> bin\mysql --login-path=slave1 --host=localhost --user=root Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 5
So, if you do choose to store passwords in your .mylogin.cnf file, and you use the same password for multiple accounts (look at me advocating security), you can have a single entry that remembers your password, and choose the host as an argument to the client.
This can be a useful enhancement for very specific security requirements and helps make it easier to be more secure in handling passwords as well as connections to multiple servers. At the same time, it should not be confused with a mechanism that prevents attackers from acquiring passwords if they have file-system level access.
2 thoughts on “Understanding mysql_config_editor’s security aspects”
I haven’t looked into this, but the rumor is that the “encryption” is a well-known algorithm that changes letters, but not numbers or symbols. Is that true?
Also, this is silly:
“In short, it reduces the possibility that users may unintentionally use their own passwords in an insecure manner.”
Firstly, copying and pasting a password from one config file to another is absolutely intentional. People do this on purpose, specifically because they want to make a script or something that uses that config file. Secondly, if it’s an easily “decrypted” (if it’s the algorithm I’m thinking of, I know folks that can decrypt in their head!), then people will just decrypt it and copy it, because that’s what they want to do.
Nobody accidentally copies their password to another file.
Hi Sheeri! I believe you may be referring to a comment where the encryption was compared to rot13. The encryption used by mysql_config_editor is NOT rot13 (looking at the resulting file in a text editor will show numbers, symbols, unprintable control characters and letters). It would take a pretty remarkable person to decrypt the file contents in their head. 🙂 Regardless, the point of the comparison remains valid regardless of encryption algorithm used: Nobody should assume that the encryption will prevent malicious users from recovering the password which the file contains.
Copying and pasting is certainly intentional, and so “unintentionally” is probably a bad choice of words. What was meant is that it can help prevent situations where a user might be tempted to ignore security considerations (or isn’t fully security-aware) and take shortcuts that can compromise security. For example, not everybody may consider whether the password used as a command-line argument in a batch file can be viewed by users who can list running processes. I don’t claim that copy/paste from a file is the only way a user can inadvertently reveal their password, but the goal here is to provide a mechanism that makes this less likely and necessary.