非常简单——所以我们使用彩虹表从哈希中获取用户密码。那么微软为什么不对 Windows 中的密码实施加盐hash(password+salt)
呢?
至少在处理本地用户密码破解时在 SAM 文件上实现时,这种实现不会节省很多麻烦吗?
非常简单——所以我们使用彩虹表从哈希中获取用户密码。那么微软为什么不对 Windows 中的密码实施加盐hash(password+salt)
呢?
至少在处理本地用户密码破解时在 SAM 文件上实现时,这种实现不会节省很多麻烦吗?
Microsoft 操作系统中的密码处理很复杂,因为它们将密码用于多种用途。操作系统(或其域控制器)将存储密码的散列版本,但也有一些值使用从密码或其散列派生的密钥进行对称加密。当某些散列必须在客户端发生时,身份验证协议不包括交换盐的规定。在不影响大量子系统并可能破坏向后兼容性的情况下,很难更改密码处理算法,而向后兼容性是Windows 生态系统的驱动力。
它归结为战略重点。Microsoft 知道更改密码散列和身份验证协议以包含盐将产生一些不可忽略的成本,他们必须承担这些成本(通过修复所有因此受影响的组件)。另一方面,不更改密码散列对他们来说是相当“免费”的,因为不稳定的散列算法不会说服客户切换到其他非微软系统(操作系统市场实际上是一个专属市场);迫使潜在客户设想一个非常昂贵的操作系统开关需要更多的时间。此外,密码散列可以说是“深度防御”,只有在已经发生违规行为时才会产生任何影响的第二层;因此,它可以被认为是次要的。因此,如果令人恼火,微软不会更新其糟糕的密码处理实践是合乎逻辑的。
从历史上看,微软只做了一次更新,当他们从NTLM v1 切换到 v2 时,这是有必要的,因为旧的 LM 哈希太弱以至于开始令人尴尬。我的猜测是,这涉及到很多内部麻烦,他们并不急于再做一次。
Microsoft 系统模型与通常的“网络”(以及较小程度的 UNIX)模型有很大不同——在 MS 世界中,通常您拥有许多在您自己控制下的机器,它们与几个中央存储库紧密绑定,并且您'很可能知道他们很多时候在哪里。(这在涉及 IIS 时确实会出现问题;然后,许多 Web 应用程序都进行自己的用户控制。)
正如另一个答案中提到的,微软的哈希传统上很弱,并且可能保持这种方式是为了向后兼容。但这对他们的安全模型也不是很重要——在微软模型中,更改密码相对来说是微不足道的。强制更改所有密码相对简单。您还有一种有效的密码过期方法(因此任何丢失的哈希值都会很快失去其价值,肯定会在 1-2 个月内)。
您还在一个仁慈的管理员通过计算陷阱听到非技术用户的世界中运作;仅举一个例子:不加盐意味着您可以让用户更新他们的密码,而不能与域控制器对话,并且域控制器可以通过查看用户的当前凭据(用户+域+新密码)和他们以前的凭证。这是一个很大的好处,因为它意味着用户体验(每xxx天更改一次密码)不会因网络访问而改变。
您可能对微软对其密码系统的技术解释感兴趣。