0

Let's say Bob sent this HTTP request to an API to update his email:

/user/update?email=bob@example.com&userid=1234&sig=x1zz645

Now a sniffer named Zerocool recorded this request for later use.

After a few days later, Bob updated his email again to email=newbob@example.com.

Few hours later Zerocool now decides to use what he sniffed a few days ago and runs the request:

/user/update?email=bob@example.com&userid=1234&sig=x1zz645

The server accepts it and Bob is now confused why is the old email back.

How can we prevent this from happening without using SSL?

IMB
  • 15,163
  • 19
  • 82
  • 140

3 Answers3

2

Keep a log of recent requests. Embed a timestamp into such requests, and reject any that are present in the log or older than the log. For good measure, sign the timestamps with a private md5 checksum, so they can't be fabricated.

ddyer
  • 1,792
  • 19
  • 26
  • Server should allow some time difference unless server and client are perfectly synced. Checking logs can be complicated too. It's better to have a nonce (unique string) generated with each request and check nonces for duplicates. – Andriy Lesyuk Apr 04 '13 at 12:25
  • EJP's answer is correct, you should use SSL. And this answer is NOT secure. With this attempted solution, a man in the middle attack can easily intercept messages and replay them to the server while preventing the requests from reaching the server. Signing the timestamps does nothing to secure against this hole. – user1678406 May 21 '14 at 20:30
0

Use SSL as stated in your tags. It is already immune to both sniffing and replay attacks. It exists. Using it is free. It works. It's done.

If you can't use SSL please remove it from your tags.

user207421
  • 305,947
  • 44
  • 307
  • 483
0

You can use Hash based message authentication code (HMAC) to secure the API so that replay attacks like the one you mentioned can be avoided. Both the server and the client will have a shared secret API key.

Amazon S3 Rest API uses the same procedure to Authenticate and Validate requests. See the Documentation here.

UPDATE: As Bruno pointed out HMAC itself cannot prevent replay attacks. You will have to include some unique identifier signed with secret key with the message and validate it at the server.

Obaid
  • 1,407
  • 19
  • 36
  • 2
    HMAC isn't going to prevent *replay* attacks, if the same message and HMAC are played again. – Bruno Aug 13 '12 at 09:47
  • @Bruno thanks for pointing that out. I don't know what I was thinking. I guess including [Cryptographic nonce](http://en.wikipedia.org/wiki/Cryptographic_nonce) can solve the problem. – Obaid Aug 13 '12 at 09:57