3

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

我对第 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：哈希->（用户名，盐）。

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

4

3 回答 3

1

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

这很奇怪。

通常哈希是从 salt 和password派生的。

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

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

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

于 2011-06-01T04:29:49.670 回答
1

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

于 2011-06-01T04:41:22.103 回答
0

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

于 2011-06-01T04:31:53.323 回答