问题标签 [salt]

当我们设置 SaltEnabled 时，Microsoft Enterprise Library 的 HashProvider 中如何生成 salt？

新机器是随机的吗？这是一个神奇的数字吗？

（我知道什么是盐，问题是企业库 HashProvider 中的盐的实际值是多少）

在对用户密码进行加盐和散列处理时，任何加盐显然都会有所帮助。盐应该放多长时间有什么最佳做法吗？我会将盐存储在我的用户表中，因此我希望在存储大小和安全性之间进行最佳权衡。随机的 10 个字符的盐是否足够？还是我需要更长的时间？

我的 Web 应用程序依赖于容器管理的安全性，我想知道是否可以使用加盐密码。据我所知，只需配置 JDBC 或 DataSource Realm 就可以很容易地将摘要密码存储在数据库中，但是无法为这些摘要添加盐。

有什么建议么？

编辑：看来我只需要在提问之前再想一想；-)

只需选择谁在进行摘要计算（客户端或服务器）并相应地配置 Tomcat。

密码盐的“盐”一词是否有意义？

bCrypt 的 javadoc有如何加密密码的代码：

要检查明文密码是否与之前已散列的密码匹配，请使用 checkpw 方法：

这些代码片段暗示我随机生成的盐被扔掉了。是这种情况，还是这只是一个误导性的代码片段？

我想生成一个随机盐值并将其放入应用程序状态。

现在，我正在使用网络场，因此每台机器的应用程序状态会有所不同。我也不想购买分布式的国有农场应用程序。

那么..对此有什么解决方案？我以为我可以在代码或 web.config 文件中对其进行硬编码 .. 但这意味着 eva 使用相同的盐 .. 不是很安全。

有人有什么建议吗？

请记住——我需要一个在所有机器上都相同的唯一键（例如 guid）。也许配置文件是唯一的方法？

我想在客户端的 JS 中使用更高阶的时间值（< 1 分钟分辨率）对散列的用户名和密码（通过 http POST 提交）加盐，以避免将用户名和密码散列作为常量值发送，这可能是用于未经授权的用户（即嗅探器）通过 POST 制造的登录尝试。

这将对传递的哈希的有用性施加短暂的到期。

如果他们检查 JS 并看到它使用了这次的盐，如果他们知道盐是什么，那么破解 MD5 的工作会容易多少？

斯蒂芬

我在理解密码盐的用途时遇到了一些麻烦。据我了解，主要用途是阻止彩虹表攻击。然而，我见过的实现这一点的方法似乎并没有真正让问题变得更难。

我看过许多教程建议将盐用作以下内容：

原因是哈希现在不是映射到原始密码，而是密码和盐的组合。但是说$salt=fooand $password=barand $hash=3858f62230ac3c915f300c664312c63f。现在有彩虹表的人可以反转哈希并提出输入“foobar”。然后他们可以尝试所有密码组合（f、fo、foo、... oobar、obar、bar、ar、ar）。获取密码可能需要几毫秒的时间，但其他时间不多。

我见过的另一个用途是在我的 linux 系统上。在 /etc/shadow 中，散列密码实际上与salt 一起存储。例如，“foo”的盐和“bar”的密码将散列为：$1$foo$te5SBM.7C25fFDu6bIRbX1. 如果黑客能够以某种方式获得此文件，我看不出盐的用途，因为te5SBM.7C25fFDu6bIRbX已知的反向哈希包含“foo”。

感谢任何人都可以对此有所了解。

编辑：感谢您的帮助。总结一下我的理解，盐使散列密码更加复杂，从而使其不太可能存在于预先计算的彩虹表中。我之前误解的是我假设所有哈希都存在彩虹表。

你们都遇到过各种网站，这些网站强制您使用 6 个字符长的密码，必须有 1 个数字，并且必须与“烦人”押韵。

显然有一些遗留的原因，为什么有时这是必要的，但有时这都是为了安全。我发现这很烦人，因为我有一组标准密码，这些密码通常不符合这些特殊规则，所以我必须创建并记住一个新密码。

如果您担心用户密码的复杂程度，似乎在安全方面还有更重要的事情需要担心。如果有人真的可以掌握该密码，那么您显然需要担心更大的问题。在依靠用户担心您的安全之前，请尽自己的一份力量并锁定您的系统端。

我的实际问题是：这些复杂的密码规则有哪些替代方法来降低彩虹表或暴力哈希反向器的风险，而不依赖用户承担记住复杂事物的重任？

一些想法：盐渍，...

我看到“八位字节”这个词出现在关于散列随机数的文献中，它似乎是“字符”的同义词，尽管这些词的使用方式有一种模式。

这使我相信两者之间存在形式上的区别。如果有人能告诉我它是什么，我将不胜感激。

（请不要讲八进制字符代码或八进制（以 8 为基数）数字；我说的是名词'octet'，而不是形容词）

编辑：事实证明，我正在寻找的词是“八位字节”。