关于用户帐户表，盐和哈希的第三范式

我明白盐，哈希以及所有那些用于密码的好东西的重要性。我的问题涉及关系数据库理论。关于用户帐户表，盐和哈希的第三范式

我是第三范式的理解是，每一个元素都必须提供有关的关键，整个键，并没有什么，但关键的事实（所以帮我科德。感谢维基百科）。所以我正在审查我的一些表格，并且我遇到了这个问题。

-- 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

关于用户帐户表，盐和哈希的第三范式

回答

相关问题