GUID好盐吗？是我的注册/登录过程有任何缺陷？

Question

如果数据库中的表格如下:

 userid uniqueidentifier
 username varchar(20)
 password varbinary(max)

当用户提交(注册)时,我将用户/传递发送到存储过程.

存储过程创建一个新的GUID(使用NEWID())然后我使用SQL Server 的HashBytes(sha1)函数根据提供的GUID +密码创建密码然后我将值插入上面的表.

当用户提交(登录)时,我将用户/传递发送到存储过程.

存储过程查找用户名并获取用户ID以将guid +密码的hashbyte(sha1)与密码字段进行比较.

你看到那个逻辑中有任何缺陷吗？

Answer 1

这是非常标准的 - 对于盐来说,guid就可以了.盐点是为了防止彩虹攻击,而且对于每个用户来说几乎任何随机的值(或者即使不是随机的,然后至少是不同的)也可以做到这一点.

Answer 2

如果安全性是首要考虑因素，我宁愿不使用 GUID 作为盐值。

GUID 有不同的“类型”，其中一些比其他的更“随机”。然而，即使是最好的 GUID 类型（从“随机性”角度来看，这将是 V4 类型的 GUID）也并不真正适合加密功能。

来自维基百科有关 GUID 的文章：

V4 GUID 使用后来的算法，它是一个伪随机数。它们的相同位置有一个“4”，例如 {38a52be4-9352-453e-af97-5c3b448652f0}。更具体地说，“data3”位模式在第一种情况下为 0001xxxxxxxxxxxx，在第二种情况下为 0100xxxxxxxxxxxx。WinAPI GUID 生成器的密码分析表明，由于 V4 GUID 的序列是伪随机的，因此在给定初始状态的情况下，我们可以预测函数 UuidCreate 返回的最多 250 000 个 GUID。这就是为什么 GUID 不应该在密码学中使用，例如作为随机密钥。