# 53.3.SASL认证
SASL是面向连接协议中的身份验证框架。目前,PostgreSQL实现了两种SASL身份验证机制:SCRAM-SHA-256和SCRAM-SHA-256-PLUS。未来可能会增加更多。以下步骤说明了SASL认证的一般执行方式,而下一小节给出了有关SCRAM-SHA-256和SCRAM-SHA-256-PLUS的更多详细信息。
SASL身份验证消息流
要开始SASL身份验证交换,服务器将发送AuthenticationSASL消息。它包括服务器可以接受的SASL身份验证机制列表,按照服务器的首选顺序排列。
客户机从列表中选择一种受支持的机制,并向服务器发送SASLInitialResponse消息。该消息包括所选机制的名称,以及可选的初始客户端响应(如果所选机制使用该响应)。
随后将出现一条或多条服务器质询和客户端响应消息。每个服务器质询都会在一条AuthenticationsAllContinue消息中发送,然后客户端会在一条SASLResponse消息中做出响应。消息的细节是特定于机制的。
最后,当身份验证交换成功完成时,服务器会发送一条AuthenticationsAlfinal消息,然后立即发送一条AuthenticationOk消息。AuthenticationsAlfinal包含额外的服务器到客户端数据,其内容特定于所选的身份验证机制。如果身份验证机制不使用完成时发送的其他数据,则不会发送AuthenticationsAlfinal消息。
出现错误时,服务器可以在任何阶段中止身份验证,并发送错误消息。
# 53.3.1.SCRAM-SHA-256身份验证
目前实施的SASL机制如下:紧急停堆-SHA-256
以及它与通道结合的变体紧急停堆-SHA-256-PLUS
.详细描述见RFC 7677 (opens new window)和RFC 5802 (opens new window).
当在PostgreSQL中使用SCRAM-SHA-256时,服务器将忽略客户端在客户端第一条消息
。将使用启动消息中已发送的用户名。PostgreSQL支持多字符编码,而SCRAM要求用户名使用UTF-8,因此可能无法在UTF-8中表示PostgreSQL用户名。
紧急停堆规范规定密码也在UTF-8中,并由萨斯普雷普算法。然而,PostgreSQL不要求密码使用UTF-8.设置用户密码时,不管实际使用的编码是什么,都会像在UTF-8中一样使用SASLprep进行处理。但是,如果它不是合法的UTF-8字节序列,或者它包含SASLprep算法禁止的UTF-8字节序列,则将在不进行SASLprep处理的情况下使用原始密码,而不是抛出错误。这允许在UTF-8中规范化密码,但仍然允许使用非UTF-8密码,并且不需要系统知道密码的编码。
通道绑定在支持SSL的PostgreSQL版本中受支持。带通道绑定的紧急停堆的SASL机制名称为紧急停堆-SHA-256-PLUS
.PostgreSQL 使用的通道绑定类型是tls-服务器端点
.
在没有通道绑定的 SCRAM 中,服务器选择一个随机数传输给客户端,以与传输的密码哈希中的用户提供的密码混合。虽然这可以防止密码哈希在以后的会话中成功重新传输,但它并不能防止真实服务器和客户端之间的假服务器通过服务器的随机值并成功进行身份验证。
具有通道绑定的 SCRAM 通过将服务器证书的签名混合到传输的密码哈希中来防止这种中间人攻击。虽然假服务器可以重新传输真实服务器的证书,但它无法访问与该证书匹配的私钥,因此无法证明它是所有者,从而导致 SSL 连接失败。
例子
服务器发送 AuthenticationSASL 消息。它包括服务器可以接受的 SASL 身份验证机制列表。这将成为;这将是
SCRAM-SHA-256-PLUS
和SCRAM-SHA-256
如果服务器是用 SSL 支持构建的,或者只是后者。客户端通过发送一个 SASLInitialResponse 消息进行响应,该消息指示所选择的机制,
SCRAM-SHA-256
要么SCRAM-SHA-256-PLUS
.(客户端可以自由选择任何一种机制,但为了更好的安全性,如果它可以支持它应该选择通道绑定变体。)在初始客户端响应字段中,消息包含 SCRAM客户至上的消息
.这客户至上的消息
还包含客户端选择的通道绑定类型。服务器发送一个带有 SCRAM 的 AuthenticationSASLContinue 消息
服务器优先消息
作为内容。客户端发送带有 SCRAM 的 SASLResponse 消息
客户端最终消息
作为内容。服务器发送一个带有 SCRAM 的 AuthenticationSASLFinal 消息
服务器最终消息
,紧随其后的是 AuthenticationOk 消息。