PostgreSQL – 密码验证方法

有几种基于密码的身份验证方法可用。在 PostgreSQL 中，这些方法的操作方式相同，但用户密码在服务器上的存储方式以及客户端提供的密码通过连接传送的方式不同。方法如下：

密码：

密码方法发送明文密码，因此容易受到“嗅探”攻击。如果可能的话，应该避免。如果连接受 SSL 加密保护，则通常可以安全使用密码。虽然 SSL 证书身份验证可能是一个更好的选择，如果一个人指望使用 SSL。

地穴：

Crypt() 可能是一个常见且现成的 Unix函数，用于尝试加密。 crypt函数接受以下两个参数：

1. 要加密的密码。
2. 加密时要使用的盐。

为了使 PostgreSQL 可供我们使用，我们总是必须使用 gen_salt函数。我们再次使用 crypt 对用户进行身份验证，但这次我们传递了以下参数：

1. 密码已提交。
2. 我们已经在数据库中的加密密码。

如果密码匹配，则 crypt 返回与我们在数据库中已有的相同的值。只要 crypt() 仅用于加密本地密码就很好，就像最初的用法一样，但是当您尝试通过网络在各种系统之间进行通信时会中断。

MD5：

md5 方法对质询-响应采用了不太可靠的机制。它可以防止密码嗅探并防止密码以纯文本形式存储在服务器上，但如果攻击者设法从服务器窃取密码哈希，则不提供保护。此外，MD5 哈希算法目前被认为不能安全地抵御确定的攻击。此外，md5 方法不能与 db_user_namespace 功能一起使用。

急停：

SCRAM 是目前唯一的 SASL 机制。分别在 RFC 7677 和 RFC 5802 中有详细描述。

在 PostgreSQL 中使用 SCRAM-SHA-256 时，服务器会忽略客户端在第一条消息客户端中发送的用户名。而是使用已在启动消息中发送的用户名。 PostgreSQL 提供了多种字符编码，而 SCRAM 指定使用 UTF-8 作为用户名，因此可能无法用 UTF-8 表示 PostgreSQL 用户名。

SCRAM 规范规定密码也是 UTF-8 格式，并使用 SASLprep 算法进行处理。然而，PostgreSQL 不需要使用 UTF-8 作为密码。设置用户密码后，无论使用何种特定编码，都将使用 SASLprep 处理它，就好像它是 UTF-8 一样。但是，如果它不是合法的 UTF-8 字节序列或包含 SASLprep 算法禁止的 UTF-8 字节序列，则可以在不处理 SASLprep 的情况下使用原始密码，而不是出现错误。

LDAP 等：

PostgreSQL 还包含一组与密码相关的身份验证方法：

• LDAP
• 半径
• 帕姆
• bsd

关于客户和协议，这些相当于纯文本认证方法“密码”。唯一的区别是服务器不会将密码与存储在 pg_authid 中的内容进行比较，而是与相应的外部服务进行比较。这可以防止密码以明文形式存储在数据库中，但它仍然存在与此方法相关的所有其他问题。将 SSL 用于 PostgreSQL 连接并安全地配置 LDAP 服务器和连接可以缓解许多此类问题，但它不会像 SCRAM 那样万无一失。

结论：

根据环境的需要，安全性和密码学很困难。但是通过 SCRAM，PostgreSQL 使用公认的公共标准，并且现在处于适应未来的有利位置。