问题标签 [salt]

我知道盐将相同的密码散列到不同的值。但是，盐通常与密码一起存储在数据库中。所以假设我是攻击者，这就是我如何使用字典攻击来攻击盐（注意在这个例子中，为了简洁起见，我没有写出 128 位哈希或盐）：

我知道这可以防止黑客使用彩虹表......但似乎并不能防止字典攻击。我想您可以在哈希算法中添加其他内容，但出于安全考虑，我们必须假设攻击方法是已知的。

因此，加盐似乎可以防止黑客找出哪些密码可能是字典密码（多个用户拥有的密码）并防止彩虹攻击......但不能防止字典攻击。

这是正确的分析吗？有什么更好的安全建议吗？

谢谢！

假设您可以自由决定如何将散列密码存储在 DBMS 中。像这样的计划有明显的弱点吗？

要创建存储在 DBMS 中的哈希值，请使用：

• 作为 salt 的一部分对 DBMS 服务器实例唯一的值，
• 而用户名作为盐的第二部分，
• 并使用实际密码创建盐的串联，
• 并使用 SHA-256 算法对整个字符串进行哈希处理，
• 并将结果存储在 DBMS 中。

这意味着任何想要提出冲突的人都必须分别为每个用户名和每个 DBMS 服务器实例单独完成工作。我计划让实际的散列机制保持一定的灵活性，以允许使用仍在研究中的新NIST标准散列算法 ( SHA-3 )。

“DBMS 服务器实例独有的值”不必保密——尽管它不会随便泄露。目的是确保如果有人在不同的 DBMS 服务器实例中使用相同的密码，则记录的哈希值会有所不同。同样，用户名也不会是秘密的——只有正确的密码。

首先是密码，然后是用户名和“唯一值”，或者三个数据源的任何其他排列，会有什么好处吗？或者如何交错字符串？

我是否需要添加（并记录）随机盐值（每个密码）以及上述信息？（优点：用户可以重复使用密码，并且可能仍然会在数据库中记录不同的哈希值。缺点：必须记录盐。我怀疑优点远大于缺点。）

有很多相关的 SO 问题 - 这个列表不太可能是全面的：

• 加密/散列数据库中的纯文本密码
• PHP 密码的安全哈希和盐
• 为哈希隐藏盐的必要性
• 带时间盐的客户端 MD5 哈希
• 简单的密码加密
• 盐生成和开源软件
• 密码哈希：固定长度的二进制字段还是单个字符串字段？

我认为这些问题的答案支持我的算法（尽管如果您只是使用随机盐，那么“每个服务器的唯一值”和用户名组件就不那么重要了）。

如果我在数据库中的表如下所示：

当用户提交（注册）时，我将用户/通行证发送到存储过程。

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

当用户提交（登录）时，我将用户/密码发送到存储过程。

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

你看到这个逻辑里面有什么缺陷吗？

我有一个散列密码数据库，在散列之前没有添加盐。我想在新密码中加盐。显然我不能重新散列现有的。

您将如何迁移到新的哈希系统？

在对数据库存储密码进行哈希处理时，我总是使用正确的每个条目的盐字符串。根据我的需要，将盐存储在散列密码旁边的数据库中始终可以正常工作。

但是，有些人建议将盐与数据库分开存储。他们的论点是，如果数据库被入侵，攻击者仍然可以构建一个彩虹表，考虑到一个特定的盐字符串，以便一次破解一个帐户。如果这个账户有管理员权限，那么他可能甚至不需要破解任何其他人。

从安全角度来看，将盐存放在不同的地方是否值得？考虑在同一台机器上具有服务器代码和数据库的 Web 应用程序。如果盐存储在该机器上的平面文件中，那么如果数据库被破坏，盐文件也将被破坏。

有什么推荐的解决方案吗？

像大多数程序员一样，我不是密码学专家，但我了解基础知识。但是，正如Jeff 的博文中所指出的，一点知识可能是一件危险的事情。考虑到这一点，我了解盐值的用途，但我需要一些帮助来了解如何使用盐值。

我在有关此主题的其他帖子中读到，最好对每个要加密的密码使用随机盐值。如果是这种情况，当我尝试对用户进行身份验证时，如何重现该随机盐值？在这种情况下，我将对用户提供的明文密码进行加密，对其进行加密，并将其与数据库中存储的密码进行比较。创建密码时，我是否将随机盐值与加密密码一起存储在用户记录中？如果黑客拥有完整的用户记录，这是否会使盐值无用？

想知道每次更改密码时盐对于单个给定用户是否唯一是否重要，或者每次重用相同的盐是否不是什么大问题。

我目前每次给定用户更新密码时都会生成一个新的随机字符串作为盐。这样，每次用户有一个新密码时，他们也是一个盐变化。这很容易做到，为什么不呢。

嗯......这就是为什么。我需要存储以前的 X 密码以确保密码不会被重复使用。在过去（我最后一次为此编写代码时），我可以只存储以前的 MD5 哈希值，并将新的哈希值与该列表进行比较。好吧，既然我使用了每次盐都是唯一的加盐哈希，那么这些比较不再可能，因为不再知道以前的盐。

为了使该系统正常工作，我有两个选择：除了最终的哈希值之外，还存储盐的历史记录，或者在每次密码更新时为任何给定用户重复使用相同的盐。这些中的任何一个都可以让我建立可以与历史相提并论的价值观。

后者工作量少，但它是否失去任何力量？从实际的角度来看，我不认为它确实如此。以为我会在这里得到第二个意见。谢谢。

为了保持问题“可回答” - 为任何用户重复使用相同的盐是否会减少可接受的最小保护以保持可搜索的密码历史记录（以防止 pswd 回收）？

我决定使用存储在数据库中的每个用户的 salt 来实现用户登录。salt 以密码为前缀，该密码使用 SHA 散列并存储在数据库中。

过去，当我不使用盐时，我会使用典型的方法来计算使用用户输入的用户名和密码的查询返回的行数。但是，对于每个用户的盐，您需要先获取盐，然后才能将其与存储的密码哈希进行比较。

因此，为了避免有两个查询（1 个用于获取 salt，另一个用于验证输入凭据），我决定根据输入的用户名在单个查询中获取 salt 和散列密码。就像是

然后在服务器端代码（PHP）中，我将盐与输入的密码连接起来，对其进行哈希处理并将其与已从数据库中获取的密码进行比较。

如果不清楚，我想关键的区别在于，在后一种方法中，我在 PHP 中检查凭据，然后在数据库中完成此操作。

这种方法在安全性或其他方面是否有任何缺点

我正在将用户从旧数据库转移到 vBulletin 数据库。

我想要一个脚本来做到这一点，否则它将永远持续下去。

我存储了所有用户的密码，就像 md5(password)

但当然，由于盐等原因，这不适用于 vBulletin。

所以我的代码是这样的：

我将如何更改它以使用 vBulletin - 这样我就可以设置 vBulletin 用户。password字段和 vBulletin 用户。salt正确。请记住，我的 $user[password] 或users. password存储为他们真实的文本密码的 md5 哈希。

谢谢！

这比普通的MD5安全多少？我刚刚开始研究密码安全性。我对 PHP 很陌生。