PostgreSQL数据库安全:密码身份验证策略

发表时间: 2020-12-26 09:22

假设您想在客户机/服务器协议中实现一个密码身份验证方法。你会怎么做,可能会有什么问题?下面是PostgreSQL是如何做到这一点的。

密码

一开始,PostgreSQL在pg_hba.conf中只有现在称为“password”的方法。这是你能想到的最简单的事情:

  • 客户端对服务器说:“你好,我是Peter,我想连接。”
  • 服务器回答:“你的密码是什么?”
  • 客户端提示输入密码,或者从其他地方获取密码,然后回答:“它是‘123456’。”
  • 现在服务器寻找实际的密码。它存储在系统目录pg_authid列rolpassword中。服务器基本上执行strcmp(pg_authid.rolpassword, "123456"),如果它等于,它向客户端说“OK”,会话启动继续。

这种方法存在一些明显的问题:

  • 密码在网络上以明文形式传输。有一些外部方法可以解决这个问题,比如使用SSL或其他加密包装器。
  • 密码以明文形式存储在系统目录中,因此最终存储在磁盘上。这很糟糕,因为它允许数据库和系统管理员查看其他用户的密码。当然,人们不应该重复使用密码,但人们会这样做。它还可以让管理员通过使用其他用户的密码登录来绕过审计。一般来说,使用明文密码是不好的,因为它可能会被复制或被意外发现。最好不要那样做。
  • 更微妙的是,密码以明文形式存在于服务器进程的内存中。这有什么不好呢?同样,管理员也可以在那里访问它。另外,如果服务器核心转储或交换,明文密码可能会保存在磁盘上的某个地方。这和明文密码存储在磁盘上一样糟糕。

crypt

于是,他们又进行了一次尝试。pg_hba.conf中不再支持" crypt "方法:

  • 客户端再次开始,“你好,我是Peter,我想要连接。”
  • 配置为使用crypt方法的服务器回应道:“您的密码crypt()是什么,使用salt ' ab ' ?“每次连接尝试的盐是随机选择的。
  • 客户端得到用户的输入并计算 crypt("123456", "ab"),然后回答:“它是‘ab01FAX.bQRSU’。”
  • 服务器检查crypt(pg_authid.rolpassword, "ab")是否等于“ab01FAX.bQRSU”,如果是,回答“OK”。

crypt()是一种常用的、可随时使用的Unix函数,用于加密,因此它显然是在这里投入使用的候选函数。它修复了在电线上有明文密码的问题,但仍然有一些现有的和新的问题:

  • 密码仍然以明文形式存在于系统目录和存储中。
  • 原来crypt()使用的加密方法现在已经过时了。同样,salt长度(2字节)也过时了。
  • 因此,不同的类unix操作系统供应商扩展了他们的crypt()调用,以使用不同的加密算法,但这是以不兼容的方式实现的。只要crypt()仅用于为本地使用加密密码(就像最初的用途一样),这就没有问题,但当您希望通过不同系统之间的网络进行通信时,它就会中断。
  • crypt()在非unix系统上可能不可用。可以提供一个替代品,但如果这是必需的,那么它就会对使用操作系统中现成的工具的最初前提产生疑问。

md5

此时,PostgreSQL支持SSL,所以线上的明文问题不再那么重要了。真正让人失望的是系统目录中的明文密码。因此设计了一个新的系统,在pg_hba.conf中称为“md5”。它是这样工作的:

  • 客户:“你好,我是彼得,我要连接。”
  • 服务器:“你的md5密码是什么,用的是盐‘abcd’?”同样,每次连接尝试都会随机选择盐值。
  • 客户端获取用户输入并计算:md5(md5("123456" + "peter") + "abcd")。(我在这里使用+字符串连接。)这里,“123456”是用户输入的密码,“peter”是用户名,“abcd”是salt。然后客户机回答:“它是‘301eddd34d997f72bd43ba678e36a5ba’。
  • 服务器检查md5(pg_authid.rolpassword + "abcd")等于" 301eddd34d997f72bd43ba678e36a5ba ",如果是,则回答" OK "。

那么这有什么问题呢?

  • 现在读这篇文章,使用MD5显然是一个危险信号。散列方法过时了。
  • salt长度(4字节)也过时了。
  • 用户名用作存储的散列密码的盐。(这意味着两个恰好拥有相同密码的用户不会有相同的存储散列。)因此,重命名用户会使存储的散列密码失效,并需要分配一个新密码。这可能不常见,但当它发生时仍然令人恼火。
  • 如果某人碰巧从系统编目(或者备份转储)获得了存储的散列密码的副本,他们可以使用这些副本登录。您不需要实际的密码。例如,在上面的步骤3中,客户端可以在不知道“123456”的情况下发送md5(“我找到的哈希”+“abcd”)。(你不能用libpq的普通版本做到这一点,但是对于专门的攻击者来说,定制一个可以做到这一点的版本并不难。)

这里的教训是:不要设计自己的密码。

scram

因此,所有这些都必须重新考虑,目前的解决方案是在PostgreSQL 10中引入的,使用的是公共标准:SASL (RFC 4422)和SCRAM (RFC 5802和RFC 7677)。

SASL是一种协议框架,允许客户机和服务器协商一种身份验证机制。例如,这在电子邮件中广泛使用:SMTP或IMAP服务器可能会提供具有名称的身份验证机制,如PLAIN、LOGIN、CRAM-MD5或DIGEST-MD5,也可能是SCRAM,尽管这种情况似乎比较少见。PostgreSQL使用SASL的原因主要是因为SCRAM是在SASL上定义的,所以遵循它是有意义的。否则,SASL功能不会向用户公开。

SCRAM是一种认证机制。它实际上是一系列身份验证机制,具有不同的散列算法。当人们最初考虑在PostgreSQL中实现SCRAM时,以前对SCRAM的大多数使用都是使用SHA-1,但那时SHA-1已经过时了,在撰写本文时也已弃用,就像MD5一样。因此,PostgreSQL目前使用的算法是SHA-256,认证方法的全名是hyper -SHA-256

整个东西在线上看起来大致是这样的:

  • 客户:“你好,我是彼得,我要接电话。”
  • 服务器:“我们将进行SASL身份验证。选择其中一种方法:SCRAM-SHA-256”。(目前只有一种方法,除非提供了通道绑定,但为了简单起见,我在这篇博文中将忽略它。)
  • 客户:“我选择了SCRAM-SHA-256。这是第一个SASL数据:n,,n=peter,r=rOprNGfwEbeRWgbNEkqO”。该数据根据SCRAM规范进行组装,并包装在SASL协议消息中。这里,“n=”字段包含用户名,“r=”字段包含一个base64编码的随机字符串。最开始的东西与通道绑定有关,这里我们会忽略它。
  • 服务器:“这里是一些SASL数据:r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,s=W22ZaJ0SNY7soEsUEjb6gQ==, i=4096”。“r=”字段包含客户端随机数据和服务器附加的随机数据。此外,服务器发送一个salt (s=)和一个interation count (i=),它们是从所讨论用户的存储密码中获取的。
  • 客户端:“这是一些SASL数据:c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0, p=dHzbZapWIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=”。“r=”字段与前面相同。客户端和服务器只是来回发送这个,以检查他们仍然在与相反的右侧对话。“p=”字段是客户端用户提供的密码,然后使用提供的盐和迭代计数以特定的方式对其进行散列。“c=”字段用于通道绑定。
  • 服务器现在会根据本地存储的数据来检查该数据。这里省略了其中的细节。如果满意,则返回:“这是最终的SASL数据:v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=”。这被称为验证器,它允许客户端检查服务器是否确实检查了密码,而不仅仅是示意每个人通过。
  • 客户机然后检查验证程序,如果验证程序满意,那么会话就可以继续进行。

这里发生了很多事。这解决了我们到目前为止所讨论的所有问题,以及一些我们还没有想到的问题:

  • 密码在网络上不是明文的。
  • 在系统目录或底层存储中,密码不是明文。
  • 该密码在服务器进程中不存在。事实上,明文密码永远不会离开客户端。客户端以某种方式对其进行哈希,服务器将其与已有的哈希信息进行比较,但服务器永远不会看到实际的密码。
  • 客户端发送的任何信息都不能被任何人用于登录,即使整个交换被捕获。这是因为客户机和服务器在每次连接尝试中都使用不同的随机数据。
  • 每个存储的密码都用不同的salt散列,因此实际上不存在存储的密码对不同用户来说是相同的风险。此外,salt是独立于用户名或用户的其他属性的。
  • 盐的长度可以很容易地改变。用户可以用不同的salt创建新密码。
  • 算法可以以一种系统的方式添加到这个设计中。请注意,这仍然需要软件更改,并不是完全没有痛苦的,但至少有一个确定的方法来做它。
  • 正如上面最后一点所提到的,客户机可以验证服务器是否确实检查了密码。在客户机/服务器身份验证中,我们通常主要考虑服务器试图阻止未授权的客户机连接。这里的想法是,服务器拥有未经授权的客户机可能想要获取的有价值的数据。但反过来也可能发生:客户端连接到一个假服务器,并向它发送服务器不应该获得的有价值的数据。这样的服务器只会很高兴地让恰好连接的任何客户机进入,而不需要实际检查密码。紧急行动可以防止这种情况发生。显然,SSL/TLS是检查网络中一个节点是否值得信任的更详细和完整的解决方案,而SCRAM并不意味着消除这种需要。

这就是PostgreSQL现在的情况。

ldap et al.

PostgreSQL中还有另外一组与密码相关的身份验证方法:

  • ldap
  • radius
  • pam
  • bsd

就客户端和协议而言,这些等同于明文认证方法“password”。唯一的区别是服务器不将密码与存储在pg_authid中的密码进行比较,而是与各自的外部服务进行比较。例如,LDAP身份验证是这样工作的:

  • 客户:“你好,我是彼得,我要接电话。”
  • 服务器:你的密码是多少?
  • 客户:“这是‘123456’。”
  • 现在服务器与LDAP服务器检查密码“123456”。这本身就可能涉及很多细节。如果检查成功,服务器说“OK”。

这样就避免了密码以明文形式存储在数据库中,但它仍然存在与此方法相关的所有其他问题。为PostgreSQL连接使用SSL,并配置LDAP服务器和连接安全地缓解了许多问题,但它不会像SCRAM那样防弹。(另一条建议是,如果目标是在组织范围内实现集中的密码存储,则考虑使用Kerberos而不是LDAP,但这完全是另一个主题了。)

结论

安全和密码学很难。有了SCRAM, PostgreSQL使用公认的公共标准,现在处于有利地位,可以在未来适应。

PostgreSQL wiki包含一个驱动程序列表,并显示哪些驱动程序支持SCRAM: https://wiki.postgresql.org/wiki/List_of_drivers.在PostgreSQL 10最初发布两年多之后,现在对它的支持似乎非常普遍。如果你还在使用md5哈希密码,现在绝对是时候升级了。

本文:http://jiagoushi.pro/node/1399

专栏
基于容器和微服务应用的架构设计
作者:首席架构师智库
3币
191人已购
查看

(此处已添加圈子卡片,请到今日头条客户端查看)