http://bugs.mysql.com/bug.php?id=70227

If you think that would be useful to you, be sure to let the WB team know.

More Todd and Joro’s area than mine, though I have some input on various aspects of it and always keep my eyes open for issues or opportunities. And I try to inform and clarify.

One good question to ponder from time to time is:”how can we protect the uninformed or unlucky from attacks or issues by default, without also making life unduly hard?”

Well done on moving things in security! I will humbly maintain my position that MySQL is at the moment still weak about security, without invalidating your hard & appreciated work (and I agree on dropping the “very little work done… part”). It’s a thing that has been neglected for years, I think there’s a lot yet to cover.
Great that you are making progress: enforecement of (strong & strongly hashed) passwords is excellent. I will publicly cheer you up on further progress!

I think we made that claim obsolete in 5.6. 🙂 You might find it useful to read these things:

http://www.mysqlperformanceblog.com/2013/08/17/mysql-5-6-security-vs-ease-of-use/

Randomly assigned root password instead of blank, then forced to change that before you can use the account. Seems like quite an improvement.

How about the password validation plugin, described at http://dev.mysql.com/doc/refman/5.6/en/validate-password-plugin.html ?

Or perhaps the SHA-256 authentication plugin for more secure password hashing: http://dev.mysql.com/doc/refman/5.6/en/sha256-authentication-plugin.html ?

And maybe the removal of passwords from logging: http://dev.mysql.com/doc/refman/5.6/en/password-logging.html ?

There’s more, of course. What we’re trying to do is get it more secure by default.

The greater focus on security mostly started to become visible in 5.6 though of course that means the work started a couple of years earlier. Easy enough to miss it if you didn’t look at the security changes in 5.6.

We do still have an education challenge, of course. One part of which is helping people like you to know what we’re doing so you can pass the word on and get more people using the improved security capabilities.

There’s still more to do and Todd has been coming up with some really good more secured by default ideas that I hope to see in 5.7.

This is very interesting! I’ll need to test this with some authentication plugin (or write my own “reject plugin”). If this turns out to work well – it’s a good enough solution for me!

Thanks

I probably wouldn’t usually want to manage most users to user-specific database accounts and that isn’t how Wikipedia does it. But I would want to split read, write and higher permissions by database account, so only the portions of the application code that need the permissions are vulnerable to attacks that might abuse the higher permissions.

In general I agree about topology and I think that most places would be happy with one user name and multiple locations and would choose not to have the same user name being a different person or password when coming from different locations. But I can see that restriction being irritating in a multiple office large environment where it could end up blocking people from using preferred names because of naming conflicts with those in other offices. Probably not enough DBAs for it to matter in most businesses.

I think you’re doing a good job of describing the most common cases and wants. An interesting challenge for us is making that easy while also not blocking the others.

FYI, one can implement host blacklists today:

http://mysqlblog.fivefarmers.com/2013/08/30/implementing-a-host-blacklist-with-mysql-privileges/

Be warned, though: it relies on the behavior that treats the same user as different accounts when the matching host differs. 🙂

Todd