在存储之前对密码进行两次哈希处理的安全性是否比仅仅哈希一次更安全？
我在说什么是这样做的:
$hashed_password = hash(hash($plaintext_password));
而不仅仅是这个:
$hashed_password = hash($plaintext_password);
如果它不太安全,你能提供一个很好的解释(或链接到一个)吗？
此外,使用的哈希函数是否有所作为？如果混合使用md5和sha1(例如)而不是重复相同的散列函数,它会有什么不同吗？
注1:当我说"双重哈希"时,我正在谈论两次哈希密码以试图使其更加模糊.我不是在谈论解决碰撞的技术.
注2:我知道我需要添加一个随机盐来真正使其安全.问题是使用相同算法进行两次散列是否有助于或损害散列.
我在理解盐密封的目的时遇到了一些麻烦.据我所知,主要用途是阻碍彩虹表攻击.但是,我看到实现这一点的方法似乎并没有真正解决问题.
我见过许多教程,建议将盐用作以下内容:
$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和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 …在数据库中存储密码的首选方法/数据类型是什么(最好是SQL Server 2005).我在几个应用程序中一直使用的方法是首先使用.NET加密库,然后将它们作为二进制文件存储在数据库中(16).这是首选方法还是我应该使用不同的数据类型或分配比16更多的空间？
据我了解,生成盐的最佳做法是使用源代码中存储的一些神秘公式(甚至魔术常量).
我正在研究一个我们打算作为开源发布的项目,但问题是源代码是生成盐的秘密公式,因此能够在我们的网站上运行彩虹表攻击.
我认为很多人在我面前都考虑过这个问题,我想知道最佳做法是什么.在我看来,如果代码是开源的话,根本就没有盐,因为盐可以很容易地进行逆向工程.
思考？
假设您可以自由决定如何将散列密码存储在DBMS中.像这样的计划有明显的弱点吗？
要创建存储在DBMS中的哈希值,请执行以下操作:
这意味着任何想要发生冲突的人都必须分别为每个用户名和每个DBMS服务器实例单独完成工作.我打算保持实际的哈希机制有点灵活,以允许使用仍在使用的新NIST标准哈希算法(SHA-3).
"DBMS服务器实例独有的值"不一定是秘密的 - 尽管它不会随便泄露.目的是确保如果有人在不同的DBMS服务器实例中使用相同的密码,则记录的哈希值会有所不同.同样,用户名也不是秘密 - 只需要密码.
首先使用密码以及用户名和"唯一值"第二个,或三个数据源的任何其他排列是否有任何优势？或者交错字符串怎么样？
我是否需要添加(并记录)随机盐值(每个密码)以及上述信息？(优点:用户可以重新使用密码,但仍然可能会在数据库中记录不同的哈希值.缺点:必须记录盐.我怀疑其优势远大于缺点.)
有很多相关的SO问题 - 这个列表不太可能是全面的:
我认为这些问题的答案支持我的算法(尽管如果你只是使用随机盐,那么'每个服务器的唯一值'和用户名组件就不那么重要了).
我正在编写一个小桌面应用程序,它应该能够加密数据文件并用密码保护它(即必须输入正确的密码才能解密).我希望加密数据文件是自包含和可移植的,因此必须将身份验证嵌入到文件中(或者我假设).
我有一个看似可行的策略,看起来很合理,基于我所知道的(这可能只是危险),但我不知道它是否真的是一个好的设计.那么告诉我:这是疯了吗？有更好/最好的方法吗？
基本上我是从实现网站密码的常用方法推断出来的(当你没有使用OpenID时),即在你的数据库中存储用户密码的(盐渍)哈希,而不是保存实际的密码.但由于我使用散列用户密码作为对称加密密钥,因此我无法使用相同的值进行身份验证.所以我再次哈希,基本上把它当作另一个密码处理,并将双重哈希值保存在数据文件中.这样,我可以将文件带到另一台PC,只需输入我的密码即可解密.
那么这个设计是合理安全的,还是绝望的天真,或介于两者之间？谢谢!
编辑:澄清和后续问题re:盐.
我认为盐必须保密才有用,但你的答案和链接暗示情况并非如此.例如,由erickson(下面)链接的这个规范说:
因此,这里定义的基于密码的密钥推导是密码,盐和迭代计数的函数,其中后两个量不需要保密.
这是否意味着我可以将盐值存储在与散列键相同的位置/文件中,并且仍然比在散列时根本不使用盐时更安全？这是如何运作的？
更多上下文:加密文件不是为了与他人共享或解密,它实际上是单用户数据.但是我想将它部署在我无法完全控制的计算机上的共享环境中(例如在工作中),并且能够通过简单地复制文件来迁移/移动数据(所以我可以在家里,在不同的地方使用它工作站等).
我已经阅读了很多有关此问题的问题,但许多答案相互矛盾或者我不理解.
您应该始终将密码存储为哈希,而不是纯文本.但是,您应该在数据库中的散列密码+ salt旁边存储salt(每个用户都是唯一的).这对我来说似乎不是很聪明,因为无法有人访问数据库,查找称为Admin或其他任何帐户,然后从中计算出密码？
我正在研究构建一个登录系统,当你将2位数的盐传递给crypt()函数时,读取php手册后,它返回一个哈希字符串,字符串的前两位是你使用的盐.
例:
$salt = "kr";
echo crypt("mysecret",$salt); //returns "kreOI.F7eOQMY"
我的第一个想法是,这不会帮助那些试图扭转你的哈希的人吗？
我在维基百科上查了一下盐说:
为了最好的安全性,盐值保密.
所以我不明白为什么crypt函数会返回所有使用salt值的哈希值？
是否有一个原因？这应该是一个安全问题吗？
security ×8
hash ×6
encryption ×5
passwords ×5
salt ×5
cryptography ×4
rainbowtable ×2
database ×1
open-source ×1
php ×1
sql-server ×1