PostgreSQL 16：保障CLI级密码安全的SCRAM迭代次数配置建议

迭代次数的核心作用 #

SCRAM-SHA-256的迭代次数本质是增加密码哈希的计算成本：每次迭代都会对哈希值进行重复的哈希运算，次数越多，破解者暴力尝试密码时需要的计算资源和时间就越多，能有效抵御彩虹表、字典攻击这类暴力破解手段。

推荐配置值 #

PostgreSQL默认的4096是官方团队在安全性与性能之间做的平衡选择，绝大多数生产环境直接用默认值就足够。

• 如果你的集群存储高敏感数据、有严格合规要求（比如金融、医疗行业），可以考虑将值提升到8192甚至16384，但必须先做性能验证；
• 若是资源有限的轻量集群（比如个人开发环境、低并发小型应用），4096完全够用，没必要盲目调高。

调整迭代次数的关键权衡 #

• 安全性层面：迭代次数越高，破解门槛指数级上升。比如从4096升到8192，破解者每尝试一个密码的计算量直接翻倍，硬件成本和时间成本都会剧增；
• 性能层面：数据库在验证用户密码（包括应用连接池初始化、重连等场景）时，会消耗CPU完成对应次数的哈希运算。次数越高，单用户登录的CPU占用越高，短连接密集的场景下可能出现登录延迟增加、CPU负载过高的问题。

实操注意事项 #

1. 调整postgresql.conf中的password_encryption = scram-sha-256（确保已开启SCRAM）和scram_iterations = 4096（修改为目标值）后，需要重启数据库生效；
2. 迭代次数是和用户密码哈希绑定的，改配置后已有用户的旧密码还是用原来的迭代次数，只有新设置/重置的密码才会使用新次数，可通过ALTER USER <username> PASSWORD '<new_password>';批量或逐个更新用户密码；
3. 调整前一定要在测试环境模拟生产级并发登录，监控CPU使用率和登录响应时间，避免影响线上业务。

内容的提问来源于stack exchange，提问作者cimply