How does Timestamp helps in preventing Replay Attacks in webservices - 【StackMirror】|wcf|web-services|security|web|timestamp

I am trying to understand the concept of timestamps in request headers in web services but somehow still can't understand fully how it works.

I would appreciate it if someone can explain the end-to-end use of timestamps in request and response of web services.

Is it really a foolproof method of preventing replay attacks?

2012-04-05 02:52
by Kunal Uppal

A timestamp by itself wouldn't be sufficient, but usually it is combined with a hashing mechanism to guarantee that the values haven't been tampered with.

The idea is that the client generates the parameters, and uses their private key to hash the parameters. The [hash + original values + public key] are then sent with the request. The server can use the public key to look up the private key, and ensure that the parameters are correct.

The timestamp is used, along with some threshold, to ensure that particular request can't be used more than once. If the threshold is small (a few hundred milliseconds) then a replay attack is virtually impossible.

2012-04-05 03:01
by Josh

Is the value of the timestamp encrypted? How does server validates that the incoming request have a valid timestamp and is within the threshol - Kunal Uppal 2012-04-05 03:43

@Kunal - Like I said the client Hashes the input parameters and sends the hash along with the inputs. The hash servers as a check-sum against tampering. The server uses the private key that corresponds to the users public key to computer their own hash of the parameters. If the two hashes match, then you know the values provided are legitimate, and have not been tampered with - Josh 2012-04-05 13:38

@Kunal, no timestamp is not encrypted and it should be in soap header - Don 2014-07-02 05:17

@Don - If you are using SOAP. But the timestamp is encrypted as part of the checksum, that is precisely what the Digest is for, it's a hash of params to verify that they have not been tampered with. The timestamp is sent along with the hashed version as a checksum. This isn't a technique that applies to only SOAP, as it is used in JSON web services as well - Josh 2014-07-02 14:11

Timestamp is not encrypted and it should be in soap header.

    <wsu:Timestamp wsu:Id="timestamp">
        <wsu:Created>2014-07-01T11:30:28.123+05:30</wsu:Created>
        <wsu:Expires>2014-07-01T11:35:28.123+05:30</wsu:Expires>
    </wsu:Timestamp>

If expires time is little after Created time, it can minimize replay attack. Actually it is not just the timestamp. You should add digest of timestamp to SignedInfo section.

<ds:Reference URI="#timestamp">
    <ds:Transforms>
        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
            <InclusiveNamespaces PrefixList="wsse soap" xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        </ds:Transform>
    </ds:Transforms>
    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <ds:DigestValue>TGgFBvglhb+jZCvjV0+oVnNaivpVBp5iVbJEqkTfaCU=</ds:DigestValue>
</ds:Reference>

So at the server side these digests must match. Even that is not all, then you sign whole signedInfo with private key and add signature value to Signature element as following.

<ds:SignatureValue>jdO5GIZ9v1VTngFZcMpz5hz62RwToq2W24A9KhJ5JNySZW1AHhd3s+eTduZZPD0Ok6Wtgzu5kquK
    IinPdi5IbGjlg6mXGDbVkLd79RBdnbzFxsJFBtRr9r3mQZp9xfU7zSJW3kbizz6Jjk3h+S2nNbUu
    f7rFrNN53ciRtj9RlKzQzmW7BDaFuq18DUfcr70muSkmd4DIqxYDGScjEjgIqLE2pYwIdDDRUGPD
    MuwuIN3DgB051QwcE75SVrKBKsTHmFADmN3nKzmQ/JUQuLot0vW6WUFRMLVlAcl5C09SGPOcpow2
    kjbuWx/bI7Aj4nAaAnmAYsWKIA3xVao+nPBOWmM0Lg7kpC4Dr5DwahmjH0/78aVUU23DEiMc0kR0
    YDg5CxD8MUuj24w8tAjuzoHrvcsIYw+vWCTKvucnXwTlZ+K3QFB6gkct2zVOyQeYaPpkAnmPYS3W
    DDpNmsx3lDcNr+5QWTsUbSQaFDddjHT/zoOJ8+iZKY/RujOI5vfXVwgN</ds:SignatureValue>

Now we can make sure that replay attacks are not possible. Since anyone else cannot have the same private key and so there is no way to alter timestamps and still have a valid signature.

2014-07-02 05:33
by Don