sql - 用户帐户表、盐和哈希的第三范式

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;

问题:这张表是第三范式吗？我的理解是......“哈希”取决于 player_id 和盐。 IE:哈希 -> (用户名，盐)。

我只是看不到拆分此表有任何实际好处。但我担心可能存在更新异常或我看不到的东西。

Answer 1

the "Hash" is dependant on the player_id and the salt. IE: hash -> (username, salt).

这很奇怪。

通常哈希值是从盐和密码中导出的。

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

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

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