|
|
1
239
彩虹表的要点是,它们是预先创建的,并集中分布,以节省其他人的计算时间-在运行中生成彩虹表所需的时间与直接破解密码+盐组合所需的时间一样长(因为生成彩虹表时所做的实际上是预运行计算因此,通过知道盐可以“生成彩虹表”的说法是错误的。 在单独的文件中存储盐没有真正的意义,只要它们是基于每个用户的基础上-盐的意义只是简单地使之成为一个彩虹表不能打破数据库中的每个密码。 |
|
|
2
33
我将提供一个略有不同的看法。 我总是把盐和盐密码散列一起存储。 例如,我将把盐的前半部分放在密码的盐散列之前,将盐的后半部分放在密码的盐散列之后。应用程序知道这种设计,因此可以获取这些数据,并获得salt和salt密码散列。 我采用这种方法的理由是: 如果密码/散列数据被破坏并落入攻击者手中,攻击者将不知道SALT从数据中是什么。这样一来,攻击者实际上无法执行暴力攻击以获取与哈希匹配的密码,因为他不知道要以哈希开头,也无法知道哪些数据部分是salt的一部分,或者是salt密码哈希的一部分。( 除非他知道应用程序的身份验证逻辑 ) 如果salted密码散列按原样存储,则可以执行暴力攻击以获取一个密码,当salted和hashed产生与salted密码散列相同的数据时。 但是,例如,即使salted密码散列按原样存储,但预先挂起一个随机字节,只要攻击者不知道第一个字节将被丢弃,这也会增加攻击的难度。当用于验证用户身份时,应用程序将知道丢弃数据的第一个字节。 结论…… 1)永远不要将您的身份验证应用程序使用的数据以其准确的形式存储。 2)如果可能的话,对您的认证逻辑进行保密以增加安全性。 再往前走一步…… 如果您不能对应用程序的身份验证逻辑保密,那么许多人都知道您的数据是如何存储在数据库中的。假设您已经决定将盐密码散列与盐混合存储在一起,其中一些盐在盐密码散列前面,其余的盐在散列后面。 当生成随机的salt时,您还可以随机决定在salt密码哈希之前/之后要存储的盐的比例。 例如,生成512字节的随机salt。您将salt附加到您的密码,并获得您的salt密码的sha-512哈希。您还可以生成一个随机整数200。然后存储前200个字节的salt,然后存储salt密码散列,最后存储其余的salt。 当验证用户的密码输入时,应用程序将传递字符串,并假定数据的前1个字节是salt的前1个字节,然后是salt散列。这个通行证将失败。应用程序将继续使用数据的前2个字节作为salt的前2个字节,并重复,直到在使用前200个字节作为salt的前200个字节后找到正结果。如果密码错误,应用程序将继续尝试所有排列,直到找不到为止。 这种方法的优点是: 提高了安全性—即使您的身份验证逻辑已知,但在编译时确切的逻辑是未知的。即使知道确切的逻辑,也几乎不可能执行蛮力攻击。增加盐的长度将进一步提高安全性。 这种方法的缺点是: 由于确切的逻辑是在运行时推断出来的,所以这种方法占用大量CPU。盐的长度越长,这种方法的CPU使用量就越大。 验证不正确的密码将涉及最高的CPU成本。这可能会对合法请求产生反作用,但会提高对攻击者的安全性。 这种方法可以以各种方式实现,并且可以通过使用可变宽度的salt和/或salted密码散列使其更加安全。 |
|
|
3
22
通常情况下,它们被预先添加到散列并存储在同一个字段中。 不需要单独存储它们——重点是对每个密码使用随机的salt,这样就不能对整个密码哈希集使用单个彩虹表。对于随机的盐类,攻击者必须对每个散列值分别强制执行(或者为所有可能的盐类计算一个彩虹表——要做的工作要多得多)。 如果您有一个更安全的存储位置,那么只将散列存储在那里是有意义的。 |
|
|
4
4
基于William Penberthy的《开发ASP.NET MVC 4 Web应用程序》一书:
|
|
|
5
0
盐的作用是使所有彩虹桌都变得无用,并要求制作一套新的彩虹桌。
猜一根绳子就像做一张彩虹桌一样长。
例如,“password”的sha-256哈希是
通常,salt与密码存储在同一个数据库中,也因为如果一个数据库被黑客攻击,另一个数据库也很可能被黑客攻击。 |