17370845950

MySQL 8.0+ 原生不支持双重身份验证（2FA），所谓“MySQL 双重身份验证”需通过 LDAP 委托、SSH 隧道或外部网关实现，validate_password 插件仅校验密码强度，非真正 2FA。

MySQL 8.0+ 原生不支持双重身份验证（2FA）

MySQL 服务端本身没有内置 TOTP、短信或硬件密钥类的双重验证机制。所谓“MySQL 双重身份验证”，实际是通过插件或外部网关实现的折中方案，不是在 mysql.user 表里加个字段就能启用的。直接执行 ALTER USER ... REQUIRE SSL AND ... 或设置 authentication_policy 都不能触发第二因子校验。

可用的替代路径：authentication_ldap_sasl + 外部 2FA 网关

如果你已有 LDAP（如 FreeIPA、Active Directory）并启用了其双因素认证（例如 Google Authenticator 绑定到 AD 用户），可让 MySQL 通过 authentication_ldap_sasl 插件委托认证。此时 MySQL 仅负责转发凭证，真正的“密码 + TOTP”校验由 LDAP 服务完成。

• 需安装并启用 authentication_ldap_sasl 插件：

  INSTALL PLUGIN authentication_ldap_sasl SONAME 'authentication_ldap_sasl.so';

• 创建用户时指向 LDAP 域：

  CREATE USER 'alice'@'%' IDENTIFIED WITH authentication_ldap_sasl BY 'uid=alice,cn=users,cn=accounts,dc=example,dc=com';

• MySQL 不缓存、不解析 TOTP，只信任 LDAP 返回的 success 响应

更现实的选择：SSH 隧道 + MySQL 账户最小权限 + 客户端 2FA

多数生产环境采用分层防护：用 SSH 密钥登录跳板机（已配好 google-authenticator），再从该机器连接 MySQL。这样第二因子落在操作系统层，MySQL 本身只需专注账号隔离与权限控制。

• 禁止 MySQL 直连公网，强制走跳板：

  iptables -A INPUT -p tcp --dport 3306 -s 192.168.10.0/24 -j ACCEPT

  （仅放行内网段）
• MySQL 用户禁用密码，只允许证书或 Unix socket 认证：

  CREATE USER 'app'@'localhost' IDENTIFIED WITH caching_sha2_password REQUIRE X509;

• 客户端连接命令必须嵌套在已通过 2FA 的 SSH 会话中，而非在应用代码里硬编码 MySQL 密码

警惕“伪 2FA”配置：validate_password 插件不是双重验证

有人误把 validate_password 插件当 2FA——它只检查密码强度（长度、字符集等），和第二因子完全无关。启用后仍只需一个密码即可登录，攻击者爆破成功一次就全盘沦陷。

• 检查是否被误用：

  SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'validate_password';

• 若返回 ACTIVE，说明只是密码策略生效，不代表有 2FA
• 真正需要第二因子时，必须引入外部系统（PAM、LDAP、ProxySQL 插件或云服务商的 IAM 集成）

MySQL 的权限模型和认证扩展点有限，强行在服务端打补丁容易破坏升级路径。最稳的方式是把 2FA 拆到网络层或系统层，让 MySQL 专注做它擅长的事：基于已认证身份做细粒度授权。