用户帐户表、盐和哈希的第三范式答案

【问题标题】：3rd Normal Form on User Account Table, Salts, and Hashes用户帐户表、盐和哈希的第三范式
【发布时间】：2011-09-05 23:29:04
【问题描述】：

我了解盐、哈希和所有密码的好东西的重要性。我的问题与关系数据库理论有关。

我对第 3 范式的理解是，每个元素都必须提供关于键、整个键的事实，并且只提供键（所以请帮帮我，Codd。感谢维基百科）。所以我在查看我的一些表时，发现了这个。

-- 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 和盐。 IE：哈希->（用户名，盐）。

我看不出拆分这张桌子有什么真正的好处。但我担心可能存在更新异常或我看不到的东西。

【问题讨论】：

+1 表示“所以帮助我科德”

标签： sql database normalization database-theory

【解决方案1】：

“哈希”取决于 player_id 和 salt。 IE：哈希->（用户名，盐）。

这很奇怪。

通常哈希是从盐和密码派生的。

在这种情况下，哈希确实提供了有关特定用户的附加和基本信息，因为密码本身并不存储在任何地方。如果您同时存储了哈希和密码，则哈希在功能上将取决于密码和盐的组合（可能还有用户名）。因此，同时存储哈希和密码将违反 3NF 和使用哈希的整个目的。

如果没有额外输入密码（不存储在任何地方），就不可能从数据库中的任何其他信息计算哈希值。否则，哈希将毫无用处。既然如此，hash 列在功能上不依赖于 DB 中的任何其他数据，并且该表符合 3NF。

如果您的哈希与密码无关，即可以从其他列计算，那么，是的，您不需要将其存储在数据库中。

【讨论】：

密码不存储在此表中，因此根据定义，哈希不能在功能上依赖于密码:-)。我不以明文形式存储密码。当然，哈希的形式是 H(salt, password)。 en.wikipedia.org/wiki/Functional_dependency
在这种情况下，哈希提供有关用户的附加信息，而不是完全依赖于其他列。所以它是 3NF。
用户名+盐哈希值可能用于验证目的。可以搜索哈希列以查找用于电子邮件验证等的匹配项。如果搜索，这是一个很好的优化，但从技术上讲它不是第 3 范式
你的新段落对我来说很有意义。谢谢。

【解决方案2】：

是的，这很正常，不要拆分你的桌子

【讨论】：

【解决方案3】：

请不要拆分表格。该表是第三范式。据我所知，所有列都依赖于 player_id，但需要注意的是 salt 依赖于例如用户名或 player_id。

【讨论】：