代码之家  ›  专栏  ›  技术社区  ›  Imagist

用大麻储存盐可以吗?

  •  23
  • Imagist  · 技术社区  · 15 年前

    我的理解是,盐并不是秘密的,它仅仅是为了不同于任何集中的标准,这样你就不能开发一个彩虹表或类似的攻击来破坏所有使用算法的哈希,因为盐破坏了彩虹表。我在这里的理解可能不完全正确,所以如果我错了就纠正我。

    在一个广泛使用的开放源代码软件中,salt将被广泛使用,这将使您容易受到攻击,因为现在它们可以简单地攻击hash的salted版本,并创建包含salt数据的彩虹表。

    正如我所见,有两种方法可以解决这个问题。第一种方法是随着软件的每一个新版本改变SALT,但这并不好,因为新版本的软件将不再能够针对旧密码哈希进行测试。

    我想到的第二个解决方案是为每个密码存储一个salt;换句话说,每个密码获得不同的salt。缺点是,这些盐类必须以某种方式与密码散列相关联,可能只是将它们贴在数据库中密码的旁边。甚至可以使用用户名(但可能用户名太短)。

    我的问题是,这可以接受吗?是否有任何额外的风险与将salt直接存储到其哈希的密码相关?在我看来,在源代码中存储salt并没有什么不同,所以用密码存储salt不会造成安全损失。

    免责声明:我不会把它用于任何现实生活中的安全系统。实际上,我从未设计过任何类型的密码系统。我只是对自己的安全问题保持模糊的了解。

    7 回复  |  直到 11 年前
        1
  •  19
  •   Mikael Auno    11 年前

    更新 :使用合格的库,例如 passlib 用于Python。

    它们负责生成每个密码的salt,并使用适当的哈希算法(它不足以只使用诸如sha1之类的加密哈希;您必须以一种使其反向速度非常慢的方式应用它,例如在其上循环1000次或更多次等。这就是密码哈希的功能 bcrypt 工作。密码存储库可以正确地完成所有这些工作;它们通常会生成一个被分隔的字符串,以便确定使用的哈希系统和工作因子;您只需存储字符串而不需要知道这一点。


    您可以将盐存储在表中的“纯文本”中。

    • 盐不需要是秘密就能有效。

    • 它只需要是随机的。

    salt通过使哈希值与同一数据库或其他数据库中的同一密码不可比较,并使预先生成的大量常用密码列表无效以进行哈希查找(例如“彩虹表”),来增强密码。

    因此,每个用户的salt都是唯一的,并且是随密码存储的一些随机值,这一点至关重要;问题中概述的其他选项(使用用户名作为salt,对整个应用程序使用单个salt值)都会失败:

    • 如果系统使用用户名或其他琐事,则可以将密码与其他系统中具有相同名称的其他用户进行比较(想象“管理员”或“根”用户帐户在不同系统中使用相同密码的频率…)

    • 如果系统对同一个系统中的所有用户使用一个随机salt,那么两个拥有相同密码的用户将拥有相同的哈希值,猜测一个用户的密码将对另一个用户造成微不足道的危害。

        2
  •  9
  •   Michael Borgwardt    15 年前

    试图保守盐的秘密是毫无意义的 这是因为我们从经验中了解到,我们甚至不能完全可靠地对数据库保密,所以存在完整的密码加盐和散列的做法。您最多可以单独存储salt,并希望访问您的db的攻击者找不到它,但是如果您使用了一个好的哈希算法和足够长的单个salt,那么您应该是安全的。

    SALT的目的仅仅是确保您不能在整个数据库甚至多个数据库中分摊暴力攻击的成本。

    第一种方法是把盐换成 软件的每一个新版本,但是 这不好,因为新版本 软件将不再是 能够测试旧密码 散列。

    我看到的一个变化是在安装过程中生成一个随机的salt(当然,在不同版本中都保留它),这样每个运行的实例都有一个不同的salt。当然,为每个密码使用不同的salt(也许除了上面的内容之外)更好。

        3
  •  1
  •   LukáÅ¡ Lalinský    15 年前

    这个 salt 根据定义,必须是随机的才能有效。不要为此使用任何确定性值。当然,这意味着您需要将它与哈希密码一起存储在数据库中。 UNIX systems 传统上,甚至将哈希存储在与密码相同的字段中(salt是密码的固定长度前缀)。在数据库中,用户表中可以有其他列。

        4
  •  0
  •   Jesse Hallam    15 年前

    为每个密码生成一个唯一的salt是完全正常的。盐可以是现有材料(如userid等)的产物,也可以是随机生成的。其优点是,对加密信息的攻击会变得更多 不切实际的 随着盐的强度增加。

    记住:每个密码算法都是可破解的。只有当破解保护(通过彩虹表或其他方式)的成本高于信息的价值时,信息才被认为是“安全的”。

    编辑:

    假设你对密码学很陌生,下面还有一些提示:

    • 长盐比短盐好。
    • 盐的可能值越多越好。字母数字盐比数字盐好。二元盐比字母数字盐好。
    • 盐类 习惯于 制作 强力攻击 攻击单一密码的可能性较小。
        5
  •  0
  •   MarkR    15 年前

    第二个解决方案“存储每个密码的盐”是正确的,通常使用。

    “salt”主要是为了让两个用户在使用相同密码时很难检测到,因此您需要将已知的“salt”混合到密码中。SALT需要在密码检查时能够获取。

    因此,通常要么生成一个随机salt并用密码存储它,要么使用其他标识符(用户ID、用户名等)作为salt。

        6
  •  0
  •   Artelius    15 年前

    对数据库中的所有密码使用一个salt是有帮助的,但是 许多的 比给每个用户一个独特的盐更不安全。

    基本上:较长的(以字节为单位)密码+salt会增加搜索空间,因此更难使用“stock-standard”彩虹表。

    但是,如果所有条目都使用相同的盐,则可以创建彩虹表。 明确地 攻击你的软件。如果你的用户群很大,那么有人可能会决定做一个彩虹表。

    例如,如果在散列之前只在每个密码的末尾添加“和大量salt”,攻击者可以构建一个由大量字符串生成的散列值表,所有这些字符串都以“和大量salt”结尾。

    因此,每用户盐是最好的方法。但是,请记住,您还希望密码+salt为“long”。

    如果您想使用主键,最好使用 搞砸 而不是使用主键本身,因为如果用户43的密码+salt看起来像“mypassword0000000043”,那么攻击者可以建立一个表,假设中间有很多零。不过,创建时间戳和随机字符串可能是更好的选择,因为有时可以很容易地找到或猜测pkey。

    注意:我不是真正的加密专家,不要在真正的系统中使用这个建议。

        7
  •  -1
  •   Community CDub    8 年前

    实际上,您已经在用户表中存储了一个salt值:表的pkey。

    你不必发明一种新的盐柱来储存盐。用一下钥匙。当然,这个想法假定您确实有一个与用户名关联的pkey。例如,用户名不是表中的pkey。

    这是一个接近dup的WTB: Password hashing, salt and storage of hashed values