在我正在处理的当前项目中，我们遇到以下问题。
我们的软件是基于位置的服务平台，应用程序可以通过使用SOAP的公开Web服务连接和使用我们的服务。到目前为止，我们的平台仅供内部应用程序使用，但现在我们想为第三方应用程序打开它。为此，我们需要一种身份验证机制。
由于我们客户的基础架构和负载平衡解决方案，我们无法使用HTTPS。最初的想法是应用程序可以只使用HTTPS并发送我们验证的密码。
解决方案将是下一个： 该应用程序具有密码。应用程序生成随机字符串（salt）并创建哈希。然后，应用程序创建一个HTTP请求，发送散列，salt和时间戳。这三个对我们来说足以进行身份验证，因为我们可以生成相同的哈希并进行比较。
我的问题是，为此我们需要以明文形式将密码存储在我们的数据库中，因为我们需要使用给定的salt执行相同的过程，以便我们可以比较结果并验证应用程序。以明文形式存储密码是不可接受的。
您知道任何适合这种情况的身份验证/访问控制机制吗？通常，您是否了解有关应用程序身份验证/访问控制机制的任何好书/来源？
非常感谢任何帮助。提前谢谢！
答案 0 :(得分：3)
应用程序（客户端）可以对密码进行两次哈希。请注意，服务器应生成其他随机盐，而不是客户端！否则，攻击者也可以使用此哈希进行日志记录。您还可以通过在数据库中存储特定于密码的salt来使其更安全。
协议：
0）服务器从数据库中检索该特定密码的salt，生成salt2，并将两者发送到客户端
1）客户端发送hash(hash(password, salt), salt2, timestamp)和timestamp。
2）服务器从数据库中检索hash(password, salt)并进行比较。
请注意，如果您在网络中攻击者不仅可以嗅探，还可以修改流量（{3}}，那么您应该签署每条消息 ：hash(hash(password, salt), salt2, timestamp, message)并在服务器上查看。 （例如，对于攻击者可以修改消息以包含删除命令的情况......）
请注意，当用户需要安全地设置/更改密码时，仍存在问题。你不能通过不安全的网络上的哈希函数安全地做到这一点，你需要某种密码/解密。
另请注意，散列函数越慢，越安全（因为字典攻击）。如果您无法访问特殊的慢速哈希函数，您也可以调用正常的快速哈希函数100000次。
答案 1 :(得分：2)
您应该使用已建立的解决方案，而不是发明自己的解决方案。 SOAP支持加密身份验证，例如WS-Security - 请参阅Craig Forster对此答案的评论以获取建议。
其他情况下的最佳选择通常是oauth;它提供授权和身份验证，并处理许多加密问题，这些问题在构建自己的问题时不太可能发现。
答案 2 :(得分：1)
使用不包含整个消息（或流）完整性检查的身份验证解决方案是不安全的。
虽然最初由Thomas T.提出的哈希解决方案（hash(hash(password, salt), salt2, timestamp)，其中hash(password, salt)存储在数据库中，而salt2是新生成的），但确保攻击者不能获取密码（或在时间戳到期后对登录有用的任何数据），它本身不会阻止活动攻击者在身份验证后劫持会话，并发送任何所需的SOAP请求（并拦截响应）。 / p>
这里需要的是确保没有数据更改的某种方法。这称为消息验证代码（MAC）。 MAC的通常定义包括一些（共享密钥）密钥和作为输入的消息，以及作为输出的认证令牌。
使用它的常用方法是在通信开始时（使用共享密钥或某些已知公钥）进行一些经过身份验证的密钥交换，然后使用现在共享密钥的一部分作为MAC密钥，然后用于验证以下消息。 （这样做基本上是对SSL / TLS（或其部分）的重新发明，可能再次犯同样的错误。）
如果您只有一条要发送的消息，则可以使用MAC作为一种对称签名，使用密码哈希（盐水并使用慢哈希函数生成）作为MAC密钥。
另一种查看此方法的方法是将消息作为Thomas T的身份验证方案中外部哈希的输入进行身份验证。 （确保验证值得验证的所有内容。）