PostgreSQL 14和SCRAM認證的改變--應該遷移到SCRAM？

最近，一些PG使用者反饋他們切換到PG14后，遇到了一些連接錯誤。

“FATAL: ?password authentication failed for a user?in the new server?”就是一個有趣的問題。至少在一個案例中，應用程序如下消息令人有點驚訝：

FATAL: Connection to database failed: connection to server at “localhost” (::1), port 5432 failed: fe_sendauth: no password supplied

這些錯誤的原因是，新版本的PG將密碼加密的默認設置改成了SCRAM認證。盡快最后一個似乎與SCRAM沒有之間關系，是的，一些按照腳本識別了，他在尋找“md5”。SCRAM認證在PG中并不是什么新鮮事。從PG10開始就存在，但不影響DBA的日常，因為他不是默認設置。通過顯式更改默認設置，作為可選項。那些選擇使用的人知道如何使用，但PG社區多年來一直不愿將其作為主要方法，因為許多客戶端/應用程序還沒準備好進行SCRAM身份認證。但這在PG14中發生變化。隨著PG9.6不再支持，情況正在發生變化。限制我們希望所有舊的客戶端庫都得到升級。SCRAM認證者成為主要密碼身份認證方法。但是，那些全部不知道的人總會有一天會收到驚喜。本文就是讓那些未了解的人快速理解并解決一些常見的問題。

什么是SCRAM認證？

簡而言之，數據庫客戶端和服務端互相證明和說服對方他們知道密碼，而無需交換密碼和密碼hash。是的，可以按照RFC7677的規定執行加鹽挑戰和響應SCRAM-SHA-256。這種存儲、通信和密碼驗證的方式使得破解密碼變得非常困難。這種方法更能抵抗：字典攻擊、回放攻擊、Stollen hashes。總的來說，破解基于密碼的身份驗證變得非常困難。

隨著時間推移，改變了什么

Channel Binding

身份驗證只是安全通信的一部分。身份驗證后，中間的惡意服務器可能會接管并欺騙客戶端連接。PG11引入了支持channel binding的SCRAM-SHA-256-PLUS。這是為了確保沒有惡意服務器充當真實服務器或進行中間人攻擊。從PG13開始，客戶端可以請求甚至堅持channel binding。例如：

psql?-U?postgres?-h?c76pri?channel_binding=prefer or psql -U postgres -h c76pri channel_binding=require

通道綁定通過SSL/TLS工作，因此SSL/TLS配置對于通道綁定工作是必需的。

配置Password Encryption

md5是PG10之前唯一可用的密碼加密選項，因此PG允許設置指示“需要密碼加密”，默認是md5：

–-Upto?PG?13 postgres=#?set?password_encryption?TO?ON; SET

由于同樣的原因，上述陳述實際上與以下內容相同：

postgres=#?set?password_encryption?TO?MD5; SET

我們甚至可以使用“true”、“1”、“yes”而不是“on”作為等效值。

但是現在我們有多種加密方法，“on”并不能真正表示我們想要的東西。所以從PG14開始，系統期望我們指定加密方法：

postgres=#?set?password_encryption?TO?'scram-sha-256'; SETpostgres=#?set?password_encryption?TO?'md5'; SET

使用“on”、“true”、“yes”的嘗試將被拒絕并出現錯誤：

–-From?PG?14 postgres=#?set?password_encryption?TO?'on'; ERROR:??invalid?value?for?parameter?"password_encryption":?"on" HINT: Available values: md5, scram-sha-256.

因此請檢查您的腳本，并確保沒有啟用老的加密方法。

一些常見問題

1、我的邏輯備份和恢復是否受到影響

（pg_dumpall）邏輯備份和重儲PG的globals不會影響SCRAM認證，相同的密碼在恢復后工作。事實上，回想下SCRAM身份認證對更改更據彈性會很有趣。例如，如果我們重命名USER，舊的md5密碼不再起作用，因為PG生成md5的方式也使用用戶名。

postgres=#?ALTER?USER?jobin1?RENAME?TO?jobin; NOTICE:??MD5?password?cleared?because?of?role?rename ALTER ROLE

NOTICE中表明，pg_authid中的密碼被清除了，因為舊的Hash不再有效。但SCRAM驗證不會出現這種情況，因為我們可以在不影響密碼的情況下重命名用戶：

postgres=#?ALTER?USER?jobin?RENAME?TO?jobin1; ALTER ROLE

2、現有/舊的加密方法（md5）是一個很大的漏洞，有沒有很大的風險？

這種擔心主要來自“MD5”這個名字，這對現代硬件來說太傻了。PG使用md5的方式不同，不僅僅是密碼的hash值，它還考慮用戶名。此外，它在使用服務器提供的隨機鹽準備hash后通過線路進行通信。有效地傳達的內容將與密碼hash不同，因此它不太容易受到攻擊。但容易出現字典攻擊和泄露用戶名密碼hash問題。

3、新的scram認證是否帶來了復雜性？連接是否需要更長時間？

Scram的有線協議非常有效，并且不知道會導致連接時間下降。而且，與服務器端連接管理的其他開銷相比，SCRAM產生的開銷將變得非常微不足道。

4、是否必須使用PG14的SCRAM認證并強制其他用戶賬戶切換到它？

絕對不是，只是更改了默認值。舊的Md5仍然是有效的方法，效果很好。如果訪問PG環境受到了防火墻/hba規則的限制，使用md5的風險已經很小。

5、為什么切換PG14時收到“FATAL: password authentication failed for user”錯誤？

最大可能原因是pg_hba.conf條目。如果我們指定“md5”作為認證方法，PG也將允許SCRAM認證。但反過來是行不通的。當創建PG14環境時，很可能將“scram-sha-256”作為認證方法。在某些PG軟件包中，安裝腳本會自動執行認證，如果認證來自PG客戶端而不是應用程序 ，請檢查驅動版本以及升級的范圍。

6、為什么會收到其他類型的身份認證錯誤？

最有可能的是后置安裝腳本。在許多組織中，使用DevOps工具（Ansible/Chef）甚至shell腳本進行安裝后自定義是一種常規做法。其中許多人將做一系列涉及密碼加密設置為on的的事情；甚至使用sed修改pg_hba.conf。如果它試圖修改不再存在的條目，則預計會失敗。

應該關注什么以及如何做

從自動化/部署腳本、工具、應用程序連接和連接池開始的任何東西都可能會中斷。將此更改延遲到PG14的主要論據之一是，最舊的支持版本9.6即將停止支持。因此，這是檢查您環境以查看是否任何環境具有舊PG庫并指定升級計劃的合適時機。因為舊版本的PG庫無法處理SCRAM。

總之，制定一個好的遷移計劃總是好的，即使它并不緊急。

1）請檢查環境和應用程序驅動以查看他們是否仍在使用舊版本的PG客戶端庫，并在需要時升級，參考：https://wiki.postgresql.org/wiki/List_of_drivers

2）如果現在有環境使用md5，鼓勵用戶切換到SCRAM認證。pg_hba.conf中提到的md5也將適用于PG14的SCRAM和MD5身份認證

3）抓住一切機會測試自動化、連接池、其他基礎架構并將其遷移到SCRAM認證。

通過更改默認的認證方式，PG社區為未來指明了方向。

原文

https://www.percona.com/blog/postgresql-14-and-recent-scram-authentication-changes-should-i-migrate-to-scram/

總結

以上是生活随笔為你收集整理的PostgreSQL 14和SCRAM认证的改变--应该迁移到SCRAM？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。