How Timestamp helps prevent replay attacks on webservices

Question

I'm trying to understand the concept of timestamps in request headers in web services, but for some reason still can't fully understand how this works.

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

Is this a really reliable way to prevent replay attacks?

Answer 1

The timestamp itself will not be sufficient, but it is usually combined with a hash mechanism to ensure that the values ​​have not been changed.

The idea is that the client generates parameters and uses its private key for hash parameters. After that [hash + initial values ​​+ public key] are sent with the request. The server can use the public key to search for the private key and verify that the parameters are correct.

A timestamp is used along with a certain threshold to ensure that a particular request cannot be used more than once. If the threshold is small (a few hundred milliseconds), then a second attack is almost impossible.

Answer 2

The time stamp is not encrypted and should be in the title bar.

<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 the expiration time elapses a little after the Created time, it can minimize the re-attack. This is actually not just a timestamp. You must add a timestamp digest to the 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, on the server side, these digests must match. Even that is not all, then you sign the signedInfo integer with the private key and add the signature value to the Signature element as follows.

 <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 repeated attacks are impossible. Since someone else cannot have the same private key, there is therefore no way to change timestamps and have a valid signature.