如何在.NET WCF中保护HTTP JSON web服务

因此，我想保护http json web服务

我将有一批系统用户，他们都有用户名和密码。 我只想在我的数据库中随机存储用户密码的salt散列，以避免在数据库受损的情况下发现所有密码，并存储salt（每个密码）以避免预先计算的彩虹表/字典攻击

我一直在研究摘要身份验证，因为它通过使用服务器提供给客户端的随机“nonce”来防止重播攻击，如下所示：

A1 = string.hashMD5 (username + ":" + realm + ":" + password)
A2 = string.hashMD5 (paramTable.method + ":" + paramTable.uri)
requestdigest = string.hashMD5 (A1 + ":" + nonce + ":" + A2)

然而，为了让服务器重新计算'requestdigest'，它必须知道'password'，但我的服务器将只能访问一个盐哈希

如果我没有使用salt，我可以像这样在客户端添加进一步的步骤（因为在客户端密码是已知的）-

然后在服务器端，我可以从数据库中检索哈希密码来执行重新计算

唉，客户也需要知道盐，以便正确地操作，例如

HashedSaltedPword = string.hashMD5(password+salt)
A1 = string.hashMD5 (username + ":" + realm + ":" + HashedSaltedPword)
A2 = string.hashMD5 (paramTable.method + ":" + paramTable.uri)
requestdigest = string.hashMD5 (A1 + ":" + nonce + ":" + A2)

因此，在给定用户名的情况下，可以通过公开一个返回salt的web服务函数将salt传输到客户端而不进行身份验证。 但是任何人都可以得到盐

但我想知道的是，分发盐是否是一个问题。 因为，如果没有存储在数据库中的哈希，salt本身是无用的，并且如果数据库被破坏，那么攻击者无论如何都可以访问哈希和salt。 接下来，如果我免费赠送salt，那么我也可以使用用户名本身作为salt，因为每个用户都是唯一的，因此我甚至不需要公开webservice调用来发现salt

你们觉得怎么样？暴露盐分或具有已知盐分机制是否重要？ 还有其他想法吗

我并不真的担心摘要身份验证的缺点，即客户端不知道它是否在与“真正的”服务器通信。因为，使用这种方法不会暴露客户的密码，我也不会要求客户在这个链接上提供任何机密信息，比如信用卡。也就是说，我想要保护的东西驻留在我的服务器上，服务器不会向客户机询问他们的任何安全信息

编辑： 嗯，实际上我刚刚读了这个链接，它基本上向我证实了知道盐并不重要。 所以我想实现一些sortof散列，比如：

HashedSaltedPword = string.hashMD5(password+username+siteWideSaltExistingOnlyInCode)

添加站点范围的salt是为了防止有人为普通用户名创建彩虹表。

---

这种方法看起来安全吗？

您必须选择如何传输密码。是否仅将哈希值从客户端传输到服务器端？在这种情况下，服务器必须存储密码，否则将无法重新计算哈希。您希望服务器不存储密码吗？在这种情况下，您必须以明文形式传输密码，以便服务器可以计算散列并将其与存储的散列进行比较

---

前一种情况需要在数据库中存储密码，如果要保护密码，应该使用一些数据库/应用程序级加密。后一种情况需要安全传输（HTTPS、VPN等），因为密码是以可读的形式传输的

你的问题与JSON没有多大关系，是吗？我想它可能有点长，有点重。您似乎真的在问“当我只存储加密密码时，如何使用摘要身份验证？”实际上，这不需要存储在数据库中的密码-HashedSaltedPword=string.hashMD5（密码+用户名+SiteWideAltexistingOnlyCode），因为在初始注册时，这个HashedSaltedPword就是我们存储到数据库中的内容。因此，在客户端，我们不是将明文密码放入摘要身份验证中，而是首先在客户端计算HashedSaltedPword，然后将其替换为密码放入摘要身份验证函数中，因此如果有人知道哈希，他根本不需要知道密码？是的，它可以工作，但你再次需要安全的运输。

HashedSaltedPword = string.hashMD5(password+username+siteWideSaltExistingOnlyInCode)