Recap

MySQL 8.0 has been released to version 8.0.34 as of now. After a series of version updates, more password enhancement work has been done. Here we will not introduce too much about the enhancement of password functions in MySQL 8.0. , the relevant introduction can be moved to the previous public account article, here are the relevant links:

Article background

This article mainly does some verification and analysis of the usage details of several parameters related to passwords, and shares with you the actual use experience. First, let’s take a look at the syntax structure of the syntax of MySQL version 8.0 CREATE USER.password_option

-- MySQL 8.0（新增了不同维度的密码控制）
password_option: {
PASSWORD EXPIRE [DEFAULT | NEVER | INTERVAL N DAY]
| PASSWORD HISTORY {DEFAULT | N}
| PASSWORD REUSE INTERVAL {DEFAULT | N DAY}
| PASSWORD REQUIRE CURRENT [DEFAULT | OPTIONAL]
| FAILED_LOGIN_ATTEMPTS N
| PASSWORD_LOCK_TIME {N | UNBOUNDED}
}

-- MySQL 5.7（只包含密码过期属性配置）
password_option: {
PASSWORD EXPIRE
| PASSWORD EXPIRE DEFAULT
| PASSWORD EXPIRE NEVER
| PASSWORD EXPIRE INTERVAL N DAY
}

Among them, the first four password attributes of the MySQL version 8.0 CREATE USERsyntax are the first details discussed in this article. The MySQL global parameters and meanings corresponding to their attributes are:

parameter name	default value	Corresponding fields of mysql.user table	meaning
default_password_lifetime	0	password_lifetime	Globally set password validity period
password_history	0	password_reuse_history	Globally set the number of historical passwords that cannot be reused.
password_reuse_interval	0	password_reuse_time	Globally set how long it takes for historical passwords to be reused
password_require_current	OFF	password_require_current	Do you need to provide the current password when changing the password in global settings?

Myth 1

mysql.userThe meaning when the corresponding field of the password-related options in the table is NULL.

Verification process

We set specific values based on these four password attributes. After setting, the configuration is as shown in the figure below.

Create a new user without specifying any user password attribute.

After the user is created, mysql.userthe values displayed in the corresponding fields in the view table are all NULL.

Are the four globally configured properties not taking effect?

If the effect is generated, it should be automatically configured with the corresponding value when creating the user. Understanding based on this logic also leads to another layer of misunderstanding: the newly configured password global attributes are not effective for historically created users.

ALTER USERDo we still need to process existing users separately?

The more I think about this question, the more wrong it becomes. If the global configuration does not take effect when a new user is created, then when will it take effect? Wouldn't it be meaningless? After further checking the official document's description of the meaning of mysql.userthe corresponding field values in the table, I got the answer. The original description is as follows, but the translation is: If these four values are NULL in the table, it does not mean that the configuration has not taken effect, but it means that it inherits the global password policy configuration.

summary

I didn't read the official documents carefully enough and misunderstood the meaning of the NULL value ( the key reason ), but it is indeed easy to step into this "pit". Here is also posted the effective correspondence table of global parameters and single-user attribute configuration for reference.

It is recommended to use PC to view

Myth 2

Although it is described as a misunderstanding here, I actually understand that the document description is incomplete. Let's take a look at the description of the document first. The translation is: You can use these two parameters to control the policy of reusing historical passwords: one is based on the number of times policy, and the other is based on the time policy. It can be configured at the same time, for example: prohibiting the use of the last 6 passwords or passwords set within 365 days. You can see that the two parameters are an OR logic.

Actual verification scenario

scene 1

password_history > 0 and password_reuse_interval = 0

Conclusion: The historical password count control policy is effective and in line with expectations.

Scene 2

password_history = 0 and password_reuse_interval > 0

Conclusion: The historical password time control policy is effective and in line with expectations.

Scene 3

password_history > 0 and password_reuse_interval > 0

Conclusion: The historical password time control policy is effective, but the historical password times control policy is not effective. mysql.password_history will record all passwords within the specified time and cannot be reused.

summary

password_reuse_intervalThe control strategy for time has a higher priority than password_historythe control for times.
- The two do not take effect at the same time. When two parameters are configured at the same time, the more stringent configuration will be used as the effective policy.
Policies essentially have no impact on usage and functionality.

For more technical articles, please visit: https://opensource.actionsky.com/

About SQLE

SQLE from the Axon open source community is a SQL audit tool for database users and managers that supports multi-scenario audits, standardized online processes, native support for MySQL audits and scalable database types.

SQLE get

type	address
Repository	https://github.com/actiontech/sqle
document	https://actiontech.github.io/sqle-docs/
release news	https://github.com/actiontech/sqle/releases
Data audit plug-in development documentation	https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse

Details of MySQL 8.0 new password policy added

Recap

Article background

Myth 1

Verification process

summary

Myth 2

Actual verification scenario

scene 1

Scene 2

Scene 3

summary

About SQLE

SQLE get

Guess you like