我有一张表，其中包含允许访问WCF服务的所有用户名及其散列密码。
使用邮件级别安全性是否有问题，并将每个请求的用户名和密码作为加密正文的一部分传递？
为什么几乎没有人认为这是一种身份验证选项？
编辑以澄清：
将此与使用传输安全性与证书进行对比，其中您必须将每个请求的用户名和密码作为ClientCredentials的一部分发送。
如果邮件级安全性提供机密性，完整性和身份验证，那么为什么使用证书是更好的选择？将凭据作为加密正文的一部分传递而不是使用ClientCredentials传递它的缺点是什么？
答案 0 :(得分：4)
在每个请求中传递密码会造成攻击，有人设法读取传输的内容。如果他们获得了密码，他们可以在每次需要时登录。他们甚至可以根据需要更改密码。使用会话ID，他们只能劫持会话，只要它是活动的（并且不会访问更好的保护区域，例如更改密码区域，您必须通过再次提供密码再次确认）。要抵消被盗密码，您必须更改密码（并记住新密码）。要抵消被劫持的会话ID，您只需结束会话即可。你永远不会想起会话ID。此外，如果您一次又一次地发送密码，密码需要始终存储在客户端应用程序中的某个位置。这是攻击者可以从中获取密码的另一个地方。
被劫持的密码实际上更糟糕，因为通常会将相同的密码用于多个不同的应用程序。
除此之外，您经常使用额外的慢速算法来对密码进行哈希处理（这使得猜测密码更难，因为您必须等待。你' d可能希望在每个时间单位添加一些密码尝试，以排除字典攻击。这与你的想法并没有很好的结合。
我总体而言，总是这是一个坏主意，无论是一直发送密码，独立还是使用框架，它都是客户端/服务器应用程序的原则。而且由于有像ID的会话这样的技术，为什么不使用它们。这并不比一直验证密码复杂。
答案 1 :(得分：2)
@kratenko是对的，发送每封邮件的密码并不是一个好方法，虽然我同意你的看法，从加密邮件中获取密码并不是一件容易的事。您可以做的是在WCF通信上使用双重安全性，这意味着消息安全性和传输安全性（SSL）。这是一个链接，解释了如何实现它：http://www.dotnetfunda.com/articles/article891-6-steps-to-implement-dual-security-on-wcf-using-user-name-ssl.aspx。
您还有其他选项，例如：仅在安全通道（SSL）上发送您的用户凭据一次，并根据用户身份验证的成功生成您发送回客户端的令牌。在此方案中，对于任何进一步的请求，客户端必须在自定义标头中提供该标记。在服务级别，您可以将生成的令牌保留在高性能缓存存储系统（如Couchbase）上，因此在每个传入请求中，您将比较客户端提供的令牌和缓存中的令牌。通过这种方式你可以保持服务无国籍。如果您不喜欢这个想法，那么您可以选择使用STS（安全令牌服务）。