Question

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

我对第三种常规形式的理解是，每个元素都必须提供关于键，整个键以及除键之外的事实（所以请帮助我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;

问题：此表是否为第3范式？我的理解是......“哈希”依赖于player_id和salt。 IE：哈希 - ＆gt; （用户名，盐）。

我看不出拆分这张桌子有什么好处。但我担心可能会出现更新异常或我看不到的事情。

Answer 1

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

这很奇怪。

通常哈希来自salt和密码。

在这种情况下，哈希确实提供了有关特定用户的其他重要信息，因为密码本身并未存储在任何地方。如果您同时存储了哈希值和密码，则哈希将在功能上依赖于密码和salt（以及用户名）的组合。因此，存储哈希和密码将违反3NF以及使用哈希的整个目的。

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

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

Answer 2

是的，这是正常的，不要拆分你的表

Answer 3

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

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

3 个答案: