phpMyAdmin 不加固 MariaDB 认证，仅是客户端界面；真正安全依赖 MariaDB 服务端权限配置与 phpMyAdmin 访问控制配合。auth_type 仅影响 Web 登录方式，MariaDB 始终按 mysql.user 表校验用户。
直接结论：phpMyAdmin 本身不加固 MariaDB 用户认证，它只是个客户端界面；真正起作用的是 MariaDB 服务端的用户权限配置 + phpMyAdmin 的访问控制层配合。单独改 phpMyAdmin 设置（比如 auth_type）不能提升数据库账户安全性。
为什么改 phpMyAdmin 的 auth_type 不等于加固 MariaDB 认证
phpMyAdmin 的 cookie、http、config 这三种 auth_type 只决定「你登录 phpMyAdmin 这个 Web 页面时怎么输密码」，和 MariaDB 实际验证用户的方式完全无关。MariaDB 始终按自己的 mysql.user 表做校验——哪怕你把 phpMyAdmin 设成 config（密码写死在 PHP 文件里），MariaDB 仍会检查该用户是否真有对应权限、密码是否匹配、是否允许从该 host 登录。
常见误操作：
- 把
$cfg['Servers'][$i]['AllowNoPassword'] = true留着，结果任何能访问 phpMyAdmin 的人都能用空密码连 MariaDB - 用
config模式硬编码root@localhost，等于把最高权限账户明文暴露在 Web 目录下 - 以为开了
cookie认证就“安全了”，却没关掉 MariaDB 里root@'%'这种远程通配账户
真正要改的是 MariaDB 的 mysql.user 表和连接策略
加固必须落在 MariaDB 服务端。针对 10.6 版本，关键动作是：
立即学习“PHP免费学习笔记（深入）”；
- 删掉或禁用所有
user为空或 host 为'%'的高权限账户（尤其是root@'%'） - 用
CREATE USER 'admin'@'192.168.1.%' IDENTIFIED BY '强密码';明确限定可登录 IP 段 - 执行
REVOKE ALL PRIVILEGES ON *.* FROM 'admin'@'192.168.1.%'; GRANT SELECT, INSERT ON mydb.* TO 'admin'@'192.168.1.%';遵循最小权限原则 - 运行
FLUSH PRIVILEGES;生效（注意：MariaDB 10.6+ 在多数情况下已自动刷新，但手动执行更稳妥） - 确认
skip-networking=OFF且bind-address没设成0.0.0.0（若只需本地访问，设为127.0.0.1）
phpMyAdmin 能配合做的三件实事
它不能替代 MariaDB 认证，但可以加一层访问过滤和行为约束：
- 在
config.inc.php中强制关闭空密码：$cfg['Servers'][$i]['AllowNoPassword'] = false;（否则用户输空密码也能连） - 用
$cfg['AllowDeny']['rules']限制 phpMyAdmin 入口 IP，例如只放内网：'deny from all', 'allow from 192.168.1.0/24' - 禁用 root 直接登录界面：
$cfg['Servers'][$i]['AllowRoot'] = false;，逼用户用普通权限账号操作
注意：$cfg['blowfish_secret'] 只影响 cookie 加密强度，和 MariaDB 密码安全无关；长度够 32 字节就行，不用追求“更随机”。
容易被忽略的兼容性坑：MariaDB 10.6 默认启用 unix_socket 插件
如果你用的是系统包安装的 MariaDB 10.6（比如麒麟 OS 或 Ubuntu 22.04+），很可能 root@localhost 已绑定 unix_socket 插件——这意味着它不走密码验证，而是靠系统用户身份。此时你在 phpMyAdmin 里填密码根本连不上。
解决方法只有两个：
- 改用系统用户
root登录 phpMyAdmin 所在服务器，再通过本地 socket 连（不推荐暴露给 Web） - 或者显式切换回
mysql_native_password：ALTER USER 'root'@'localhost' IDENTIFIED VIA mysql_native_password USING PASSWORD('你的密码');
这个点不排查，你会一直卡在“用户名密码正确却登录失败”。
