电子邮件地址为密码盐？

Question

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

Answer 1

修改
让我向您推荐这个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在某些情况下，因此完全绕过计算机的任何好处 - 或者应该带来内存密集的密码散列函数 由于它们的确定性结果，简单的散列函数比密钥导出函数的输出更可能被正确测试，但您的里程可能会有所不同。

Answer 2

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

1. 正如Mark指出的那样，电子邮件可能会发生变化，但是对于给定的密码，盐需要保持不变（否则您将无法检查密码的有效性）。
2. 电子邮件地址的大小是可变的，我认为盐大于特定大小非常重要。
3. 使用电子邮件地址可以使盐更多更具可预测性，这在加密中通常是一件坏事。

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

如果某人有特定电子邮件地址的彩虹表，您是否可以通过使用随机盐散列密码来阻止它们？优秀的黑客采取阻力最小的路径，其中可能包括获得对系统的root访问权限以及下载salt和用户表。 （它们是单独保护的吗？）如果是这样，它们会一直更改密码以匹配散列，无论系统强制执行的连续失败登录尝试限制或您选择的盐是什么。

您的应用程序中随机盐会产生多少复杂性？你试图挫败黑客的决心如何？还有哪些其他措施 - 最大连续故障锁定，强制密码有效期，入口和DoS警报，防火墙等等 - 您有没有？答案在于这些问题的答案与其他问题的答案之间的趋同。