mysql密码策略和登录失败处理
mysql密码策略和登录失败处理
等保对mysql有两个整改要求：设置密码复杂度策略和登录失败处理功能。记得之前我们没去整改，说版本不支持（用的是5.6.15），当时觉得过等保的分数已经足够了，且有别的事忙，所以就没管。
最近领导叫提前了解等保三级的安全规范，就顺便去做测试。没错，5.6.15版本确实不支持登录失败处理，写入配置文件里无法启动（如下图），但支持设置密码复杂度策略：
总的来说，都需要在配置文件加插件加载的配置，对于网上说的什么“mysql >= 5.6.6 才能设置密码策略”，我觉得大家测试过再下定论比较好，不然还是抱着怀疑态度去看待（5.6.51和5.6.15我都试过了，设置密码策略是可行的）
一、密码复杂度策略
用到这个插件：validate_password 插件
1、编辑配置文件：my.cnf
[mysqld]
...
## 密码复杂度插件
plugin-load-add=validate_password.so
validate-password=force_plus_permanent
2、重启mysql
登录，运行：show variables like 'plugin_dir"；
应该会看到插件目录：
也能看到插件相关参数（没加到配置文件前是空的）：
默认值刚好是等保建议的设置值
mysql> show variables like 'validate_password%';
字段说明：
（1）validate_password_check_user_name：默认关闭，设置为ON时可以将密码设置成当前用户名
（2）validate_password_dictionary_file：插件用于验证密码强度的字典文件路径。
（3）validate_password_length：密码最小长度。
（4）validate_password_mixed_case_count：密码至少要包含的小写字母个数和大写字母个数。
（5）validate_password_number_count：密码至少要包含的数字个数。
（6）validate_password_special_char_count：密码至少要包含的特殊字符数。
（7）validate_password_policy： validate_password强制执行的密码策略
validate_password_policy的值可以使用数值0、1、2或相应的符号值LOW、MEDIUM、STRONG来指定。
0/LOW：只检查长度。对于长度测试，所需的长度是validate_password_length系统变量的值
1/MEDIUM：检查长度、数字、大小写、特殊字符。
2/STRONG：检查长度、数字、大小写、特殊字符字典文件。
3、测试：
密码不符合要求的：1234ha、123456789、1235%AAAAK
（授权的时候会报错：不符合当前的策略要求）
密码符合要求：1235%AAAAk
grant all privileges on db_20220311.* to "test"@"localhost" identified by 'xxx';
二、登录失败处理
参考：
https://www.cnblogs.com/zhenxing/p/11050823.html
里面文章提到mysql >= 5.7.17 以后提供了Connection-Control插件，用来控制客户端在登录操作连续失败一定次数后的响应的延迟，我用5.6.51的mysql也是支持的，不过做测试的时候，用“show processlist”查看数据库线程的时候，Time这个字段会为空，而5.7.28的这个字段是有值的。
按照参考文档设置就好了。假设我设置的参数如下：
mysql> SET GLOBAL connection_control_failed_connections_threshold = 5; ## 失败尝试次数为：5次 mysql> SET GLOBAL connection_control_min_connection_delay = 20000; ## 单位默认为毫秒, 设置为：20秒 mysql> SET GLOBAL connection_control_max_connection_delay = 30000; ## 单位默认为毫秒，设置为：30秒
字段说明：
（1）connection_control_failed_connections_threshold：
失败尝试的次数，默认为3，表示当连接失败3次后启用连接控制，0表示不开启（这个我持保留意见，暂时没测试过）
（2）connection_control_min_connection_delay：失败上限之后再次尝试登录前，最小延迟(以毫秒为单位)。
（3）connection_control_max_connection_delay：失败上限之后再次尝试登录前，最大延迟(以毫秒为单位)
我特意讲下参考链接2的测试过程：
未登录前或正常登录（密码输入正确），运行命令返回为空：select * from information_schema.connection_control_failed_login_attempts;
然后我开另一个终端模拟爆破份子（输入错误密码），上面截图的终端再次运行命令，这个connection_control_failed_login_attempts相当于一个计数器，如下图：
直到我设置的阈值：5次。第6次开始再过来搞事的时候，一直卡着（只要后续没有输入正确密码，每一次再去试图爆破都会卡着，除非后续有一次输对了，这个计数器会清零，重新统计失败的次数），卡着的时间视乎你设置的：connection_control_min_connection_delay的值。
运行：show processlist;
当Time到达20的时候，就会返回响应，错误提示：
最后引用文章的话：
正常情况下，输错密码是即刻返回错误的，当连续失败次数达到阈值后，再次进行连接尝试，则会延迟响应，具体表现就是一直卡着，到延迟结束后才返回错误。
所以这玩意不能避免被试图爆破的问题，但是一定程度上能缓解，就好像linux系统也无法做到不被暴力破解，但可以通过修改常见账号名、修改ssh默认端口号、设置强密码来加固，不让坏人那么容易猜到。。。
