We have all done it in the past, and probably most people that read this (will admit| or lie) to still doing it, but everybody must start making an effort to improving MySQL security in the usage on your MySQL Installation, including just on your laptop, and in presentations that people read.
I spotted a reference article on Planet MySQL this evening and without looking at the details the syntax presented typifies two basic and fundamental 101 MySQL security issues.
1. Always, always, always have a password for a MySQL account, especially for the ‘root’ user.
2. Don’t use the ‘root’ user unless you really have to. The SUPER privilege is just that SUPER, there are many things you really don’t want every person accessing to have. In a larger environment you want to ensure good principles, but also in single developer environment.
I was asked on Thursday at a seminar I was giving. “Our developers login as ‘root’ for development and use ‘root’ for MySQL access, is this bad?”. To which my simple response was “Yes”.
I think MySQL should improve the product and not allow a root user without a password. You can of course use mysql_secure_installation to set this, but it’s not a mandatory step. You can also use SQL_MODE to ensure users can’t be created without a password, in both instances the horse has already bolted.
Yep, mysql security is important, and my “to do” list has had “audit mysql user accounts” on it for several months. But each time I take on this task–who can access what from where–I face the trade-off between security and usability. We get a lot of value/usability out of a passwordless root account accessible only from localhost. If you have local access to a db server via ssh, you get mysql root for free. This works great for our mysql installation, and lets me manage authentication/authorization via PAM and SSH, not mysql.
Effective security requires cost-benefit analysis of the threats you’re protecting against. Adding a mysql root password would cost a lot for our installation without much security benefit.
Yes, and folks should try to use the sakila test database as much as possible. And don’t use SELECT *
It’s a matter of best practices. Also, I can’t imagine that there are blank root passwords in production, and development should mirror production, right? It’s a bad idea to introduce something (like root passwords) in production, where things might fail because they couldn’t be properly tested.