我理解盐、哈希和所有密码的好东西的重要性。我的问题与关系数据库理论有关。
我对第三范式的理解是,每个元素都必须提供关于键的事实,整个键,除了键什么都没有(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:哈希 -> (用户名,盐)。
我只是看不到拆分此表有任何实际好处。但我担心可能存在更新异常或我看不到的东西。
最佳答案
the "Hash" is dependant on the player_id and the salt. IE: hash -> (username, salt).
这很奇怪。
通常哈希值是从盐和密码中导出的。
在这种情况下,哈希确实提供了关于特定用户的额外和基本信息,因为密码本身没有存储在任何地方。如果您同时存储散列和密码,则散列在功能上将取决于密码和盐(可能还有用户名)的组合。因此,同时存储散列和密码将违反 3NF 和使用散列的全部目的。
如果没有额外输入密码(不存储在任何地方),就不可能从数据库中的任何其他信息计算哈希值。否则,散列将毫无用处。既然如此,哈希列在功能上不依赖于数据库中的任何其他数据,并且该表符合 3NF。
如果您的哈希与密码无关,即可以从其他列计算,那么,是的,您不需要将它存储在数据库中。
关于sql - 用户帐户表、盐和哈希的第三范式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/6196262/