密码,哈希和密码问题,全部noob?

您的问题是如何使用密码作为身份验证机制,以及如何使用哈希将这些密码安全地存储在数据库中。正如您可能已经知道的那样,目标是能够在不存储这些密码的情况下验证密码,我会在数据库中清除文本。在此背景下,我试着回答你的每个问题:

如果有人可以访问您的数据库/数据,那么他们仍然需要找出您的散列算法,并且您的数据仍然是安全的,这取决于您的算法?他们所要的只是土豆泥和盐。

散列密码的基本思想是攻击者知道散列算法,并且可以访问散列和salt。通过为每个密码选择不同的加密强散列函数和适当的salt值,猜测密码所需的计算工作量非常大,以至于成本超过了攻击者猜测密码时可能获得的收益。所以为了回答您的问题,隐藏哈希函数并不能提高安全性。

如果有人可以访问您的数据库/数据和源代码,那么不管您做什么,您的哈希算法都可以进行反向工程,您唯一能做的就是您的算法有多复杂和耗时?

您应该始终使用一个著名的(并且很强的)哈希算法,并且反向工程这个算法是没有意义的,因为您的代码中没有隐藏的东西。如果你不是故意的 逆向工程 但实际上 颠倒 然后,是的,密码受到逆转散列函数(或猜测与散列值匹配的密码)的复杂性的保护。好的散列函数使得这非常困难。

看起来最薄弱的环节是:你自己的系统有多安全,谁可以访问它?

一般来说,这是正确的,但是当涉及到通过将密码存储为哈希来保护密码时,您仍然应该假设攻击者具有对哈希的完全访问权,并通过选择适当的哈希函数和使用salts来相应地设计您的系统。

这些散列试图防范哪些类型的攻击?我读过彩虹表和字典攻击(蛮力),但是这些攻击是如何管理的?

密码散列保护的基本攻击是当攻击者访问您的数据库时。无法从数据库中读取明文密码,并且密码受保护。

更复杂的攻击者可以生成可能的密码列表,并使用与您相同的算法计算散列值。然后,他可以将计算出的哈希值与存储的哈希值进行比较,如果找到匹配项,他就拥有有效的密码。这是一种暴力攻击,通常假定攻击者对您的数据库具有“脱机”访问权限。通过要求用户使用长而复杂的密码,“强力”密码所需的工作量显著增加。

当攻击者不想攻击一个密码,而是要攻击数据库中的所有密码时,可以预先计算一个大的密码表和哈希值对,并使用所谓的哈希链进一步改进。彩虹表是这个想法的一个应用程序,可以用于在不显著增加工作量的情况下同时强制执行许多密码。但是,如果使用一个唯一的salt来计算每个密码的散列值,则预计算的表将变得无用,因为它对于每个salt都是不同的,不能重用。

综上所述:模糊安全并不是保护敏感信息的好策略,现代密码学允许你不必借助模糊来保护信息。

密码算法的安全性总是在其秘密输入中。合理的密码分析基于这样一个假设,即任何攻击者都知道您使用的算法。良好的密码散列是不可逆的和抗冲突的。这意味着仍然有很多工作要做,从散列到生成散列的值,不管您是否知道应用的算法。

1. 如果您使用安全散列,那么对散列、salt和算法的访问仍然会为未来的攻击者留下大量工作。
2. 是的,一个安全散列将很难反转算法。请注意,此反转不是“反向工程”。
3. 薄弱环节可能是将这些密码散列输入数据库的过程和过程。有各种各样的方法可以把敏感数据搞得一团糟。

正如我在评论中指出的,这些措施防范的攻击。首先,知道密码可能会导致授权去做数据库内容所建议的以外的事情。第二,这些密码可能会在其他地方使用,而您会因为闯入而泄露用户的密码,从而使用户面临风险。第三,通过散列,内部人员无法利用对数据库的只读访问(受审核次数较少等影响)来冒充用户。

字典和彩虹表是加速哈希反转的技术。

这些散列试图防范哪些类型的攻击?

当有人从不安全站点获取密码时,将其反转,然后尝试访问您的银行/ PayPal等帐户。这种情况一直在发生,而且许多人仍然在各地使用相同的(通常是弱的)密码。

作为旁注,根据我读到的, key derivation functions (pbkdf2/scrypt/bcrypt)被认为更好/更安全( #1 ,请 #2 )比加密人的纯盐sha-1/sha-2哈希还要多。

如果你只有一个散列,没有盐,那么一旦他们知道你的数据(和算法),他们就可以通过彩虹表查找获得你的密码。如果你有一个哈希和一个salt,它们可以通过消耗大量的CPU周期和构建一个彩虹表来获取你的密码。

如果您的salt对于所有数据都是相同的,那么它们只需要一次消耗大量的CPU周期来构建表,然后就拥有了所有的密码。如果您的salt不总是相同的,那么它们需要在CPU周期中燃烧,为每个记录生成一个独特的彩虹表。

如果salt足够长,那么它们需要的CPU周期将变得非常昂贵。

当然,如果您知道您的数据安全被破坏了,那么您需要立即重置所有密码,因为据您所知,攻击者愿意花费这段时间。

如果有人可以访问您的数据库/数据,那么他们仍然可以 必须找出你的散列 算法和你的数据 有点安全,取决于 算法?他们只会拥有 土豆泥和盐。

这可能是一个真正专注的对手所需要的。这个答案很大程度上取决于数据的价值,这将告诉你对手有多积极。信用卡号码将是非常有价值的,犯罪攻击者似乎有足够的时间和帮凶做他们的肮脏工作。有人知道一些坏人向僵尸网络分发密钥解密任务!

如果有人可以访问您的数据库/数据和源代码, 不管你的 是的,你的哈希算法可以 逆向工程,唯一的东西 你会站在你这边的 您的 算法是什么?

如果他们能够访问您的源代码和所有数据,那么问题将是“您首先是如何将密钥加载到服务器的内存中的?”如果它嵌入到数据或程序代码中,游戏就结束了,你输了。如果它是在机器启动时由操作员手动键入的,它应该和您对操作员的信任一样安全。如果它存储在HSM*中,它应该仍然是安全的。

如果它们具有对正在运行的机器的根级别权限访问权,那么它们可能会触发并恢复一个内存转储,该转储将显示密钥。

似乎最薄弱的环节是:如何 保护你自己的系统是谁 有权使用它吗?

这是真的。但是,还有其他方法可以帮助提高安全性。

对于类似银行的保护,即通过安全和行业审计的保护,建议您使用*硬件安全模块(HSM)来执行密钥存储和加密/解密功能。商业实力的高铁,我们正在考虑成本10万美元或以上,每一个,取决于容量。但我见过插入PCI插槽的硬件加密卡,它的成本要低得多。

HSM背后的想法是,加密发生在一个安全、加固的平台上,没有秘密密钥,任何人都无法访问该平台。它们中的大多数都有带有入侵检测开关、跳闸线、环氧树脂芯片和存储器的机柜,如果被篡改,它们会自动销毁。即使是合法所有者或工厂也不能在没有授权加密密钥集的情况下从HSM中恢复数据库密钥(通常使用智能卡)。

对于非常小的安装,HSM可以像智能卡一样简单。不过,智能卡并不是高性能的加密设备,因此您不能每秒通过它们抽取超过一个解密事务。使用智能卡的系统通常只存储根密钥,然后解密智能卡上的工作数据库密钥并将其发送回数据库访问系统。如果攻击者可以访问正在运行的内存,或者如果攻击者可以嗅探进出智能卡的USB流量,这些数据仍将生成工作数据库密钥。

我还没有让TPM芯片工作的经验,但理论上它们可以用于安全地在机器上存储密钥。同样,当密钥加载到内存中时,仍然无法防御攻击者进行内存转储,但他们会阻止包含代码和数据的被盗硬盘泄露其秘密。

哈希不能反转。从概念上讲,将散列看作是将要散列的值作为随机数生成器的种子,然后将其生成的第500个数作为种子。这是一个 可重复的 过程,但它不是 可逆的 过程。

如果将哈希密码存储在数据库中,当用户登录时,将其密码从输入页提取到登录页,对其应用相同的哈希,然后将该操作的结果与存储在数据库中的结果进行比较。如果匹配,则用户键入了正确的密码。(或者,理论上,他们可能键入了一些哈希值相同的东西,但实际上,您可以完全忽略这一点。)

salt的目的是,即使用户拥有相同的密码,您也无法分辨,而且还有许多其他与此想法等效的东西。如果用户的密码是“secret”,salt是“abc”,那么您可以散列“secret abc”而不是散列“secret abc”,并将结果存储在数据库中。您还可以存储盐,但这是完全安全的存储--您无法从中找出任何有关密码的信息。

保护散列密码和salt的唯一原因是,如果攻击者有散列密码和salt的副本,他可以在自己的计算机上脱机测试密码,而不是反复尝试登录到您的服务器,您可能会在三次尝试或类似尝试后将其锁定。即使你不锁定他,在本地测试也比等待网络往返要快得多。

( 操作 )

如果你的数据 是妥协然后游戏结束…我的 后续问题是:什么类型的 攻击是这些哈希试图 防范?我读过有关 彩虹表和字典攻击 (蛮力),这些怎么样? 实施的攻击

( 讨论 )

这不是一个游戏,除了攻击者。研究这些术语:

• 萨班斯-奥克斯利
• 格莱姆-里奇-布利利法案(GLBA)
• HIPAA
• 数字千年版权法(DMCA)
• 爱国者法案

那么告诉我们(作为对你的思想挑衅)我们如何保护谁?一方面,这是无辜的VIS-A-VIS入侵者的努力,另一方面,如果系统的一部分出现故障,它是数据恢复。

TCP/IP等协议的初衷被宣传为一种战争武器、攻击下的生存能力,这是一个有趣的实验。好吧,所以密码是散列的-没人能恢复它们…

其中,duh,包括系统的所有者和操作员。

因此,您构建了一个强大的记录锁定工具来实现关键控制,然后政治压力迫使使用Brand-X工具。

您可以阅读《联邦信息安全管理法》(Fisma),当您阅读该法案时,某个政府实体的整个磁盘可能被盗或受到损坏。

如果磁盘上有您的个人身份信息,您将如何保护该磁盘?

我可以从马丁利弗塞奇和杰德特斯的口径告诉你,他们会注意的。

以下是我对你的看法:

1. 如果人们有权访问您的数据库,那么您的安全问题就比哈希算法和salt短语更大。哈希在某种程度上是安全的,但是也存在一些问题,例如哈希冲突和哈希查找。
2. 散列是单向的,因此,除非它们能猜到输入,否则即使使用算法和salt,也无法反转原始文本;因此称为单向散列。
3. 安全是关于隐蔽性和防御层的。如果您对防御进行分层并确定哪些防御措施,那么您抵御攻击的可能性比依赖于单一安全方法(如密码散列和运行操作系统/网络硬件更新)要好得多。加入一些曲线,比如Web服务器平台的过时,以及ProdWeb和数据库环境之间的清晰界限。层和隐藏的实现细节为您赢得了宝贵的时间。

当散列密码时,这是一种方法。因此,即使您有大量的CPU周期需要消耗,也很难获得密码。