对，但是..

为了让它变得清晰明了......我们谈论的是当攻击者可以访问数据库但不能访问应用程序源代码时的仅数据库妥协。在这种情况下，攻击者将获得密码哈希，但由于 Dave 的自定义算法，将无法破解它们并获得原始密码。因此，在仅数据库泄露的情况下，是的，Dave 的密码算法将比他使用 MD5 或 SHA1 更能保护密码。

然而，这只是系统泄漏的一种可能途径。有一个关键事实破坏了使 Dave 的自制算法看起来合理的“数学”。

一半的违规行为始于内部。

（来源1 2 3）这是一个非常发人深省的事实，一旦你让它沉入其中。在员工造成的一半违规中，一半是偶然的，一半是故意的。如果您担心的只是数据库泄漏，Dave 的算法会很有帮助。如果这就是您所担心的全部，那么您在脑海中保护的威胁模型是错误的。

仅举一个例子，根据定义，开发人员可以访问应用程序源代码。因此，如果开发人员获得了对生产数据库的只读访问权限，他们现在拥有轻松破解密码所需的一切。Dave 的自定义算法现在没用了，因为它依赖于旧的且易于破解的哈希。

但是，如果 Dave 使用了现代密码散列算法并同时使用了盐和胡椒，那么获得仅数据库转储访问权限的开发人员将完全没有任何用处。

这只是一个随机示例，但总体要点很简单：现实世界中发生了大量数据泄漏，当 Dave 的算法无法阻止时，适当的散列可以阻止实际损坏。

总之

这一切都与深度防御有关。很容易创建一种可以防止一种特定类型的攻击的安全措施（Dave 的算法在防止仅数据库泄漏方面比 MD5 略有改进）。但是，这并不能使系统安全。许多现实世界的违规行为非常复杂，它们利用系统中多个点的弱点来最终造成一些真正的损害。任何以“这是我必须担心的唯一攻击向量”（这是 Dave 所做的）假设开头的任何安全措施都会使事情发生危险的错误。

这并没有具体回答有关 Dave 协议的问题，但我想为世界各地正在编写自己的哈希的 Dave 解决更普遍的问题。戴夫斯，您需要意识到以下几点：

1. 你不是密码学家。这不是对你的轻视；我也不是。但即使你是密码学家，你也必须是世界上最好的，才能确保你的算法没有可能危及安全的缺陷，因为即使是专家也会搞砸很多（ 所有四个词都是单独的链接） . 除其他外，哈希中的潜在缺陷包括：
   • 意外的可逆性。也许您不是故意的，但是您将太多信息放入“哈希”中，现在即使没有蛮力，也可以轻松反转。对于一个“复杂”算法的例子，它很容易反转，看看线性同余生成器。
   • CPU、GPU、ASIC 等没有足够的复杂性。这很难做到；只有三个库来进行密码散列是有原因的，它们都基于相同的想法。除非您非常熟悉GPU 和 ASIC 的工作原理，否则您很可能会构建在 GPU 上比 CPU 运行得更快的东西，从而立即否定您拥有的任何其他保护。
   • 你实际运行它的地方太复杂了，再加上最后一点。很容易指出你的性能测试并说，“看，我需要 30 秒来做 30 次哈希，太棒了！” 除非您再次不是密码学家或 GPU 开发人员，因此您没有意识到您的复杂加法和乘法实际上可以很容易地在 GPU 上复制，因此它们可以在 30 秒内破解 3000 万个哈希，同时 DoSing通过尝试每秒多次登录来提供您的服务。
   • 均匀度不够。当输入不同的输入时，理论上完美的密码哈希函数的输出与真正的随机数生成器的输出无法区分。在实践中，我们不能完全到达那里，但我们可以非常接近。你的算法可能不会。不，“看起来”随机并不意味着它实际上足够接近；如果你没有足够的经验来编写自己的秘密加密以获得“更好的”安全性，那么你就没有足够的经验，不知道如何发现真正的随机性。
   • 即使您完全使用良好、可靠的加密原语构建算法，您仍然可以将它们错误地组合在一起。
2. 你不是网络安全程序员。可能有一个更好的词，但重点是，您没有专门编写正确实现算法的代码，即使是像您自己的代码。有关仅从数据库中可以看到的可能问题的非常简短列表，每个问题都链接到“[item] 攻击”的第一个 Google 结果：
   • 频率分析
   • 已知明文
   • 数据剩磁

所有这些都只是专门考虑对数据库的离线攻击，而这种想法是由一个甚至没有主修网络安全的大学生完成的。我向你保证我错过了很多东西。我已经完全跳过了 MITM、恶意客户端等的所有其他攻击媒介。我也省略了提及即使您使用现成产品也可能发生的每个错误；将其视为读者的练习，以弄清楚如何使用甚至是好的加密错误。最后，我完全省略了开发人员使用加密的常见错误类别，而他们应该使用hashes，我偶尔会看到这种错误。

所以，总而言之，Dave，每当你认为你有一个最好的想法来为你的生产代码使用一个秘密的内部哈希，而不是使用一个标准的、现成的、公开的、经过全面测试的产品， 记住这一点：

你没有。

只需使用 bcrypt。（或氩气2）

（附带说明，如果您只是为了娱乐和/或自学而构建算法，请随意忽略所有这些。构建自己的算法来保护生产中的密码是危险的，因为您将构建一个弱算法这几乎没有提供任何保护。构建自己的算法以查看是否可以破解它是打发时间、激发思想甚至学习一些加密货币的好方法。）

在破坏数据库而不是源代码的情况下，与普通的 SHA1 相比，Dave可能会使事情变得更好。但...

1. 正如Conor Mancone 解释的那样，源代码也很可能被泄露。

2. 自制软件可能会搞砸哈希，使其比普通的 SHA1 更不安全。天知道 Daves 奇怪的装置如何与散列算法的内部相互作用。如果不出意外，Dave 已经为追随他的人制造了一个小小的维护地狱，而大混乱对安全从来没有好处。

3. 它给人一种虚假的安全感。如果 Dave 没有为他的出色解决方案感到骄傲，他可能会花时间阅读如何正确地进行密码散列。从这个问题中，很明显 Dave 认为他所做的比说 bcrypt 更好。它不是。

4. 自制算法提供的一点额外保护可以用胡椒代替。这在所有可能的方面都比自制算法好。

所以是的，在某些非常特定的情况下，自制软件可能比 SHA1 更好。如果平均而言更好是一个悬而未决的问题，但答案并不重要。关键是它与真正的密码哈希算法相比是可怕的，而这正是家庭酝酿阻止 Dave 实施的原因。

长话短说，戴夫搞砸了。

TLDR：如果您看不到加密的值，不安全的加密甚至都不安全。

其他帖子很好地解释了为什么你不应该在攻击者可以看到加密值的环境中编写自己的加密货币的原因，但他们错过了一些非常重要的事情：你也不应该编写自己的加密货币当攻击者看不到加密消息时。

有一种东西叫做“侧通道”。侧通道是（通常是¹）意外的事情，会泄露有关您的应用程序正在做什么的信息。例如，将部分正确的密码与“加密的” ²值进行比较可能需要更多的 CPU 周期，因此需要更多的时间。这将使攻击者加速暴力攻击以慢慢学习正确的密码。

让我们举一个幼稚的例子。假设需要 1 秒来测试提交密码的单个字符与存储在数据库中的值。假装正确密码长度为 8 个字符，无效密码在第一个错误结果时被拒绝。该算法可能类似于：

boolean encrypt_password(string password) {
    if(not isascii(password) ) { return false; } // ERROR! 
    string result;
    foreach(char c : password) {
        result += daves_magic_that_takes_1s(c)
    }
    return true;
} 

boolean is_correct_password(input, pw_from_db) {
    if(input.length != pw_from_db.length) { return false }
    foreach(char c_in, c_db : input, password) {
         c_in = daves_magic_that_takes_1s(c_in)
        if(c_in != c_db){ return false}
    }
    return true; // valid password!
}

现在，让我们假设有效密码是“password”，攻击者尝试输入“a”。这失败了，因为密码长度错误。攻击者可能会随机尝试各种密码。每个比“密码”长或短的错误密码都需要不到一秒钟的时间来处理。假设他们很快就会尝试“12345678”。“12345678”与“密码”的长度相同，因此需要一秒钟的时间来处理。时机不同，攻击者会注意到。他们又试了几次来验证，结果是一致的。

攻击者现在尝试了几个 8 个字符的密码。它们都需要 1 秒。攻击者发现了一个侧通道，告诉他们有效密码可能是 8 个字符长。现在他们需要确定哪个 8 个字符的密码是正确的。

攻击者开始随机尝试 8 个字符的密码。最终，他们尝试“p2345678”并注意到这需要 2 秒才能完成。他们测试了一堆，发现所有以“p”开头的尝试都需要 2 秒才能完成。攻击者猜测该算法有一个侧通道，告诉他们他们有多少字符是正确的。

现在，攻击者不必尝试所有 96^8 密码来暴力破解有效密码，而只需尝试 96*8 密码³。根据可以并行测试的密码数量，他们可能可以在非常合理的时间内成功地暴力破解密码。这对攻击者来说很棒！这对您系统的安全性很不利。⁴

我们如何防止时序侧信道？我们保证所有计时会泄漏敏感信息的操作必须始终花费相同的时间来执行。

这可能看起来像一个非常简单的例子。它发生在野外。在 NVD 中搜索“定时侧通道”会得到许多真实世界的漏洞，这些漏洞都会产生相同的结果，从而使攻击者能够了解他们未授权的秘密信息。根据定义，如果无论输入如何，所有操作都花费相同的时间，那么某件事所花费的时间并不能告诉您有关输入的任何信息。

在现实世界中，侧通道非常容易引入。Dave 可能甚至没有听说过它们，并且可能是一位关心他的系统性能的优秀工程师——这实际上是一种用于防止侧信道的反模式。Dave 的算法很可能同时具有他永远不会发现的明显和微妙的侧通道，但研究人员和攻击者知道要寻找，并且可以很容易地编写自动化测试来检测。⁵

因此，仅仅因为您看不到加密并不意味着您看不到不良加密的副作用，并使用这些副作用来学习受保护的秘密。

尾注

^{1：好吧，如果你是一名情报人员或一名优秀的报纸记者，你可能会故意设置旁道，以便在“敌人”不知情的情况下与你的特工/消息来源进行交流。同样，如果你是狡猾的，你可能会创建一个带有侧通道的加密协议，目的是泄露秘密信息。}

^{2：由于我们可以并且应该始终假设自定义加密是不安全的（由于其他人在此线程中提到的原因等等），我们可能不应该将自定义加密算法的使用称为“加密”或“解密”......也许“不安全的加密”或“破解解密”......}

^{3：为了描述的简单起见，我忽略暴力攻击成功，平均而言，当攻击者尝试了 50% + 1 个密码时。我专注于侧通道，而不是蛮力攻击。我还掩盖了蛮力攻击的数学，因为这也与主要话题相切；一些代表读者的 Google-Fu 应该找到大量深入细节的资源。}

^{4：“1 秒太慢了”，对吧？没有现实世界的系统可以通过互联网检查现实世界的计时侧通道，对吧？错误的。我手头没有参考资料，但是多年来的研究表明，您可以统计测试 HTTP 事务上毫秒级的时间。}

^{5 事实上，如果您要使用 Google-Fu，我愿意打赌，您可以使用框架或现有工具（很可能两者兼有）来测试您的应用程序的明显侧通道。}