这是一种自滚散列/混淆方法吗?你能认出图案吗?

信息安全 加密 哈希 混淆 黑盒子
2021-08-18 15:43:33

我们引入组织的系统没有使用我能找到的任何传统散列函数。我已被分配通过黑盒测试“批准”它。

我怀疑密码只是被混淆或加密(未散列),因为结果的长度随密码长度而变化(尽管似乎有一些最小值 - 也许是填充?)。

这是一些数据:

密码:结果
1:TG3432WB7VU=
11:r8ahLkJGWbY=
111:E7fXdNqEWAA=
11111111:FIcx3a00R4e GhFyHjD56qw==
1111111111:FIcx3a00R4e vxqEuQkZZtg== 
2111111111:GPwnH80qEAC vxqEuQkZZtg==

结果显然是 base64,但不会解码为任何可读的。在我知道结果的长度发生变化之前,我尝试将解码后的字节视为 MD5 和其他散列函数,但这显然没有成功。现在我知道结果长度会发生变化,我正在考虑其他更糟糕的替代方案。值得注意的是上面的两个粗体部分:它们在两个不同的密码中是相同的。因此,要么每 8 个字节都被独立处理(为什么?),要么正在进行一些多字母替换(?)。

更新:

系统接受任何字符(包括 Unicode 字符)作为密码。将一个 3 字节字符重复 8 次确实会产生一个 24 字节长的“散列”。

4个回答

我高度怀疑这是一种自发的方法,或者至少是非常过时的方法。按照现代标准,它非常弱,不应该用来保护任何重要的东西。

不超过 2^64 次暴力破解可以破解短密码,即使是普通计算机也很有可能。如果结果的两半是独立的,即使密码相当长,2*2^64 次暴力尝试也可以破解它(所以 2^65 次尝试)。该算法可能存在进一步的弱点,使其比此处描述的更弱。

另一个有趣的测试点是 2111111111 并查看结果的第二部分是否保持不变。如果第二部分没有变化,这绝对是一个弱算法。

编辑:

看到2111111111测试的结果和后半部分一样,这绝对是弱算法,不应该用来保护敏感的东西!我在下面包含了相关的比较:

  • 1111111111 : FIcx3a00R4evxqEuQkZZtg==
  • 2111111111 : GPwnH80qEACvxqEuQkZZtg==

编辑:

另一个有趣的测试是 Ricky Demer 在下面提出的建议:

接下来要检查的是它是否以相同的方式处理 8 字节块。aaaaaaaabbbbbbbbc 和 bbbbbbbbaaaaaaaac 的“哈希”是什么?- Ricky Demer 2 月 25 日 6:44

如果它以相同的方式处理 8 字节块,那么即使是长密码,无论长度如何,情况都会变得更糟。正如尼尔在评论中指出的那样,它只需要 2^64 次蛮力尝试。一旦有人列出了每种可能性的计算结果,该算法实际上将毫无用处。这个算法可能还有更多的弱点有待发现。

底线:

无论上次测试的结果如何,我都不建议使用此算法。我们已经看够了,知道它很弱。具有更高位加密/哈希方案、盐、长计算时间等的东西会好得多,我建议使用现有的经过彻底测试的方法之一。自卷式加密/散列没有像大多数主流方法所具有的广泛测试的好处。

编码字符串的长度取决于相应密码的长度这一事实表明了一个更严重的弱点:密码似乎被混淆而不是散列

这意味着任何知道系统内部的人都可以立即解密任何密码!这意味着很多:你必须信任曾经在系统上工作过的开发人员,源代码必须永远保密(这就是你审查黑匣子的原因)等等。

混淆算法有多好并不重要(而且 2 64并不完全是一流的)。它被设计破坏了。

Kerckhoffs's_principle显然适用:密码系统应该是安全的,即使系统的所有内容(除了密钥)都是公共知识。

这本身就足以让您说“如果没有更多信息,我无法批准这个系统”。

从您的示例中,似乎输入分为 8 个字符/字节的块,每个块单独散列并将输出放在一起,然后整个结果是 base64 编码的。

情况不妙。大多数超过 8 个字符的密码只有几个字符。这意味着攻击者可以非常轻松地破解第二个区块。当你知道第二个块时,你对第一个块可以包含什么有一个强烈的暗示。

加密社区几十年前就发现了这一点,将不再独立散列区块。这意味着这些程序员不是最新的加密。

唯一的好消息是密码中的单个字符更改会更改其整个输出块。这可能意味着他们实际上是在散列密码,而不仅仅是混淆密码。尽管如此,由于上述弱点,世界上最好的散列函数无法拯救算法。

看起来像一个简单的分组密码,绝对不是你想要使用的东西。比较它,而不是散列密码,只需使用例如 base64 对它们进行编码/混淆。这不是你想做的事情。如果有人甚至应用过简单的密码分析,他们可以很容易地发现它们只是过去使用 base64 的足够字符。