在密码安全方面，人们同意一些事情，例如存储密码的加盐哈希，这可以针对受损模型和数据提供统计防御。
有些人似乎不同意如何处理盐。您可以采取无数种技术来尝试保护盐，但许多专家会认为它们只是对安全模型的毫无意义的混淆，并且随着时间的推移该模型将被暴露，我发现自己不同意有了这个，但我可能不理解其他观点。
我不明白的是，如果您的模型受到损害，为什么要假设完全妥协而不是部分妥协？如果您的安全模型分布在不同的基础设施中，这些基础设施的安全性并不相同，那么部分妥协甚至可能不是问题。（如果您执行诸如加密盐之类的操作并从不太可能被破坏的更安全的环境中检索加密密钥）
我假设这里的妥协并不总是 100%。我从来没有被黑客入侵过，也从来没有被黑客入侵过，所以我没有完整的画面。
如果您的模型受到损害，为什么要假设完全妥协而不是部分妥协？
您应该始终假设安全方面的最坏情况。这是最安全的方法。
部分妥协甚至可能不是问题
也许。但是你真的确定吗？
在您的 OP 中，您的分析基于太多假设。也许在一个非常具体的设置中，您认为部分妥协可能不是问题的评估可能是合理的。
但是话又说回来，您假设攻击者不足以找到漏洞。
不要将您的安全模型建立在假设之上。
混淆和加密的最大区别在于，混淆的内容可以被澄清，而不需要混淆信息之外的任何东西——只要你能弄清楚你正在查看的数据类型，那么你就可以找到一种方法来澄清它.
与此同时，加密只能使用正确的密钥/密码/破解工具解密。没有这些东西的加密数据是非常安全的。
因此，混淆最多只能减缓一个坚定的攻击者，尽管它可能会推迟一个不太坚定的攻击者。围绕系统和服务器的安全性，您可以做许多更容易和更易于维护的事情，以加强它们免受不那么坚定的攻击者的攻击，因此在我看来，为您和您的系统增加额外工作的混淆成本很少是合理的。
假设发生妥协时不是 100% 是一项非常冒险的尝试，因为您实际上假设的是您比攻击者更聪明，更了解您的系统。你可能是对的，但如果你假设它并且你错了，那么你确实有非常严重的麻烦。你必须证明它，并且考虑到证明否定的问题，当发生妥协时，就好像你已经完全受到危害一样行事，并设计你的系统，使它们尽可能安全，即使在总妥协已经发生。
通过默默无闻的安全，充其量是一场赌博。将盐存放在其他地方是否值得？大概。但是当您开始进入这些多步骤安全设置时，您必须考虑成本与回报。我想说，如果您的应用程序需要它，您会知道的。否则，为了获得超强的安全性而在应用程序中添加更多步骤可能只会在出现问题时让自己头疼。不是每个人都需要 NASA 级别的系统安全性。这并不是说安全不重要。只是您需要根据当前环境对其进行调整。