9

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

4

6 回答 6

20

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

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

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

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

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

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

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

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

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

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

编辑（稍微偏离主题）：
关于密码哈希安全性的进一步说明：您可能还想阅读为什么盐会使字典攻击“不可能”？关于多次散列以额外保护免受暴力破解和彩虹表攻击（尽管我认为重复散列可能会引入拒绝服务攻击的额外机会，除非您限制每次登录尝试的次数）。

笔记

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

还有一件事：使用基于广泛使用的标准而不是广泛使用的预构建函数构建的“自定义”散列的另一个主要理由是 PHP 本身，它在实现安全性方面已证明自己根本不值得信赖 -相关的东西，无论是不那么随机的随机数生成器还是在某些情况下crypt()根本不起作用的函数，从而完全绕过了计算密集型或内存密集型密码散列函数应该带来的任何好处。
由于它们的确定性结果，简单的散列函数比密钥派生函数的输出更有可能被正确测试，但你的里程可能会有所不同。

于 2010-09-24T13:14:32.277 回答
6

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

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

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

于 2010-09-24T13:16:13.313 回答
4

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

于 2010-09-24T13:10:10.033 回答
1

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

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

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

1 WLAN 的 WPA 安全性使用接入点的 SSID 作为盐。太糟糕了，有人已经为最常见的 SSID 名称预先计算了哈希值。

于 2010-09-24T13:24:14.703 回答
1

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

于 2010-09-24T13:30:33.823 回答
1

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

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

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

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

于 2014-01-29T02:15:04.153 回答