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

时间:2011-06-01 04:25:31

标签: sql database normalization database-theory

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

我对第三种常规形式的理解是,每个元素都必须提供关于键,整个键以及除键之外的事实(所以请帮助我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:哈希 - > (用户名,盐)。

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

3 个答案:

答案 0 :(得分:1)

  

“哈希”取决于player_id和salt。 IE:哈希 - > (用户名,盐)。

这很奇怪。

通常哈希来自salt和密码

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

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

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

答案 1 :(得分:1)

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

答案 2 :(得分:0)

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