当为登录网站的用户实施盐时，盐帐户创建时是否不需要与用户要登录时使用的盐相同？
在实施过程中，每次使用的盐量都不一样吗？
我理解用户之间的盐值可能会有所不同（在我的示例中），但是当用户A在星期一和星期五再次登录时，这两个时间的盐值不必相同？
#1 楼
通常，当用户注册时，您将生成一个随机值来变成盐。然后，在用户数据库中，存储使用密码和salt生成的用户名，salt和哈希（以及与用户表相关的任何其他信息）。请注意，这样做可以每个用户都有一个独特的盐。具有独特盐分的每个用户都会大大增加攻击难度。攻击者被迫对每个用户进行暴力攻击，而不是预先计算每个密码方案彩虹表（无盐）或每个数据库彩虹表（系统级盐）。在当今大规模并行GPU哈希实现的今天，确保暴力攻击实际上足够缓慢以至于使攻击者付出代价仍然是您的责任。
理想情况下，攻击者甚至无法查看数据库上的盐，但是如果情况变得更糟，则不必将其私有。
#2 楼
是的，每次使用由该盐创建的哈希时，都需要使用相同的盐。通常，为每个用户生成一个伪随机盐，并将其存储在散列旁边。许多哈希库（例如bcrypt）会创建带有嵌入盐的哈希。#3 楼
在过去的一位雇主处，我们使用了一些大致如下的表格：
Web应用程序将根据使用的哈希算法来切换出不同的算法。并且如果用于特定客户的哈希现在已过时，则将要求他们更改密码，并且它将使用新哈希更新用户表中的行。由于某种原因，业务花花公子（又名“西装”）会改变主意，以接受可接受的散列，并对微观事物进行微管理（例如，“必须在密码前加盐”，后来改为“否”）。 ！必须在密码末尾添加“ salt”。）基于他们当周阅读的任何博客文章或商业杂志。这导致每年使用任何数量的哈希算法。我认为这太可怕了，在任何时候都应该只使用一种算法（当从“旧”切换到“新”时，最多只能使用2种算法）。
盐通常是在用户注册第一个盐时生成的。但是，当诉讼决定采用新的哈希算法时，他们有时会要求更改盐值。
当EULA发生变化时，我们必须迫使用户阅读新的并同意新的，并跟踪谁同意什么。
免责声明：我在其他帖子上使用了这张图片。
评论
$ \ begingroup $
攻击者（理想地）看到哈希的唯一方法是，如果他们获得了数据库转储。那个垃圾堆里会放着盐...你不想把两者分开吗？在我看来，将盐放在哈希表上几乎就像存储使用可加密数据的一半密钥存储的可解密数据一样。
$ \ endgroup $
– Corey Ogburn
2011年7月12日在20:01
$ \ begingroup $
那不是真的。没有盐，攻击者将被要求执行蛮力攻击。有了盐，攻击者仍然需要蛮力攻击。区别在于，攻击者无法使用Salt预先计算许多简单的哈希（“ dog”，“ password”等），而必须重新计算整个哈希键空间（“ dog_kaskd2e”，“ password_kaskd2e等”） 。
$ \ endgroup $
–萨摩斯
2011年7月12日20:10
$ \ begingroup $
您也可以将其视为第一个原像攻击。这种攻击是在给定哈希h的情况下，找到一条消息m，其中H（m）= h。如果知道盐，则将其简单地降低为H（m |盐）= h。假设您有一个安全的哈希算法，那么它应该能够抵御这种第一个原像攻击。
$ \ endgroup $
–萨摩斯
2011年7月12日在20:12
$ \ begingroup $
啊，我明白了您的意思，即不允许攻击者使用预先计算的简单哈希。看到了如此多的Sony版本之后，我知道盐会在多大程度上使他们免于羞耻。我将从他们的错误（以及您的答案/评论）中学习
$ \ endgroup $
– Corey Ogburn
2011年7月12日在20:39
$ \ begingroup $
盐绝对不需要保密。如果您不知道使用它们的动机，则可能会发现此答案很有趣stackoverflow.com/questions/2583203/salt-passwords-and-security / ...
$ \ endgroup $
–ZoFreX
2011年7月13日在10:48