假设您可以自由决定如何将散列密码存储在DBMS中.像这样的计划有明显的弱点吗？
要创建存储在DBMS中的哈希值,请执行以下操作:
这意味着任何想要发生冲突的人都必须分别为每个用户名和每个DBMS服务器实例单独完成工作.我打算保持实际的哈希机制有点灵活,以允许使用仍在使用的新NIST标准哈希算法(SHA-3).
"DBMS服务器实例独有的值"不一定是秘密的 - 尽管它不会随便泄露.目的是确保如果有人在不同的DBMS服务器实例中使用相同的密码,则记录的哈希值会有所不同.同样,用户名也不是秘密 - 只需要密码.
首先使用密码以及用户名和"唯一值"第二个,或三个数据源的任何其他排列是否有任何优势？或者交错字符串怎么样？
我是否需要添加(并记录)随机盐值(每个密码)以及上述信息？(优点:用户可以重新使用密码,但仍然可能会在数据库中记录不同的哈希值.缺点:必须记录盐.我怀疑其优势远大于缺点.)
有很多相关的SO问题 - 这个列表不太可能是全面的:
我认为这些问题的答案支持我的算法(尽管如果你只是使用随机盐,那么'每个服务器的唯一值'和用户名组件就不那么重要了).
我决定使用存储在数据库中的每用户盐实现用户登录.盐的前缀为密码,密码用SHA进行哈希处理并存储在数据库中.
在过去我没有使用salt时,我会使用典型的方法来计算查询返回的行数,使用用户输入的用户名和密码.但是,对于每用户salt,您需要先获取salt,然后才能将其与存储的密码哈希进行比较.
因此,为了避免有两个查询(1获取盐和另一个验证输入凭据),我决定根据输入的用户名在单个查询中获取salt和散列密码.就像是
SELECT users.salt, users.password
FROM users
WHERE username = ?'
然后在服务器端代码(PHP)中,我将salt与输入的密码连接起来,哈希并将其与已经从数据库中获取的密码进行比较.
如果不清楚,我想关键的区别在于,在后一种方法中,我在数据库中完成此操作之前检查PHP中的凭据.
在安全性或其他方面,这种方法是否有任何缺点