问这是最安全的加密/哈希系统吗？

EN

是的，如果操作得当，您设计的系统应该会提供少量的安全增益，但这可能不是最好的选择。

扩充后的版本：

当我们将安全设计成一个系统时，我们首先开发一个威胁模型，然后我们就会知道我们的系统将如何减轻这些特定的威胁。因此，问题是：“您试图保护系统免受的威胁是什么?这种设计是否合理地减轻了这种威胁？”“合理”意味着有效地将威胁降低到可接受的风险水平，而不增加过多的成本或复杂性。

因此，在我看来，您想要防范的具体威胁是攻击者从web应用程序数据库中丢弃密码哈希和盐类。

如果我们想规定攻击者有能力在应用程序的上下文中查询数据库，这是一个有效的问题。然而，总的来说，我建议我们实际上没有规定这一点。这导致攻击者能够访问各种潜在的特权数据，并且在系统中添加复杂性以保护这一个目标(散列和盐类)，而不添加复杂性来保护其他特权数据，这并不会使sense...Unless --该数据比数据库中的任何其他数据更有价值。相反，我们通常希望我们的威胁模型枚举攻击者非法访问数据库这一更为普遍的威胁，并作为一个整体加以保护。

不过，让我们继续将其添加到威胁模型中，将其作为需要缓解的有效威胁，因为您的缓解机制是您最初真正面临的问题。

那么，是否将密码验证移到一个单独的系统上，并且该系统只公开提供密码甲骨文的API是抵御此威胁的有效方法？是。它是。在特殊目的的硬系统中隔离敏感数据是信息安全的标准模式，就像我们在硬件安全模块中存储密钥的方式一样。然而，在这种情况下，对于一个相当小的威胁来说，增加成本和复杂性是很大的，所以我不知道我是否会推荐它，但是它肯定有一些(小的)潜在的安全优势。

然而，这并不是唯一可以用来减少这种威胁的机制。根据数据库引擎的不同，您可能可以使用类似于存储过程的内容为您验证密码，并且至少拒绝应用程序对密码散列的访问，因此它们不能转储，盐类只能单独检索。您甚至可以让数据库为您计算验证，并且不允许应用程序访问散列或盐类，从而有效地实现您所设定的完全相同的目标，而不需要复杂的额外系统。

或者，您可以使用非常流行的身份和身份验证联合方式，完全取消存储密码散列和盐类。在企业环境中，您可能有一个联邦提供程序，它允许您委派身份验证，而可以处理类似SAML令牌的事情。在网络世界中，您可以使用OAUTH，让Google和Facebook等公司担心凭据管理和身份验证，您根本不需要密码，完全消除了这一特殊威胁。

脱机/本地加密/散列服务器。假设这是一个用户在网站上注册自己>，而不是当前站点哈希和存储密码。

这会向未知服务器公开密码，密码本身的安全性未知。最好永远不要通过电报发送密码。为此，您可以使用java脚本散列脚本。

站点向散列服务器发送请求(其中包含散列>算法和salt)。我还没有找到服务器之间最安全的通信方式。

两个连接意味着两条窃听线路。因此，它的安全性总是低于1连接。(两者都会产生登录凭据，因此两者都很有趣)

哈希服务器然后使用散列密码进行响应，然后站点将其>存储在数据库中。这样，即使黑客知道系统，取决于>您是如何配置散列服务器的(我也缺少关于>配置服务器的一些信息)，黑客也无法计算出您的散列/盐分。

这也可以通过简单地用咸散列重新散列来解决。(基本上是在验证哈希之前向哈希添加一个盐分，这样从DB窃取的散列不会产生访问令牌。)

这主意不错。但你的想法并没有增加很多的安全IMHO。

也许其他人有不同的观点/指针。