盐,密码和安全

Question

我已经阅读了很多有关此问题的问题,但许多答案相互矛盾或者我不理解.

您应该始终将密码存储为哈希,而不是纯文本.但是,您应该在数据库中的散列密码+ salt旁边存储salt(每个用户都是唯一的).这对我来说似乎不是很聪明,因为无法有人访问数据库,查找称为Admin或其他任何帐户,然后从中计算出密码？

Answer 1

很多人都在说"停止彩虹表"而不解释彩虹表的作用或为什么会阻止它们.

彩虹表是一种聪明的方法,可以预先计算大量哈希值,并将它们存储在比天真需要的内存更少的内存中,您可以使用它们来快速反转哈希值.裸的功能,如表hash = md5(password)和hash = sha1(password)是常见的.

但是,可以为任何哈希函数生成它们,可以将其描述为output = f(input).如果你使用一个站点范围的盐对所有用户的密码,例如hash = md5(salt+password),您可以构建一个功能f,f(password) = md5(salt+password).因此,您可以为此函数生成彩虹表,这将花费很长时间,但是可以让您非常快速地破解数据库中的每个密码.

如果每个密码的salt不同,则无法生成将破解数据库中所有密码的彩虹表.你可以为每个用户生成一个新的,但这将毫无意义 - 天真的暴力强迫将不会更慢.因此,为每个用户提供单独的盐可以阻止彩虹表攻击.

有几种方法可以做到这一点.流行方式包括:

• 每个用户的单独盐,与其他详细信息一起存储在数据库中: hash = hashfunction(salt + password)
• 全局盐和每个用户的一些独特价值:hash = hashfunction(salt + password + user_id)例如
• 全球盐和每用户盐: hash = hashfunction(global_salt + user_salt + password)

拥有全局盐可能会增加一些额外的复杂性来破解密码,因为它可能存储在数据库之外(例如,在代码中),攻击者可能无法在数据库泄露事件中获得访问权限.在密码学上我认为它不会增加太多,但在实践中它可能会减慢它们的速度.

最后,回答你的实际问题:

将盐与用户数据一起存储不会削弱散列.散列函数是单向的:给定密码的散列,即使是未加密的密码,也很难找到密码.salting背后的动机不是使单个哈希更安全,而是使多个哈希的集合更安全.对于一组未加盐的哈希,有几种攻击方式:

• 彩虹表
• 散列常用的密码(123,password,god),如果任何存在于数据库中看到的,然后妥协的账户
• 在数据库中查找相同的哈希值,这意味着相同的密码(可能)

Answer 2

Salt用于增加攻击者必须花费的时间来查找与数据库中存储的哈希匹配的密码.通常使用诸如彩虹表(参见http://en.wikipedia.org/wiki/Rainbow_table)之类的查找表来实现此目的.

花费时间不是查找本身,而是计算彩虹表的时间.添加盐迫使攻击者重新计算新的彩虹表,即使攻击者知道它会破坏数据库