应用到应用认证/访问控制，无需 HTTPS答案

【问题标题】：Application to Application authentication/access control without HTTPS应用到应用认证/访问控制，无需 HTTPS
【发布时间】：2011-12-06 05:36:16
【问题描述】：

在我正在进行的当前项目中，我们遇到了以下问题。

我们的软件是一个基于位置的服务平台，应用程序可以使用 SOAP 通过我们公开的网络服务连接和使用我们的服务。到目前为止，我们的平台仅由内部应用程序使用，但现在我们希望将其开放给第三方应用程序。为此，我们需要一种身份验证机制。

由于我们客户的基础设施和负载平衡解决方案，我们无法使用 HTTPS。最初的想法是应用程序可以只使用 HTTPS 并发送我们验证的密码。

下一个解决方案是：应用程序有密码。应用程序生成一个随机字符串（盐）并创建一个散列。然后应用程序创建一个发送哈希、盐和时间戳的 HTTP 请求。这三个足以让我们进行身份验证，因为我们可以生成相同的哈希并进行比较。

我的问题是，为此我们需要将密码以明文形式存储在我们的数据库中，因为我们需要使用给定的 salt 执行相同的过程，以便我们可以比较结果并验证应用程序。以明文形式存储密码是不可接受的。

您知道任何适合这种情况的身份验证/访问控制机制吗？一般来说，您知道有关应用程序身份验证/访问控制机制的任何好书/资料吗？

非常感谢任何帮助。提前致谢！

【问题讨论】：

标签： security authentication hash cryptography

【解决方案1】：

应用程序（客户端）可以对密码进行两次散列。请注意，服务器应该生成其他随机盐，而不是客户端！否则，攻击者也可以使用此哈希登录。您还可以通过在数据库中存储特定于密码的盐来使其更安全。

协议：

0) 服务器从数据库中检索该特定密码的 salt，生成 salt2，并将两者发送给客户端

1) 客户端发送hash(hash(password, salt), salt2, timestamp) 和timestamp。

2) 服务器从数据库中检索hash(password, salt) 并进行比较。

请注意，如果您在网络上，攻击者可以不仅可以嗅探，还可以修改流量，如Paulo pointed out，您应该签署每条消息：@ 987654326@ 并在服务器上查看。（例如，对于攻击者可以修改消息以包含删除命令的情况......）

请注意，用户需要安全地设置/更改密码时仍然存在问题。您不能仅使用不安全网络上的散列函数安全地做到这一点，您需要某种密码/解密器。

还要注意哈希函数越慢，越安全（因为字典攻击）。如果你没有特殊的慢哈希函数，你也可以调用普通的快速哈希函数100000次。

【讨论】：

@Aston：请注意：这里使用慢散列函数（至少对于数据库中的散列，但也可能对于外部散列），因此从数据库中获取散列的攻击者可以不要轻易暴力破解密码。因此，使用 scrypt、bcrypt 或 PBKDF2（具有合适的工作因子），而不是简单的快速散列，如 SHA-1、SHA-2（甚至 SHA-3，当它准备好时）。
@Aston，或者更安全的是，salt2 应该由服务器随机生成并发送给客户端。另外，请注意哈希函数越慢，越安全（因为字典攻击）。
@Paulo，啊，我们只是互相交谈 :-)。
这并不比存储明文密码更好：任何获得哈希的攻击者都可以像使用密码一样使用它，而无需额外的哈希层。
@TomasT 是的 - 但可能让破坏数据库的人更难处理密码正是你对密码进行哈希处理的目标 - 你为什么还要这样做？ - 我要指出的是，它绝对不会增加方案的安全性。

【解决方案2】：

您应该使用既定的解决方案，而不是发明自己的解决方案。 SOAP 支持加密身份验证，例如 WS-Security - 请参阅 Craig Forster 对此答案的评论以获取建议。

其他情况下最好的选择通常是oauth；它同时提供授权和身份验证，并处理许多您在构建自己的密码时不太可能发现的加密问题。

【讨论】：

我同意这种观点，但不同意建议的解决方案。基于 SOAP 的 Web 服务应该使用 WS-Security，很可能结合了用于身份验证的 SAML 令牌和用于消息级安全性的 XML 签名和加密。
@craigforster 不知何故，我错过了 OP 正在使用 SOAP。我会更新我的答案。

【解决方案3】：

使用不包含对整个消息（或流）进行完整性检查的身份验证解决方案是不安全的。

虽然最初由 Thomas T. 提出的哈希解决方案（hash(hash(password, salt), salt2, timestamp)，其中hash(password, salt) 存储在数据库中，salt2 是新生成的）确保攻击者无法获取密码（或任何时间戳过期后对登录有用的数据），它本身并不能阻止主动攻击者在身份验证后劫持会话，并发送任何想要的 SOAP 请求（并拦截响应）。

这里需要一些方法来确保不更改任何数据。这称为消息验证码 (MAC)。 MAC 的通常定义包括一些（共享秘密）密钥和作为输入的消息，以及作为输出的身份验证令牌。

通常的使用方法是在通信开始时进行一些经过身份验证的密钥交换（使用共享密钥或一些已知的公钥），然后使用现在共享密钥的一部分作为 MAC 密钥，然后用于验证以下消息。（这样做本质上是对 SSL/TLS（或其部分）的重新发明，可能会再次犯同样的错误。）

如果您只有一条消息要发送，您可以改为使用 MAC 作为一种对称签名，使用密码哈希（盐化并使用慢速哈希函数生成）作为 MAC 密钥。

查看此问题的另一种方法是将要进行身份验证的消息作为 Thomas T 身份验证方案中外部散列的输入。（确保验证所有值得验证的内容。）

【讨论】：

请注意，@Paulo。是的，如果攻击者不仅可以嗅探，还可以修改网络流量，那就有点复杂了（但是，这种攻击并不常见）。我认为您的最后一段（在我的外部散列函数中散列整个消息）是想要的解决方案。
但是，如果您不这样做，身份验证本身的安全性不会被破坏。但是，如果您需要保护其他客户端-服务器通信免受任何修改，那就太好了，这是另一回事（可能经常被忽略）。例如。攻击者可以更改客户端消息以启动 DELETE 命令等。然后您需要在每条消息中发送签名哈希。我更新了我的答案。