為什麼要儲存使用者密碼？
我偶爾會看到一些問題，詢問如何安全地儲存 Web 應用程序的使用者密碼（使用 RDBMS，我不是在談論 Facebook 或 Twitter）。通常的答案是“對密碼加鹽，然後使用 TDES 或 SHA512 等強算法對其進行雜湊處理”。
我的問題是：作為一個 RDBMS 使用者，我為什麼要為密碼儲存問題而煩惱，因為大多數引擎都有內置的身份驗證機制。
例如，如果某個使用者 X 想在我的 Web 應用程序上創建一個帳戶使用者密碼 Y，那麼發出以下查詢是如何出錯的：
CREATE USER X WITH ENCRYPTED PASSWORD Y IN GROUP baseuser;然後在我的應用程序中，使用者可以使用他的憑據打開與數據庫的連接，而我根本不必費心管理密碼。
我看到了這種方法的多個優點：
- 如果 RDBMS 決定需要更改加密算法，我不需要更改任何內容，只需應用安全更新即可；
- 我很容易管理使用者授權。如果將使用者提升為管理員角色，我只需將該使用者添加到相應的組；
- SQL 注入現在毫無意義，因為我管理權限以允許數據庫中的每個使用者準確地允許我想要允許的內容（例如，在像 SO 這樣的論壇中，添加新文章，回复文章，評論和編輯/刪除他自己的問題/答案/評論）；
- 使用者帳戶“匿名”可用於未經身份驗證的連接到我的應用程序；
- 每個使用者都是他提供的數據的所有者。
但在我看到的關於這個主題的幾乎每一個問題上，似乎都有一個普遍的共識，即這不是必須做的事情。我的問題是：為什麼？
注意：第三點是PostgreSQL 中的策略和Microsoft SQL Server 中的安全策略所允許的。我意識到這些概念是新來的，但無論如何，既然它們在這裡，為什麼我描述的技術沒有成為處理使用者帳戶的標準方法？
因為對於許多應用程序，他們不希望單個使用者帳戶連接到數據庫。使用者/密碼/權限/權限都在應用層處理，並且使用一個專用服務帳戶連接到數據庫後端。
作為一名 DBA，我不想在數據庫級別管理一些面向公眾的中型 Web 應用程序的 10,000 個活躍使用者，或者可能是某個突然流行的應用程序的 2+ 百萬使用者。
在非常真實的意義上，這是應用程序開發人員和數據庫開發人員/DBA 之間的哲學差異。
許多/大多數應用程序開發人員不希望將應用程序功能和/或業務規則的主要方面的責任下放到數據庫層。相反，他們將數據庫視為一種簡單地儲存和檢索數據的工具。
在某些情況下，這可能是短視的；許多 RDBMS 確實具有很棒的功能，可以使應用程序開髮變得更加輕鬆（行級安全性、列索引、文件流儲存等）。
但其中一些更酷的功能僅在較新的版本中可用，並且組織並不總是能夠快速升級現有環境（參見2014 年的這張圖表）。
在其他情況下，最好在應用層處理這些事情（不僅僅是為了數據庫平台的可移植性，我坦率地說，我認為這種說法被誇大了）。