在 PostgreSQL 中trust 和 scram-sha-256 是 pg_hba.conf客户端认证配置文件中用来控制数据库访问权限的两种身份验证方法。它们决定了用户连接数据库时“如何证明自己是自己”。简单概括两者的区别trust 是无条件放行免密scram-sha-256 是加密密码验证最安全。以下是详细的对比和原理解析1. 什么是 trust信任认证含义只要连接请求的来源 IP/Unix Socket 符合 pg_hba.conf 中的规则数据库就会无条件允许该用户登录。验证过程完全跳过密码验证。用户甚至不需要提供密码或提供任意错误密码都能登录。安全性极低。相当于把家门的钥匙直接挂在门把手上。适用场景仅限本地连接local 或 host 127.0.0.1的开发测试环境。数据库服务器处于完全隔离的内网且没有安全风险。绝对不能用于生产环境或任何暴露在网络中的数据库。2. 什么是 scram-sha-256SCRAM-SHA-256 认证含义全称是 Salted Challenge Response Authentication Mechanism with SHA-256。它是 PostgreSQL 目前最安全的默认密码加密认证方式从 PostgreSQL 10 引入PG 14 成为默认。验证过程客户端与服务器之间不直接传输明文密码。具体流程如下客户端发起连接请求。服务器发送一个随机生成的 Salt盐值和迭代次数给客户端。客户端使用 SHA-256 算法将“密码 Salt”混合计算出摘要Digest发送回服务器。服务器用自己存储的加密密钥进行比对。即使网络被监听黑客拿到的也只是动态的加密摘要无法反推出原始密码。安全性极高。防窃听、防重放攻击且加盐后能有效抵御彩虹表撞库。适用场景所有生产环境、公网访问、需要高安全合规的场景。3. 核心区别对比表对比维度trustscram-sha-256是否需要密码❌ 不需要随意输入✅ 必须提供正确密码密码在网络传输不传输因为没有校验不传输明文传输的是加密摘要加盐哈希抗窃听能力❌ 毫无防备✅ 即使被抓包也无法破解密码用户密码存储不检查密码存储内容无关在 pg_authid 表中存储SCRAM-SHA-256$salt$stored_key$server_key性能开销极低几无开销略微高于 Trust有计算哈希的 CPU 开销但现代服务器可忽略安全性⚠️ 致命缺陷任何人都能伪装✅ 工业级安全默认配置倾向仅用于 local 本地测试生产环境绝对首选4. 重要的配置关联password_encryption需要注意的是在 pg_hba.conf 中配置了 scram-sha-256 后PostgreSQL 还依赖一个服务端参数password_encryption来决定存储密码时的算法。如果 pg_hba.conf 要求 scram-sha-256但password_encryption设置为 md5那么当用户执行ALTER USER ... PASSWORD ...时密码仍会以较弱的 MD5 格式存储导致连接失败。正确做法确保 postgresql.conf 中设置password_encryption scram-sha-2565. 它们通常写在哪儿在$PGDATA/pg_hba.conf文件中常见写法如下# 本地连接仅限开发测试—— 可以使用 trustlocalall postgres trust# 本地 IPv4 连接必须走密码—— 必须使用 scram-sha-256hostall all127.0.0.1/32 scram-sha-256# 远程应用连接生产环境—— 强制使用 scram-sha-256hostall app_user192.168.1.0/24 scram-sha-256 建议如果是为了解决连接报错比如no pg_hba.conf entry尽量不要为了省事设置成 trust除非你确定只有你自己能连且极看重方便。安全底线从 PostgreSQL 15 开始官方甚至移除了对明文密码 password 方法的默认推荐全力导向 scram-sha-256。请务必将生产环境数据库的 pg_hba.conf 配置为 scram-sha-256。如果你在运维中需要快速排查可以通过查询pg_hba_file_rules视图来确认当前生效的认证规则SELECT*FROMpg_hba_file_rules;
