假設您想在客戶機/伺服器協議中實現一個密碼身份驗證方法。你會怎麼做，可能會有什麼問題?下面是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=”。這被稱為驗證器，它允許客戶端檢查伺服器是否確實檢查了密碼，而不僅僅是示意每個人透過。客戶機然後檢查驗證程式，如果驗證程式滿意，那麼會話就可以繼續進行。

這裡發生了很多事。這解決了我們到目前為止所討論的所有問題，以及一些我們還沒有想到的問題:

ldap et al.

PostgreSQL中還有另外一組與密碼相關的身份驗證方法:

ldapradiuspambsd

就客戶端和協議而言，這些等同於明文認證方法“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