电子邮件地址作为密码盐？答案

【问题标题】：Email address as password salt?电子邮件地址作为密码盐？
【发布时间】：2011-04-16 18:51:12
【问题描述】：

使用电子邮件地址作为salt 的密码是不是一个坏主意？

【问题讨论】：

你们推荐的盐应该是多长？
如果它是唯一使用电子邮件的盐会削弱您的用户安全性，因为使用同一系统的多个网站将可以使用给定用户的相同彩虹表破解。即使用户花时间为每个网站/服务使用一个密码。
对于试图暴力破解所有用户密码的攻击者来说，每一点盐都会使计算量或存储量翻倍。然而，对于已知的 salts（例如登录名），攻击者仅在针对特定用户时才会增加工作量，因为他无法将结果用于具有不同 salt 的用户。
@VirtualBlackFox 但是盐并不是为了保护单个用户免受有针对性的攻击，而是为了保护一大群用户免受同时攻击。
@Tyler 是的，这就是他们的目的。它们保护同一站点的多个用户免受同时攻击。但是它们在网站之间是独立的这一事实也可以保护跨多个网站的一个用户免受同时攻击。失去这个防止另一个攻击向量的属性是一个坏主意，尤其是在计算复杂度相似的情况下。

标签： php passwords salt

【解决方案1】：

为了提高安全性，最好使用随机盐。可以很容易地找到电子邮件地址，从而降低了盐的有效性。（在 cmets 中澄清）

【讨论】：

盐的设计目的是在数据库被入侵时使暴力破解和使用彩虹表变得更加困难......所以我不明白你的意思
盐的设计初衷是让彩虹表无法使用。但是，是的，它也可以阻碍蛮力。虽然对于强密码来说它可以忽略不计。最好算盐已经被破坏了。而且，你知道......说到这些事情，虽然 99% 的应用程序通过网络以纯文本形式发送密码，这很有趣
我也不明白你的意思keyboardP - Salt旨在防止攻击者已经知道salt是什么的攻击。
-1，盐通常与密码一起以明文形式存储。
对不起，我应该更清楚。是的，盐的复杂性是无关紧要的，因为对它的危险访问将假定对数据库的访问。但是，我个人认为应该尽可能地加强安全性。许多网站使用相同的散列技术。现在假设他们都使用电子邮件地址作为盐。构建一个彩虹表，无论花费多长时间，都会有效地破坏多个数据库的安全性。对于琐碎的网站来说可能不太可能，但添加随机盐真的需要更多的工作吗？

【解决方案2】：

编辑：
让我推荐你看这个answer on Security StackExchange，它解释了很多关于密码散列和密钥派生的细节。

底线：使用安全的既定密码散列方案，该方案在某种程度上是资源密集型的，以防止暴力攻击，但限制允许调用的数量以防止拒绝服务 (DoS ) 攻击。

如果您的语言库有它的功能，请在升级时验证它是否能完成它应该做的事情，特别是如果它是 PHP。

下面的答案是历史原因留下的。

您可以使用用户的登录名作为盐，它可能比电子邮件地址更不可能更改（编辑： 0xA3 正确指出，这比使用电子邮件地址，因为登录名往往更容易猜到，并且有些非常常用，因此彩虹表可能已经存在，或者可以用于其他站点）。

或者，有一个数据库列，您可以在其中保存密码的盐。
但是，您也可以使用随机的用户特定盐，这很难猜到。

为了更好的安全性，您可以使用两种盐：一种特定于用户的盐和一种系统范围的盐（连接它们，然后使用密码对盐进行散列）。

顺便说一句，简单的盐和密码连接可能不如使用HMAC 安全。在 PHP 5 中，您可以使用 hash_hmac() 函数：

$salt = $systemSalt.$userSalt;
hash_hmac('sha1', $password, $salt);

编辑：系统范围盐的基本原理：它可以而且应该存储在数据库之外（但备份它。您将无法进行身份验证你的用户，如果你失去它）。如果攻击者以某种方式读取了您的数据库记录，在他知道系统范围的盐之前，他仍然无法有效地破解您的密码哈希。

编辑（稍微偏离主题）：
关于密码散列安全性的进一步说明：您可能还想阅读Why do salts make dictionary attacks 'impossible'? 多次散列以额外保护免受暴力破解和彩虹表攻击（尽管我认为重复散列可能会带来额外的拒绝 -服务攻击，除非您限制每次登录尝试的次数）。

注意

考虑到多用途多核系统（显卡、可编程微控制器等）的兴起，可能值得使用具有高计算量的算法以及盐来对抗暴力破解，例如使用多个散列，如 PBKDF2。但是，您应该限制每个时间单位的身份验证尝试次数，以防止 DDoS 攻击。

还有一件事：使用基于广泛使用的标准而不是广泛使用的预构建函数的“自定义”散列的另一个主要理由是 PHP 本身，它已被证明不是在实现与安全相关的东西时完全值得信赖，无论是非随机随机数生成器还是特定情况下的crypt() function that does not work at all，从而完全绕过任何计算或内存密集型密码散列函数应该带。
由于它们的确定性结果，简单的哈希函数比密钥派生函数的输出更有可能被正确测试，但您的里程可能会有所不同。

【讨论】：

这很有趣......我对 HMAC 从来没有新的了解......我会阅读它
使用登录名作为盐甚至比使用电子邮件更糟糕。它使预先计算您的彩虹表变得更容易，因为您几乎可以在任何网站上找到用户名。除此之外，我喜欢你使用两种盐的方法，它会是 +1。
谢谢，0xA3。相应地更新了我的答案。

【解决方案3】：

我不是密码学专家，但是有 3 件事特别让我觉得这个建议可能存在问题。

正如 Mark 指出的那样，电子邮件可能会更改，但是对于给定的密码，盐值需要保持不变（否则您将无法检查密码的有效性）。
电子邮件地址的大小是可变的，我认为盐值大于一定大小很重要。
使用电子邮件地址会使盐大大更可预测，这在密码学中通常是一件坏事。

我不知道这些是否是一个问题，但是关于密码学的事情是，通常没有人知道，直到有人设计了一个漏洞利用（到那时为时已晚） -所以我的建议是谨慎行事，不要将电子邮件地址用作盐。

【讨论】：

【解决方案4】：

正如其他人已经提到的，盐最好是随机的。 salt 的目的是防止使用预先计算的哈希字典进行彩虹表攻击。

假设攻击者从您的数据库中知道了散列密码和盐，如果盐是“a74kd%$QaU”并且密码是“12345”，他能否使用彩虹表破解它？不，即使密码很弱，攻击者也不会为您的随机盐准备一个预先计算的哈希字典。

但是，如果您使用非随机 salt（如用户 id 或电子邮件），则更有可能有人已经为该 salt 创建了彩虹表，希望找到用户名为“john”或电子邮件“john. doe@example.com"¹

¹WLAN 的 WPA 安全性使用接入点的 SSID 作为盐。太糟糕了，有人已经pre-computed hashes 获取最常见的 SSID 名称。

【讨论】：

0xA3，如此巧合，我现在正在使用盐“john.doe@example.com”生成彩虹表。我理解你的意思，但世界上没有一个人用盐“john.doe@example.com”做彩虹桌。它们制作时间太长，并且需要太多的存储空间来制作这样的桌子......但是我会随机使用盐，因为我意识到将来有可能电子邮件可能需要改变。
@Starlin：电子邮件地址可能比用户名或 SSID 值更好，但为什么要让攻击变得不必要地容易呢？我的答案中链接中的 SSID 彩虹表仅在 3 天内生成，大小仅为 40GB。这就是另一点发挥作用的地方：散列函数需要很慢。
@0xA3：WPA 还会在间隔时自动更改密钥。如果间隔小于彩虹表查找时间，您也可以使用固定盐。

【解决方案5】：

Ophcrack（大多数攻击者可能会使用它，具体取决于您的加密功能）不包含带有“.”等特殊字符的表。或 '@' 除非您使用最大（“扩展”）表。因此，使用电子邮件可能会比许多其他盐更好。

【讨论】：

这是一个有趣的观察。如果您真的担心彩虹表或暴力攻击，使用更复杂的盐会有一些好处。

【解决方案6】：

与所有与安全相关的事情一样，答案取决于问题，其中不包括有关您希望系统有多安全的信息。最安全的建筑是没有门窗的；它也是最没用的建筑。

从最高级别：不，这不是一个坏主意。这也不是一个好主意。但是，对于您的应用程序来说，它可能已经足够了——或者已经足够好了。

如果某人有一个特定电子邮件地址的彩虹表，您是否能够通过使用随机盐对密码进行哈希处理来阻止他们？优秀的黑客会采取阻力最小的方式，这可能包括获取系统的 root 访问权限以及下载 salt 和 user 表。（它们是单独保护的吗？）如果是这样，它们必须在密码更改之前匹配哈希，而不管系统强制的连续登录尝试失败限制或您为 salt 选择的内容。

您的应用程序中的随机盐会增加多少复杂性？您试图阻止黑客的决心如何？还有哪些其他措施——最长连续失败锁定、强制密码到期期限、入口和 DoS 警报、防火墙等——你有什么措施吗？答案就在这些问题的答案和其他问题的答案之间的某个地方。

【讨论】：