關於用戶帳戶表，鹽和哈希的第三範式

我明白鹽，哈希以及所有那些用於密碼的好東西的重要性。我的問題涉及關係數據庫理論。關於用戶帳戶表，鹽和哈希的第三範式

我是第三範式的理解是，每一個元素都必須提供有關的關鍵，整個鍵，並沒有什麼，但關鍵的事實（所以幫我科德。感謝維基百科）。所以我正在審查我的一些表格，並且我遇到了這個問題。

-- Users 
CREATE TABLE accounts(
    player_id mediumint NOT NULL AUTO_INCREMENT, -- Surrogate Key 
    username VARCHAR(32) UNIQUE NOT NULL, -- True primary key 
    salt char(29), -- Passwords are stored in bcrypt hash 
    hash char(60), -- Salt + Hash stored 
    created DATETIME, 
    lastlogin DATETIME, 
    PRIMARY KEY (player_id) 
) ENGINE = InnoDB;

問：是這樣的表是第三範式？我的理解是......「哈希」依賴於player_id和salt。 IE：散列 - >（用戶名，鹽）。

我看不出任何實際的好處分手了這個表。但是我擔心有一個可能的更新異常或者我看不到的東西。

來源

2011-06-01 Dragontamer5788

+1「所以幫我科德」 – Thilo 2011-06-01 04:27:15

「哈希」依賴於player_id和salt。 IE：散列 - >（用戶名，鹽）。

這是奇怪的。

一般散列從鹽和密碼的。

在這種情況下，散列確實提供了有關特定用戶的附加和重要的信息，因爲密碼本身不存儲任何地方。如果你同時存儲了散列和密碼，那麼散列在功能上將取決於密碼和鹽（也許是用戶名）的組合。因此存儲散列和密碼將違反3NF和使用散列的全部目的。

它必須是不可能從數據庫中的任何其他信息計算哈希沒有密碼（不存儲）的額外投入。否則，哈希將是無用的。並且既然如此，哈希列在功能上並不依賴於數據庫中的任何其他數據，並且該表符合3NF。

如果您的散列與密碼無關，即可以從其他列計算出來，那麼，是的，您不需要將其存儲在數據庫中。

來源

2011-06-01 04:29:49 Thilo

的密碼不被定義存儲在此表中，因此，哈希不能功能上依賴密碼：-）。我不以明文存儲密碼。當然，哈希形式爲H（鹽，密碼）。 http://en.wikipedia.org/wiki/Functional_dependency – Dragontamer5788 2011-06-01 04:31:48

在這種情況下，哈希提供了有關用戶的附加信息，並且不完全依賴於其他列。所以它是3NF。 – Thilo 2011-06-01 04:34:53

用戶名+ salt哈希可能用於驗證目的。可以搜索哈希列以查找用於電子郵件驗證的匹配項等。如果搜索到匹配項，這是一個很好的優化，但它在技術上並不是第三範式。 – 2011-06-01 04:35:48

請不要拆分表格。此表格是第三種標準格式。據我所見，所有的列都依賴於player_id，並且要注意鹽依賴於例如用戶名或者player_id。

來源

2011-06-01 04:31:53

鹽應該是隨機的 – Thilo 2011-06-01 04:47:18

然後這確實是3NF。 – 2011-06-01 04:52:17

是的，這是正常的，不拆你的臺

來源

2011-06-01 04:41:22 DeveloperX

關於用戶帳戶表，鹽和哈希的第三範式

回答

相關問題