假設您想在客戶端/服務器協(xié)議中實現(xiàn)密碼身份驗證方法。 您將如何做到這一點以及可能出現(xiàn)的問題是什么？ 以下是 PostgreSQL 中如何完成此操作的故事。

password

一開始，PostgreSQL 只有 pg_hba.conf 中現(xiàn)在稱為“password”的方法。 這是你能想象到的最簡單的事情：

1.客戶端對服務器說：“你好，我是 Peter，我想要連接。”

2.服務器回復：“你的密碼是什么？”

3.客戶端提示輸入密碼或從其他地方獲取密碼并響應：“這是‘123456’?！?/p>

4.現(xiàn)在服務器查找實際密碼。 它存儲在系統(tǒng)目錄 pg_authid 列 rolpassword 中。 服務器基本上執(zhí)行 strcmp(pg_authid.rolpassword, “123456”)，如果相等，它會向客戶端說“OK”，會話啟動將繼續(xù)。

這種方法有一些明顯的問題：

?密碼通過網(wǎng)絡線路以明文形式傳輸。 有一些外部方法可以解決這個問題，例如使用 SSL 或其他加密封裝。

?密碼以明文形式存儲在系統(tǒng)目錄中，最終存儲在磁盤上。 這很糟糕，因為它允許數(shù)據(jù)庫和系統(tǒng)管理員看到其他用戶的密碼。 當然，人們不應該重復使用密碼，但事實上人們可能會這樣做。 它還可以允許管理員通過使用密碼以其他用戶身份登錄來繞過審核。 一般來說，存在明文密碼是不好的，因為它最終可能會被復制或意外看到。 最好不要這樣做。

?更微妙的是，密碼以明文形式存在于服務器進程的內(nèi)存中。 為什么這么糟糕？ 因為管理員也可能可以在那里訪問它。 此外，如果服務器核心轉(zhuǎn)儲或交換，明文密碼可能最終會出現(xiàn)在磁盤上的某個位置。 因此，這實際上幾乎與在磁盤存儲中以明文形式保存密碼一樣糟糕。

crypt

于是又嘗試了另一種方法。這是在pg_hba.conf中不再支持的“crypt”認證方式。

1.客戶端再次開始：“你好，我是 Peter，我想連接?！?/p>

2.已配置為使用 crypt 方法的服務器響應：“請告訴我使用鹽（salt）'ab’對你的密碼進行crypt()加密后的值？” 每次連接嘗試都會隨機選擇salt干擾串。

3.客戶端獲取用戶的輸入內(nèi)容并計算 crypt(“123456”, “ab”)然后回復：“這是‘a(chǎn)b01FAX.bQRSU’?！?/p>

4.服務器檢查 crypt(pg_authid.rolpassword, “ab”) 是否等于“ab01FAX.bQRSU”，如果是則回復“OK”。

crypt() 是一個常見且隨時可用的 Unix 函數(shù)，用于進行加密，因此它是在此處使用的明顯選擇。 它解決了以明文形式傳輸密碼的問題，但仍然存在一些現(xiàn)有問題和新問題：

?密碼仍以明文形式保存在系統(tǒng)目錄和存儲中。

?原始 crypt() 使用的加密方法現(xiàn)已過時。 同樣，鹽值長度salt（2 個字節(jié)）也已過時。

?因此，類 Unix 操作系統(tǒng)的不同供應商已擴展了 crypt() 的調(diào)用以使用不同的加密算法，但這是以不兼容的方式完成的。crypt() 只用于加密本地使用的密碼（就像最初的用途一樣）是可以的，但是當您想通過網(wǎng)絡在不同系統(tǒng)之間進行通信時，它就會崩潰。

?crypt() 可能在非 Unix 系統(tǒng)上不可用。 雖然可以提供替代品，但如果需要這樣做的話，就會對使用操作系統(tǒng)中現(xiàn)成的設施的原始前提產(chǎn)生疑問。

md5

到此時，PostgreSQL 已經(jīng)支持 SSL，因此線傳輸過程中的明文問題不再那么重要。 真正讓人煩惱的是系統(tǒng)目錄中的明文密碼。 因此設計了一個新系統(tǒng)，在pg_hba.conf中稱為“md5”。 它的工作原理如下：

1.客戶端：“你好，我是 Peter，我想連接?！?/p>

2.服務器：“請告訴我使用鹽（salt）'abcd’對你的密碼進行MD5哈希后的值？” 同樣，每次連接嘗試時都會隨機選擇鹽。

3.客戶端獲取用戶輸入并計算：md5(md5(“123456” + “peter”) + “abcd”)。 （我在這里使用 + 進行字符串連接。）這里，“123456”是用戶輸入的密碼，“peter”是用戶名，“abcd”是鹽值。 然后客戶端回復：“這是‘301eddd34d997f72bd43ba678e36a5ba’。”

4.服務器檢查 md5(pg_authid.rolpassword + “abcd”) 是否等于“301eddd34d997f72bd43ba678e36a5ba”，如果是則回復“OK”。

那么這方法有什么問題呢？

?現(xiàn)在讀到這里，使用 MD5 顯然是一個危險信號。 哈希方法已過時。

?鹽值salt的長度（4 字節(jié)）也已過時。

?用戶名被用作存儲的哈希密碼的鹽值。 （這是為了確保兩個恰好具有相同密碼的用戶不會具有相同的存儲哈希值。）因此，重命名用戶會使存儲的哈希密碼失效，并且需要分配新密碼。 這可能并不常見，但發(fā)生時仍然很煩人。

?如果有人碰巧從系統(tǒng)目錄（或者可能是備份轉(zhuǎn)儲）中獲取了存儲的哈希密碼的副本，他們可以使用這些密碼進行登錄。您不需要實際的密碼。 例如，在上面的步驟 3 中，客戶端可以在不知道“123456”的情況下只發(fā)送 md5（“我找到的哈希值”+“abcd”）。 （你不能使用庫存 libpq 來做到這一點，但制作一個可以做到這一點的自定義版本對于專門的攻擊者來說并不難。）

這里的教訓是：不要設計自己的加密方法。

scram

因此，所有這些問題都必須重新考慮，目前的解決方案是在 PostgreSQL 10引入的使用公共標準的：SASL（RFC 4422）和 SCRAM（RFC 5802 和 RFC 7677）。

SASL 是一個協(xié)議框架，允許客戶端和服務器協(xié)商身份驗證機制。 這在電子郵件中被廣泛使用：SMTP 或 IMAP 服務器可能提供名稱為 PLAIN、LOGIN、CRAM-MD5 或 DIGEST-MD5 的身份驗證機制，或許還有 SCRAM，盡管這種情況似乎較少見。 PostgreSQL 使用 SASL 的原因主要是因為 SCRAM 是通過 SASL 定義的，因此遵循它是有意義的。 否則 SASL 功能不會向用戶公開。

SCRAM 是一種身份驗證機制。 它實際上是一組身份驗證機制，具有不同的可能的哈希算法。 當最初考慮在 PostgreSQL 中實現(xiàn) SCRAM 時，大多數(shù)以前的 SCRAM 使用都采用 SHA-1，但它已經(jīng)過時了，并且在撰寫本文時也已被棄用，就像 MD5 一樣。 所以PostgreSQL目前使用的算法是SHA-256，認證方式的全稱是SCRAM-SHA-256。

整個過程大致如下，傳輸過程中的數(shù)據(jù)格式如下：

1.客戶端：“你好，我是 Peter，我想連接?！?/p>

2.服務器：“我們將進行 SASL 身份驗證。 選擇以下方法之一：SCRAM-SHA-256”。 （目前只有一種方法，除非提供通道綁定，但為了簡單起見，我在這篇博文中忽略了這一點。）

3.客戶端：“我選擇 SCRAM-SHA-256。 這是第一個 SASL 數(shù)據(jù)：n,n=peter,r=rOprNGfwEbeRWgbNEkqO“。 該數(shù)據(jù)根據(jù) SCRAM 規(guī)范進行組裝并封裝在 SASL 協(xié)議消息中。 這里，“n=”字段包含用戶名，“r=”字段包含base64編碼的隨機字符串。 前面的內(nèi)容與通道綁定有關(guān)，我們在這里忽略它。

4.服務器：“這是一些 SASL 數(shù)據(jù)：r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,s=W22ZaJ0SNY7soEsUEjb6gQ==, i=4096”。 “r=”字段包含客戶端的隨機數(shù)據(jù)以及服務器附加的附加隨機數(shù)據(jù)。 此外，服務器還發(fā)送鹽值 (s=) 和交互計數(shù) (i=)，這是從相關(guān)用戶存儲的密碼中獲取的。

5.客戶端：“這是一些 SASL 數(shù)據(jù)：c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0, p=dHzbZapWIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=”。 “r=”字段與之前相同。 客戶端和服務器只需來回發(fā)送此消息以檢查它們是否仍在與正確的對方進行通信。 “p=”字段是客戶端用戶提供的密碼，然后使用提供的鹽值和迭代計數(shù)以特定方式對其進行哈希處理。 “c=”字段用于通道綁定。

6.服務器現(xiàn)在會根據(jù)本地存儲的數(shù)據(jù)檢查此數(shù)據(jù)。 其詳細內(nèi)容在此省略。 如果滿足，則發(fā)回：“這是最終的 SASL 數(shù)據(jù)：v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=”。 這稱為驗證器，允許客戶端檢查服務器是否確實檢查了密碼，而不僅僅是讓每個人都通過。

7.然后客戶端檢查驗證器，如果滿足條件，則會話可以繼續(xù)進行。

這里涉及很多內(nèi)容。這解決了我們之前討論的所有問題，甚至包括我們還沒有考慮到的一些問題：

?密碼不會以明文形式傳輸?shù)骄W(wǎng)絡中。

?密碼在系統(tǒng)目錄或底層存儲中不是明文形式。

?密碼在服務器進程中永遠不會以明文形式存在。 實際上，明文密碼從未離開客戶端?？蛻舳艘砸欢ǖ姆绞綄ζ溥M行哈希處理，服務器將其與已有的哈希信息進行比較，但服務器永遠不會看到實際的密碼。

?客戶端發(fā)送的任何信息都不能被其他任何人用來登錄，即使整個交換過程被捕獲。 這是因為客戶端和服務器在每次連接嘗試中都使用不同的隨機數(shù)據(jù)。

?每個存儲的密碼都使用不同的鹽值進行哈希處理，因此實際上不存在不同用戶存儲的密碼意外相同的風險。 此外，鹽值與用戶名或用戶的其他屬性無關(guān)。

?鹽長度可以輕松改變。 用戶只需使用不同的鹽值創(chuàng)建新密碼即可。

?可以以系統(tǒng)化的方式將算法添加到此設計中。 請注意，這仍然需要更改軟件，并且不會完全輕松，但至少有一個明確的方法可以做到這一點。

?正如上面第7點提到的，客戶端可以驗證服務器是否確實檢查了密碼。 在客戶端/服務器身份驗證中，我們通常主要考慮服務器試圖阻止未經(jīng)授權(quán)的客戶端連接。 這是因為服務器存儲了未經(jīng)授權(quán)的客戶端可能想要獲取的有價值的數(shù)據(jù)。 但相反的情況也可能發(fā)生：客戶端連接到偽造的服務器并向其發(fā)送服務器不應該獲得的有價值的數(shù)據(jù)。 這樣的服務器會很高興地讓任何碰巧連接的客戶端進入，而不實際檢查密碼。 SCRAM 可以防止這種情況發(fā)生。 顯然，SSL/TLS 是一種更復雜、更完整的解決方案，用于檢查網(wǎng)絡中的節(jié)點是否值得信賴，SCRAM 并不意味著消除這種需要。

這就是 PostgreSQL 現(xiàn)在的情況。

LDAP認證和其他認證方法

PostgreSQL中還有另一組與密碼相關(guān)的認證方法：

?ldap

?radius

?pam

?bsd

對于客戶端和協(xié)議而言，這些方法與明文認證方式“password”是等效的。 唯一的區(qū)別是服務器不會將密碼與 pg_authid 中存儲的密碼進行比較，而是與相應的外部服務進行比較。 例如，LDAP 身份驗證的工作原理如下：

1.客戶端：“你好，我是 Peter，我想連接?！?/p>

2.服務器：“您的密碼是什么？”

3.客戶端：“是‘123456’。”

4.現(xiàn)在服務器向 LDAP 服務器檢查密碼“123456”。 這本身就可能涉及許多細節(jié)。 如果檢查成功，服務器會說“OK”。

因此，這避免了將密碼以明文形式存儲在數(shù)據(jù)庫中，但仍然存在與此方法相關(guān)的所有其他問題。 使用 SSL 進行 PostgreSQL 連接并安全地配置 LDAP 服務器和連接可以緩解許多此類問題，但它不會像 SCRAM 那樣安全。 （另一條建議是，如果目標是在組織范圍內(nèi)建立集中式密碼存儲，則可以考慮使用 Kerberos 而不是 LDAP，但那是另一個話題了。）

總結(jié)

安全和密碼學是很復雜的。通過使用SCRAM，PostgreSQL采用了公認的公共標準，現(xiàn)在處于一個良好的狀態(tài)，并且可以在未來進行適應。

PostgreSQL考試認證中心（簡稱：PGCCC）