我理解盐,哈希和所有密码的好东西的重要性。我的问题涉及关系数据库理论。
我对第三种常规形式的理解是,每个元素都必须提供关于键,整个键以及除键之外的事实(所以请帮助我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:哈希 - > (用户名,盐)。
我看不出拆分这张桌子有什么好处。但我担心可能会出现更新异常或我看不到的事情。
答案 0 :(得分:1)
“哈希”取决于player_id和salt。 IE:哈希 - > (用户名,盐)。
这很奇怪。
通常哈希来自salt和密码。
在这种情况下,哈希确实提供了有关特定用户的其他重要信息,因为密码本身并未存储在任何地方。如果您同时存储了哈希值和密码,则哈希将在功能上依赖于密码和salt(以及用户名)的组合。因此,存储哈希和密码将违反3NF以及使用哈希的整个目的。
如果没有额外的密码输入(不存储在任何地方),就不可能从数据库中的任何其他信息计算哈希值。否则,哈希将是无用的。由于这种情况,哈希列在功能上不依赖于DB中的任何其他数据,并且该表符合3NF。
如果您的哈希与密码无关,即可以从其他列计算,那么,是的,您不需要将其存储在数据库中。
答案 1 :(得分:1)
是的,这是正常的,不要拆分你的表
答案 2 :(得分:0)
请不要拆分表格。此表格为第3范式。据我所知,所有列都依赖于player_id,但需要注意的是盐依赖于例如用户名或player_id。