MongoDB 6.0起强制禁用SCRAM-SHA-1，仅支持SCRAM-SHA-256；服务端拒绝加载SHA-1用户、不响应SHA-1认证请求，且要求驱动显式声明机制、authSource严格匹配。
MongoDB 6.0 及以后版本不再支持 SCRAM-SHA-1，不是“推荐弃用”，而是直接禁用——服务端拒绝加载任何用该机制创建的用户，连接必然失败。
SCRAM-SHA-1 的哈希强度已不满足基本安全要求
SHA-1 算法在 2017 年已被 Google 官方宣告可被实际碰撞攻击，离线字典爆破其哈希值的成本远低于预期。MongoDB 日志中若出现 Ignoring user : unsupported authentication mechanism，说明该用户凭据是用 SCRAM-SHA-1 存储的，6.0 启动时直接跳过加载。
- 旧用户不能复用：即使用户名密码完全一致，只要原用户是用
SCRAM-SHA-1创建的，就必须重建 - 无法降级协商：客户端即使显式指定
authMechanism=SCRAM-SHA-1，服务端也不会响应，只返回泛泛的Authentication failed - 迭代次数固定为 10000，不可调高，进一步削弱抗暴力能力
SCRAM-SHA-256 是唯一允许的内置认证机制
从 MongoDB 6.0 开始，SCRAM-SHA-256 不是“可选项”，而是强制启用的唯一 SASL 认证机制。它要求：
- 服务端必须执行密码哈希（即密码摘要由服务器完成），避免客户端实现差异引入漏洞
- 默认迭代次数为 4096000，远高于 SHA-1 的 10000，显著增加爆破耗时
- 每个用户拥有独立随机盐值，且每次挑战都带 nonce，杜绝重放和彩虹表攻击
- 驱动必须显式声明机制，例如连接字符串中必须含
&authMechanism=SCRAM-SHA-256
老工具连不上？别改客户端，先看服务端配置
Navicat ≤16.0.17、旧版 mongoshell 连接失败，根本原因不是“客户端不支持”，而是服务端根本不发 SHA-1 挑战——它们压根收不到可解析的响应。
- Navicat 用户若坚持不升级，只能在
mongod.conf中设disableScramSHA256: true并重启，再用mechanisms: ["SCRAM-SHA-1"]重建用户 -
mongosh必须 ≥1.10，或启动时加参数：mongosh --authenticationMechanism SCRAM-SHA-256 - Java 驱动
mongodb-driver-sync必须 ≥4.11，旧版即使加参数也默认 fallback 到 SHA-1
真正容易被忽略的点是：用户重建后，authSource 参数必须与创建用户时所在的数据库严格一致；哪怕你是在 admin 库创建的 root 用户，连接非 admin 库时也得显式写 authSource=admin，否则仍报认证失败。
