我一直在阅读LANMAN (LM) 哈希，我对算法的特定部分感到好奇。
LM 哈希计算如下：
链接的 Wikipedia 文章中概述了许多安全漏洞，并在其他地方进行了讨论，但我对第 3 步到第 6 步特别感兴趣。我很好奇是什么导致了这种设计。拆分密码，分别加密两半，然后将两半组合起来再次形成一个散列，有什么真正的安全优势吗？或者这只是“通过默默无闻的安全”的一个例子？
拆分密码是一个弱点，而不是一个优势。它允许独立破解每个密码一半。从 ASCII 字符（包括 32 到 126 的代码）开始，然后删除小写字母，您将在密码字母表中得到 127-32-26 = 69 个可能的字符。这导致69 7可能的一半，略低于2 43。换句话说，这很容易通过蛮力处理。你甚至不需要字典。
这不是通过默默无闻的安全。这是无能带来的不安全感。
编辑： “非常易于使用蛮力”也为各种优化开辟了道路。请注意，LanMan 没有加盐，因此预先计算的表可以很有效（您支付一次建表的成本，然后您攻击了几个半密码——实际上即使是一个密码也是值得的，因为一个密码是两个半密码。密码）。2003 年，Philippe Oechslin 发表了改进的时间记忆权衡（在这篇文章中他创造了“彩虹表”一词）和用于破解 LanMan 密码的计算表。他限制自己使用字母数字密码（字母和数字，但没有特殊符号），因此空格为2 37. 表的累积大小为 1.4 GB，破解效率为 99.9%，攻击时间不到一分钟。
使用2 43空间，即大 64 倍，表大小和攻击时间都增加了 16 倍（即64 2/3），所以我们谈论的是 23 GB 左右（这对于今天的磁盘来说并不多）和 15 -分钟攻击。实际上，攻击会比这更快，因为瓶颈是在硬盘上查找，聪明的攻击者会使用 SSD，它的查找速度比机械硬盘快 50 倍（32 GB SSD 成本低于70 美元...）。建表工作（一次性支出）在一台 PC 上可能需要几周时间，在任何体面的云上可能需要几天时间，所以它相当便宜。
显然，这样的表已经存在......
将密码拆分为散列并不是一个优势。这样做的原因不明，如今已不再适用。
LanMan 散列以这种方式工作的原因是因为 LanMan 散列是建立在 DES 之上的。DES 接受 56 位密钥。因此，将 7 个字节的块视为构成 DES 密钥是很自然的。使用 DES 一次散列超过 7 个字节没有什么好的方法，我们需要一些方法从 DES 中为更长的密码构建散列，因此 LanMan 散列的设计者决定将密码分成两半。
今天，我们永远不会以这种方式构建密码哈希。我们只需使用 Bcrypt、Scrypt、PBKDF2 或类似的东西——或者我们会基于现有的原语构建类似的东西，比如 SHA256。但当时 Bcrypt、Scrypt、SHA256 等都不存在，这为 LanMan 设计者提供了犯下这种毁灭性错误的机会。
按照现代标准，LanMan 哈希是一个糟糕的设计。有很多 很多 攻击它。它很弱。如果可以避免的话，今天没有人应该使用 LanMan 哈希。（正如其他人指出的那样，即使按照当时的标准，它的安全性也很糟糕。这是公平的。）
仅仅因为某些东西更复杂并不一定会使它更安全。我在我的 windows 盒子上运行了一个密码破解程序，它似乎将密码分解为 8 个字符串，并且它独立于另一个字符串破坏了每个字符串，使得这个过程变得非常快。
因此，从实际的角度来看，拆分密码是没有好处的，@Thomas 已经解释了为什么它在数学上没有好处。