我在理解盐密封的目的时遇到了一些麻烦.据我所知,主要用途是阻碍彩虹表攻击.但是,我看到实现这一点的方法似乎并没有真正解决问题.
我见过许多教程,建议将盐用作以下内容:
$hash = md5($salt.$password)
原因是哈希现在不映射到原始密码,而是密码和盐的组合.但是说$salt=foo和$password=bar和$hash=3858f62230ac3c915f300c664312c63f.现在有人用彩虹表可以反转哈希并提出输入"foobar".然后他们可以尝试所有密码组合(f,fo,foo,... oobar,obar,bar,ar,ar).获取密码可能需要几毫秒,但其他情况并不多.
我见过的其他用途是在我的linux系统上.在/ etc/shadow中,散列密码实际上与 salt一起存储.例如,"foo"的盐和"bar"的密码将散列到此:$1$foo$te5SBM.7C25fFDu6bIRbX1.如果一个黑客以某种方式能够得到这个文件,我不知道盐服务的目的是什么,因为te5SBM.7C25fFDu6bIRbX已知反向哈希包含"foo".
感谢任何人都可以解决这个问题.
编辑:谢谢你的帮助.为了总结我的理解,salt使得散列密码更加复杂,从而使得它更不可能存在于预先计算的彩虹表中.我之前误解的是,我假设所有哈希都存在彩虹表.
在工作中,我们有两种相互竞争的盐理论.我工作的产品使用类似用户名或电话号码来加密哈希值.基本上每个用户都有不同的东西,但我们可以随时使用.另一个产品为每个用户随机生成一个salt,并在每次用户更改密码时更改.然后在数据库中加密盐.
My question is if the second approach is really necessary? I can understand from a purely theoretical perspective that it is more secure than the first approach, but what about from a practicality point of view. Right now to authenticate a user, the salt must be unencrypted and applied to the login information.
在考虑之后,我只是没有从这种方法中看到真正的安全性收益.将盐从帐户更改为帐户,即使攻击者知道如何快速确定每个帐户的内容,仍然会使某人尝试强制执行散列算法变得非常困难.这是基于密码足够强的假设.(显然,找到一组密码的正确哈希值,它们都是两位数,比找到8位密码的正确哈希值要容易得多).我的逻辑是不正确的,还是我缺少的东西？
编辑:好的,所以这就是为什么我认为加密盐真的没有意义.(lemme知道我是否在正确的轨道上).
对于以下说明,我们假设密码总是8个字符,盐是5,所有密码都由小写字母组成(它只是使数学更容易).
Having a different salt for each entry means that I can't use the same rainbow table (actually technically I could if I …
更新:我最近从这个问题中了解到,在下面的整个讨论中,我(我确信其他人也这样做)有点令人困惑:我一直称之为彩虹表,实际上称为哈希表.彩虹桌是更复杂的生物,实际上是Hellman Hash Chains的变种.虽然我认为答案仍然是相同的(因为它不归结为密码分析),但有些讨论可能有点偏差.
问题是:" 什么是彩虹表,它们是如何使用的？ "
通常,我总是建议使用加密强随机值作为salt,与哈希函数(例如密码)一起使用,例如防止彩虹表攻击.
但实际上盐是随机的加密必需吗？在这方面,任何唯一值(每个用户唯一,例如userId)是否足够？实际上,它会阻止使用单个Rainbow Table来破解系统中的所有(或大多数)密码......
但是缺少熵真的会削弱散列函数的加密强度吗？
注意,我不是在问为什么要使用salt,如何保护它(它不需要),使用单个常量哈希(不要),或者使用什么样的哈希函数.
无论盐是否需要熵.
感谢所有答案到目前为止,但我想集中讨论我(有点)不太熟悉的领域.主要是对密码分析的影响 - 如果有人从密码数学PoV获得一些输入,我会非常感激.
此外,如果还有其他未被考虑的向量,那也是很好的输入(参见@Dave Sherohman指向多个系统).
除此之外,如果您有任何理论,想法或最佳实践 - 请使用证据,攻击情景或经验证据来支持这一点.或者甚至是可接受的权衡的有效考虑因素......我对该主题的最佳实践(资本B资本P)很熟悉,我想证明这实际上提供了什么价值.
编辑:这里有一些非常好的答案,但我认为正如@Dave所说,它归结为Rainbow Tables的常见用户名......以及可能不太常见的名称.但是,如果我的用户名是全局唯一的呢？不一定是我的系统唯一,但每个用户 - 例如电子邮件地址.
没有动力为单个用户构建RT(正如@Dave强调的那样,盐不会保密),这仍然会阻止群集.唯一的问题是我可能在不同的网站上有相同的电子邮件和密码 - 但盐无论如何都不会阻止它.
因此,它回归到密码分析 - 是否需要熵？(我目前的想法是从密码分析的角度来看没有必要,但这是出于其他实际原因.)
security authentication hash cryptography password-protection
更新:请注意我不是在询问盐是什么,彩虹表是什么,字典攻击是什么,或盐的目的是什么.我在查询:如果你知道用户的salt和hash,那么计算密码是不是很容易？
我理解这个过程,并在我的一些项目中自己实现它.
s = random salt
storedPassword = sha1(password + s)
在您存储的数据库中:
username | hashed_password | salt
我所看到的盐析的每次实施都会在密码的末尾添加盐,或者开始:
hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)
因此,来自黑客的字典攻击是值得他的盐(哈哈),只需针对上面列出的常见组合中存储的盐运行每个关键字.
当然,上述实现只是为黑客增加了另一个步骤,而没有真正解决潜在的问题？有什么替代方法可以解决这个问题,还是我误解了这个问题？
我唯一能想到的就是有一个秘密混合算法,它以随机模式将salt和密码绑定在一起,或者将其他用户字段添加到散列过程中,这意味着黑客必须能够访问数据库和代码才能获得花边他们为字典攻击证明富有成效.(更新,正如评论中指出的那样,最好假设黑客可以访问您的所有信息,因此这可能不是最好的).
让我举一个例子,说明我如何建议黑客用密码和哈希列表来破解用户数据库:
来自我们黑客数据库的数据:
RawPassword (not stored) | Hashed | Salt
--------------------------------------------------------
letmein WEFLS... WEFOJFOFO...
通用密码字典:
Common Password
--------------
letmein
12345
...
对于每个用户记录,循环公共密码并对其进行哈希:
for each user in hacked_DB
salt = users_salt
hashed_pw = users_hashed_password
for each common_password
testhash = sha1(common_password + salt)
if testhash = hashed_pw then
//Match! Users password …我正在看一些我自己没有写过的代码.代码尝试使用SHA512散列密码并仅使用time()盐作为密码.是time()太简单盐这或者是这个代码安全吗？
感谢您的回答和评论.我将在此为新读者总结一下:
random, evenly distributed, high entropy盐？好吧,那么我用随机字符串32 char long替换time()怎么样.可以通过在一组字母表字符上循环32次来生成随机字符串.听起来不错吗？
假设您可以自由决定如何将散列密码存储在DBMS中.像这样的计划有明显的弱点吗？
要创建存储在DBMS中的哈希值,请执行以下操作:
这意味着任何想要发生冲突的人都必须分别为每个用户名和每个DBMS服务器实例单独完成工作.我打算保持实际的哈希机制有点灵活,以允许使用仍在使用的新NIST标准哈希算法(SHA-3).
"DBMS服务器实例独有的值"不一定是秘密的 - 尽管它不会随便泄露.目的是确保如果有人在不同的DBMS服务器实例中使用相同的密码,则记录的哈希值会有所不同.同样,用户名也不是秘密 - 只需要密码.
首先使用密码以及用户名和"唯一值"第二个,或三个数据源的任何其他排列是否有任何优势？或者交错字符串怎么样？
我是否需要添加(并记录)随机盐值(每个密码)以及上述信息？(优点:用户可以重新使用密码,但仍然可能会在数据库中记录不同的哈希值.缺点:必须记录盐.我怀疑其优势远大于缺点.)
有很多相关的SO问题 - 这个列表不太可能是全面的:
我认为这些问题的答案支持我的算法(尽管如果你只是使用随机盐,那么'每个服务器的唯一值'和用户名组件就不那么重要了).
继我之前关于PHP/MySQL中的盐渍密码的问题之后,我还有另外一个关于盐的问题.
当有人说"使用随机盐"来预先/附加密码时,这是否意味着:
如果盐对于每个用户来说是随机的并且与散列密码一起存储,那么原始盐如何被检索回来进行验证？
我的理解是盐不是秘密的,它只是意图与任何集中标准不同,所以你不能开发彩虹表或类似的攻击来打破使用该算法的所有哈希值,因为盐分断裂彩虹桌.我在这里的理解可能不完全正确,所以如果我错了,请纠正我.
在一个广泛使用的开源软件中,盐会广为人知,这会让你受到攻击,因为现在他们可以简单地攻击哈希的盐渍版本并创建包含盐数据的彩虹表.
我认为,有两种方法可以解决这个问题.首先是使用每个新版本的软件更改salt,但这并不好,因为该软件的新版本将无法再针对旧密码哈希进行测试.
我想到的第二个解决方案是存储每个密码的盐; 换句话说,每个密码都有不同的盐.缺点是盐必须以某种方式与密码哈希相关联,可能只是将它们紧紧地放在数据库中的密码旁边.甚至可以使用用户名(但可能不会,用户名可能太短).
我的问题是,这可以接受吗？直接使用哈希密码存储盐有任何额外的风险吗？在我看来,在源代码中存储salt没有什么不同,因此通过使用密码存储salt不会造成安全性损失.
免责声明:我没有将它用于任何现实生活中的安全系统.事实上,我从未设计过任何类型的密码系统.我只是对自己的安全问题进行了模糊的教育.
好吧,我知道这可能很简单,但我似乎无法在任何地方找到答案.假设我有以下内容:
Password: "mypassword"
Salt: 1234567
腌制的想法是做什么样的hash(password + salt)或hash(password) + salt？我的猜测是,只有前者才有意义,但我只是想确保我不会错过任何东西.
请原谅我的无知.
嗨,大家好我读过有关密码腌制的信息,但这听起来有点奇怪.但是我如何储存和保护盐.例如,在多轮胎架构中,我说使用客户端机器的GUID生成我的盐然后用户被限制在一台机器上,但如果我使用随机盐,它必须存储在某处.几天后我看到了一个示例应用程序,每当创建一个新用户时,在客户端系统上生成散列和盐,然后将盐渍密码和散列传输到存储在SQL服务器中的服务器.但是,如果我遵循此方法并且数据库被泄露,则每个密码的密码和salt值将可供X人使用.那么,我应该再次加密/加密密码并在服务器端接收盐吗？腌制的最佳做法是什么？
hash ×9
security ×8
salt ×7
cryptography ×3
encryption ×3
passwords ×3
brute-force ×1
php ×1
rainbowtable ×1