我编写了一个WCF服务，该服务返回有关人名，地址和电话号码的“半私人”数据。通过半私有，我的意思是有一个用户名和 用于访问数据的密码，数据应在传输过程中受到保护。然而， 恕我直言，没有人会花费任何精力来获取数据，因为它主要是可用的 无论如何在公共电话簿等等。在某种程度上，安全是一个安全的“剧院”来勾选政府实体强加给我们的一些箱子。
该服务的客户端是一个已注册的应用程序 '用户'在自己的IT设置中运行。我们无法控制IT 用户 - 事实上，如果我们投入太多，他们经常会告诉我们'跳' 他们的系统要求。
我们遇到的一个问题是拥有系统时钟的众多用户 这不准确。这可能是由真正的慢速/快速时钟引起的，或者 很可能是时区或夏令时区错误（把他们的 机器一小时关闭'真实'时间）。我们是WCF绑定的一个特性 使用是因为他们依靠时间的概念来检测重放攻击等。
<wsHttpBinding>
<binding name="normalWsBinding" maxBufferPoolSize="524288" maxReceivedMessageSize="655360">
<reliableSession enabled="false" />
<security mode="Message">
<message clientCredentialType="UserName" negotiateServiceCredential="false"
algorithmSuite="Default" establishSecurityContext="false" />
</security>
</binding>
</wsHttpBinding>
不准确的客户端时钟会导致抛出安全异常 不满意的用户。
除了建议用户更正他们的时钟，我们知道我们可以 增加安全绑定的时钟偏差。
http://www.danrigsby.com/blog/index.php/2008/08/26/changing-the-default-clock-skew-in-wcf/
我的问题是，真正的实际安全后果是什么？ 增加歪斜说2个小时？如果攻击者可以执行某些操作 一种重播攻击，为什么一个时钟会扭曲5分钟的窗口 一定比2小时安全吗？我认为表演任何 使用'message'安全模式进行攻击需要的不仅仅是 在代理处捕获一些数据并再次发回数据 “重播”电话？在像我这样的数据的情况下 只有用户“阅读”，确实存在任何安全后果 根本不允许'重播'攻击？
答案 0 :(得分：0)
默认情况下，您将通过互联网公开并且可以通过各种地理位置（即跨时区）访问并且将检查时间戳以避免重放攻击的任何Web服务都应使用通用时间（UTC）检查那些时间戳。
在这种情况下，Web服务还应该规定任何消费者提取数据也应该使用UTC来标记他们的请求。这当然会消除服务器和客户端之间的任何时区冲突。
关于服务器和客户端之间的时钟偏差。您的服务器是否与普通的互联网时间服务器同步？如果是这样，您还可以在Web服务API中指定任何使用者还必须将其系统时钟与同一时间服务器同步，以便提高服务质量和服务连接的可靠性。
不幸的是，您无法控制客户端系统上的时钟！通过加宽服务器上的时钟偏差来尝试解决客户端的连接问题会降低系统的完整性，应该不惜一切代价避免，即使系统返回的数据只是半敏感的。如果消费的数据对于消费者来说足够重要，他们将很乐意遵守任何改进服务质量和他们所希望的数据的可访问性的改变。