practical security ramifications of increasing WCF clock skew to more than an hour

Question

I have written a WCF service that returns 'semi-private' data concerning peoples name, addresses and phone numbers. By semi-private, I mean that there is a username and password to access the data, and the data is meant to be secured in transit. However, IMHO noone is going to expend any energy trying to obtain the data, as it is mostly available in the public phone book anyway etc. At some level, the security is a bit of security 'theatre' to tick some boxes imposed on us by government entities.

The client end of the service is an application which is given out to registered 'users' to run within their own IT setups. We have no control over the IT of the users - and in fact they often tell us to 'go jump' if we put too many requirements on their systems.

One problem we have been encountering is numerous users that have system clocks that are not accurate. This can either be caused by a genuine slow/fast clocks, or more than likely a timezone or daylight savings zone error (putting their machine an hour off the 'real' time). A feature of the WCF bindings we are using is that they rely on the notion of time to detect replay attacks etc.

 <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>

The inaccurate client clocks cause security exceptions to be thrown and unhappy users.

Other than suggesting users correct their clocks, we know that we can increase the clock skew of the security bindings.

http://www.danrigsby.com/blog/index.php/2008/08/26/changing-the-default-clock-skew-in-wcf/

My question is, what are the real practical security ramifications of increasing the skew to say 2 hours? If an attacker can perform some sort of replay attack, why would a clock skew window of 5 minutes be necessarily safer than 2 hours? I presume performing any attack with security mode of 'message' requires more than just capturing some data at a proxy and sending the data back in again to 'replay' the call? In a situation like mine where data is only 'read' by the users, are there indeed any security ramifications at all to allowing 'replay' attacks?

Answer 1

By default any web services which you will be exposing over the internet and which are meant to be accessible by various geographical locations (i.e. across timezones) and which will be checking timestamps to avoid replay attacks should be using Universal Time (UTC) to check those timestamps.

That being the case, the web service should also dictate that any consumer pulling data should also by using UTC to stamp their requests. This will of course remove any Time Zone conflicts between your servers and the client.

As to clock skew between the server and the client. Are your servers being synchronized with common internet time server? If so you may also specify in the web service API that any consumer must also synchronize their system clocks with the same time server in order to increase the quality of service and reliability of the service connections.

Unfortunately, you cannot control the clock on a client's system! By widening your clock skew on the server to try and solve a client's connection issue reduces the integrity of your system and should be avoided at all cost, even if the data being returned by the system is only semi-sensitive. If the data being consumed is important enough to the consumer they will gladly comply with any changes which improve the quality of service and accessibility to the data they desire.