我有一个表，其中包含允许访问 WCF 服务的所有用户名及其哈希密码。
使用消息级安全性并将每个请求的用户名和密码作为加密正文的一部分传递是否存在问题？
为什么几乎没有人建议将此作为身份验证选项？
编辑以澄清：
将此与将传输安全性与证书进行对比，您必须在每个请求中将用户名和密码作为 ClientCredentials 的一部分发送。
如果消息级安全提供机密性、完整性和身份验证，那么为什么使用证书是更好的选择？将凭据作为加密正文的一部分传递而不是与 ClientCredentials 一起传递有什么缺点？
每次请求都传递密码进行攻击，有人设法读取传输的内容。如果他们得到密码，他们可以随时登录。如果他们愿意，他们甚至可以更改密码。使用会话 ID，他们只能劫持会话，只要它处于活动状态（并且无法访问更好的受保护区域，例如更改密码区域，您必须通过再次提供密码来重新确认）。为了防止密码被盗，您必须更改密码（并记住新密码）。要抵消被劫持的会话 ID，您只需结束会话。无论如何，您永远不会记得会话 ID。此外，如果您一次又一次地发送密码，则需要始终将密码存储在客户端应用程序中的某个位置。那'
被劫持的密码实际上更糟糕，因为通常相同的密码用于多个不同的应用程序。
除此之外，您通常会使用一种额外的慢速算法来散列密码（这使得猜测密码变得更加困难，因为您必须等待。您可能想要添加一些类似有限尝试的东西每个时间单位的密码，以排除字典攻击。这与您的想法并不一致。
我想说总的来说这是一个坏主意，一直发送密码，独立或使用的框架，它更多的是客户端/服务器应用程序的原则。既然有像带有 ID 的会话这样的技术，为什么不使用它们。这并不比一直验证密码更复杂。
@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（安全令牌服务）。