我想討論好主意還是壞主意：
我得到了一個 MySQL 資料庫并創建了一個公用表“用戶”來驗證登錄。
|User|
|user_id|username|password|created_at|
我實作了一個存盤函式和一些觸發器。
首先：
ON BEFORE UPDATE
更改時將生成 SHA256 哈希和鹽password。salt 是由created_at,user_id和一個全域 salt_mod 混合生成的，它存盤在另一個“配置表”中。
因此，當通過普通更新在“密碼”中輸入 123 時，它將產生用戶唯一的密碼和鹽哈希。
接下來我實作了一個存盤函式
checkUserAuth('username', 'password')
回傳：布爾真或假
當然：接收 PLAIN 用戶名和密碼，復制相同的散列邏輯并回傳 bool "true" 或 "false"，這取決于憑據是否正確。
臨：
- 這使得密碼演算法更改的完全同步對于任何連接的應用程式都過時了。
- 應用程式正在使用的資料庫帳戶可以在沒有“用戶名”、“密碼”和“鹽”權限的 SELECT 權限的情況下作業。
- 即使資料庫的用戶帳戶被盜，由于缺少讀取 FUNCTIONS 源代碼和存盤登錄資訊的列的權限，密碼仍然是安全的。我們這里只有一個 EXECUTE 權限。
反對：
- 好吧，如果有人以 root 權限闖入資料庫，那么“如何生成哈希”的源代碼幾乎都會被泄露（幾乎是鹽漬公式）以及所有資訊在一個地方。然而，由于 created_at 日期和 user_id 上的唯一哈希與 global_salt 混合，它仍然很難彩虹表。
上述情況的問題：
Is this a good approach or totally vulnerable in point of data-security?
我的意思是，一方面，資料庫內部的入侵總是一個不應該發生的問題
另一方面，即使應用程式的源代碼被盜或應用程式中的錯誤導致資料庫帳戶被盜，您也無法竊取任何與登錄相關的資料。
root 帳戶當然不能在 localhost/服務器上的其他地方使用。
你怎么看待這件事？
uj5u.com熱心網友回復：
主要弱點是在創建行時以及每次呼叫 checkUserAuth() 函式時都以明文形式傳遞密碼。
這可以被竊聽（除非您確保在應用程式和資料庫之間使用 SSL 連接）并且如果您啟用了查詢日志，它將被寫入查詢日志。它在 processlist 和 performance_schema 陳述句歷史表中也可見。
這是在客戶端進行散列的一個很好的理由，并且在創建行時只發送密碼的加鹽散列。當您進行身份驗證時，從資料庫中獲取加鹽哈希，并根據客戶端中的用戶輸入對其進行驗證。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/424364.html