Transport Layer Security (TLS, also often referred to as SSL) is an important component of a secure MySQL deployment, but the complexities of properly generating the necessary key material and configuring the server dissuaded many users from completing this task. MySQL Server 5.7 simplifies this task for both Enterprise and Community users. Previous blog posts have detailed the changes supporting Enterprise builds; this blog post will focus on parallel improvements made to MySQL Community builds.
Over the years, MySQL has used three different mechanisms for securing passwords both for storage and for transmission across networks. This blog post aims to provide a brief history of the various mechanisms and highlight reasons to migrate accounts to use the sha256_password mechanism introduced in MySQL Server 5.6. Continue reading Protecting MySQL passwords with sha256_password plugin
Recent changes to support better security by increasing strength of Diffie-Hellman cipher suites from 512-bit to 2048-bit were introduced to MySQL Server 5.7. While this change enhances security, it is an aggressive change in that 2048-bit DH ciphers are not universally supported. This has become a problem specifically for Java users, as only Java 8 JRE (currently) supports DH ciphers greater than 1024 bits. Making the problem more acute, this change was back-ported from MySQL Server 5.7 to the recent 5.6.26 and 5.5.45 releases in response to a community bug report. This blog post will identify affected applications, existing workarounds, and our plans to provide a more permanent solution in upcoming maintenance releases.
Continue reading SSL/TLS Connections to Recent MySQL Servers in Java
A key theme of the MySQL Server 5.7 release is much improved security. Earlier releases of MySQL 5.7 have introduced features supporting this initiative including automatic generation and detection of TLS key material and client-side preference for TLS connections. The recent MySQL 5.7.8 release builds upon this and provides additional monitoring and audit capabilities that make it easy to answer the question, “How secure are my client connections?”
Today, oCERT published advisory 2015-003 describing a TLS vulnerability in MySQL and derivative products. The content isn’t exactly news – it is documented legacy behavior and the subject of an earlier blog post describing how MySQL Server 5.7 solves the problem. That said, the efforts of Duo Security are certainly appreciated and welcomed – it provides a meaningful context to discuss how to properly harden existing MySQL 5.5 and 5.6 deployments, as well as frame a discussion on potential changes in these versions to increase security.
I’ve written previously about use cases where having accounts which cannot be used to establish client connections are useful. There are various hacks to accomplish this with legacy versions (insert invalid password hash into
mysql.user table, etc.), and we introduced the
mysql_no_login authentication plugin for this very purpose. Now as of MySQL 5.7.6, account locking gets native support through the
ACCOUNT LOCK clause of
CREATE USER and
ALTER USER commands. This post revisits the use cases which drove this feature and the implementation details.
Continue reading Locking accounts in MySQL 5.7
Complimenting the expanded
CREATE USER syntax introduced in MySQL Server 5.7.6 is more useful
ALTER USER syntax. Before MySQL Server 5.7.6,
ALTER USER could only be used to expire a user’s password. That’s pretty limited. With changes made in MySQL Server 5.7.6, a better distinction is made between privilege-level attributes (those which are managed via
REVOKE statements) and account-level attributes (those managed using
CREATE USER and
ALTER USER statements). MySQL has a long history of confusing these – for example, requiring a
GRANT command to set account resource limits or require SSL. This all changes for the better in MySQL Server 5.7 – here’s how: Continue reading Improved ALTER USER syntax support in 5.7
Prior to MySQL 5.7, the
CREATE USER command had a number of limitations:
- No way to set both authentication plugin and password
- No way to disable a user
- No way to define user resource limitations
- No way to set a non-default password expiration policy
- No way to require SSL/x509
All of these things could be done through other means, but typically involved other statements, such as
GRANT commands. Starting with MySQL 5.7.6, these can all be done through a new and improved
CREATE USER syntax: