我一直都很好奇...在使用散列密码进行散列时哪个更好:前缀或后缀？为什么？或者它是否重要,只要你加盐？
为了解释:我们所有(希望)现在我们应该知道盐之前,我们哈希它存储在数据库中的密码[ 编辑:所以你能避免类似的事情发生了什么杰夫阿特伍德最近.通常,这是通过在将盐传递给散列算法之前将盐与密码连接来完成的.但是这些例子各不相同......有些例子在密码之前加盐.一些示例在密码后添加salt .我甚至看到过一些尝试将盐放在中间的人.
那么哪种方法更好,为什么呢？有没有一种方法可以减少哈希冲突的可能性？我的谷歌搜索没有找到关于这个问题的体面分析.
编辑:很棒的答案人们!对不起,我只能选一个答案.:)
前缀或后缀是无关紧要的,它只是为密码添加一些熵和长度.
你应该考虑这三件事:
对于您存储的每个密码,盐必须不同.(这是一个很常见的误解.)
使用加密安全随机数生成器.
选择足够长的盐.想想生日问题.
Dave Sherohman对另一个问题有一个很好的答案,为什么你应该使用随机生成的盐而不是用户的名字(或其他个人数据).如果你遵循这些建议,你把盐放在哪里都没关系.
我认为这都是语义学.除非针对特定的威胁模型,否则将其置于之前或之后无关紧要.
它应该打败彩虹表的事实.
我提到的威胁模型将是对手可以在密码附加/预先附加普通盐的彩虹表的情况.(比如美国国家安全局)你猜测他们要么附加或附加,要么不是两者兼而有之.这很愚蠢,这是一个糟糕的猜测.
最好假设他们有能力存储这些彩虹表,但不是说,例如,在密码中间插入奇怪的盐的表.在那个狭隘的案例中,我猜想穿插最好.
就像我说的.这是语义.为每个密码选一个不同的盐,一个长盐,并在其中包含奇数字符,如符号和ASCII码:©¤¡
真正的答案,没有人似乎已经触及过,两者都是错的.如果你正在实施自己的加密,无论你认为自己在做什么都是微不足道的,你都会犯错误.
HMAC是一种更好的方法,但即便如此,如果您使用SHA-1之类的东西,由于其速度设计,您已经选择了一种不适合密码散列的算法.使用像bcrypt或scrypt这样的东西,完全解决问题.
哦,甚至不考虑将产生的哈希值与您的编程语言或数据库字符串比较实用程序进行比较.那些字符和短路的比较,就false好像一个字符不同.所以现在攻击者可以使用统计方法来尝试找出哈希是什么,一次一个字符.
它应该没有任何区别.无论你把盐放在哪里,哈希都不会轻易猜到.由于故意非线性,哈希碰撞既罕见又不可预测.如果它对安全性产生影响,则表明散列问题,而不是腌制问题.
如果使用加密安全散列,无论你是pre-post还是postfix都无关紧要; 哈希点是源数据中的单个位更改(无论在哪里)应该产生不同的哈希.
什么是重要的,虽然是使用长盐,用正确的密码PRNG生成它们,并且每用户的盐.使用站点范围的哈希是在数据库中存储每用户salt 不是安全问题.
首先,术语"彩虹表"一直被滥用.A"彩虹"表只是一个特定类型的查找表,一个允许特定种类上的按键数据压缩.通过交换空间计算,可以将需要1000 TB的查找表压缩一千次,以便可以将其存储在较小的驱动器驱动器上.
你应该担心哈希到密码查找表,彩虹或其他.
@ onebyone.livejournal.com:
攻击者的"彩虹表"不是由字典单词的散列组成,而是由最终确定散列计算之前的散列计算状态组成.
然后,使用postfix salt强制使用密码文件条目比使用salt前缀更便宜:对于每个字典单词,您将加载状态,将salt字节添加到散列中,然后完成它.使用前缀盐,每个字典单词的计算之间没有任何共同点.
对于通过输入字符串线性扫描的简单散列函数,例如简单的线性同余生成器,这是一种实际的攻击.但是加密安全散列函数被故意设计为具有多个循环,每个循环使用输入字符串的所有位,因此在添加盐之前计算内部状态在第一轮之后没有意义.例如,SHA-1有80轮.
此外,像PBKDF这样的密码散列算法多次组合它们的散列函数(建议迭代PBKDF-2至少1000次,每次迭代应用SHA-1两次)使得这种攻击双重不切实际.
京公网安备 11010802040832号 | 京ICP备19059560号-6 