添加密码:最佳实践?

前缀或后缀是无关的,它只是增加一些熵和长度的密码。

你应该考虑这三件事:

1. 存储的每个密码的salt都必须不同。(这是一个很常见的误解。)

有一个极好的例子 answer by Dave Sherohman

我认为这都是语义学。把它放在前面或后面并不重要,除非是针对一个非常具体的威胁模型。

它在那里的事实应该能打败彩虹桌。

可以

最好假设他们有能力存储这些彩虹表,但不是,比如说,在密码中间散布着奇怪盐的表。在里面 那个

就像我说的。这是语义学。每个密码选择一个不同的salt,一个长salt,并在其中包含奇数字符,如符号和ASCII码:

真正的答案似乎没有人提及,那就是 both are wrong . 如果您正在实现自己的加密,无论您认为自己正在做的部分多么微不足道,您都可以 犯错误。

HMAC 是一种更好的方法,但即使您使用类似SHA-1的方法,您已经选择了一种算法,该算法由于其速度设计不适合密码哈希。使用类似 bcrypt scrypt 把问题完全从你手里拿开。

哦,甚至不要考虑将得到的哈希值与编程语言或数据库字符串比较实用程序进行相等性比较。这些比较字符的字符和短路作为 false 如果字符不同。因此,现在攻击者可以使用统计方法尝试计算出散列是什么,一次一个字符。

这应该没什么区别。无论你把盐放在哪里,杂烩都不容易猜到。散列冲突既罕见又不可预测,因为它是故意非线性的。如果它对安全性产生了影响,那么这就意味着哈希问题,而不是盐析问题。

什么 是 不 安全问题,使用站点范围的哈希 .

首先,术语“彩虹表”一直被误用。“彩虹”桌只是一个特殊的桌子 友善的

您应该担心密码查找表的哈希,rainbow或其他。

@onebyone.livejournal.com:

攻击者拥有的“彩虹表”不包括字典单词的散列,而是在完成散列计算之前的散列计算状态。

对于线性扫描输入字符串的简单哈希函数,例如简单的线性同余生成器,这是一种实际的攻击。但是一个加密安全的散列函数被故意设计成具有多轮,每轮使用输入字符串的所有位,以便计算内部状态 就在前面

此外,密码散列算法(如PBKDF)多次组合其散列函数(建议至少迭代PBKDF-2 1000次,每次迭代应用SHA-1两次),使得这种攻击更加不切实际。

BCrypt hash 如果平台有提供者。我喜欢你不用担心盐的产生,如果你想的话,你可以让盐变得更浓。

在密码中插入任意数量的salt字符是最不理想的情况,因此在社会上是最“安全”的,但在一般情况下,只要您为salt使用长的、唯一的每个密码字符串,它就没有多大意义。