[ACCEPTED]-How do I prevent replay attacks?-encryption

If you hash in a time-stamp along with the 4 user name and password, you can close the 3 window for replay attacks to within a couple 2 of seconds. I don't know if this meets your 1 needs, but it is at least a partial solution.

There are several good answers here and 37 putting them all together is where the answer 36 ultimately lies:

1. Block-cipher encrypt (with 35 AES-256+) and hash (with SHA-2+) all state/nonce 34 related information that is sent to a client. Hackers 33 with otherwise just manipulate the data, view 32 it to learn the patterns and circumvent 31 everything else. Remember ... it only takes 30 one open window.

2. Generate a one-time random 29 and unique nonce per request that is sent 28 back with the POST request. This does two 27 things: It ensures that the POST response 26 goes with THAT request. It also allows tracking 25 of one-time use of a given set of get/POST 24 pairs (preventing replay).

3. Use timestamps 23 to make the nonce pool manageable. Store 22 the time-stamp in an encrypted cookie per 21 #1 above. Throw out any requests older than 20 the maximum response time or session for 19 the application (e.g., an hour).

4. Store a 18 "reasonably unique" digital fingerprint 17 of the machine making the request with the 16 encrypted time-stamp data. This will prevent 15 another trick wherein the attacker steals 14 the clients cookies to perform session-hijacking. This 13 will ensure that the request is coming back 12 not only once but from the machine (or close 11 enough proximity to make it virtually impossible 10 for the attacker to copy) the form was sent 9 to.

There are ASPNET and Java/J2EE security 8 filter based applications that do all of 7 the above with zero coding. Managing the 6 nonce pool for large systems (like a stock 5 trading company, bank or high volume secure 4 site) is not a trivial undertaking if performance 3 is critical. Would recommend looking at 2 those products versus trying to program 1 this for each web-application.

If you really don't want to store any state, I 12 think the best you can do is limit replay 11 attacks by using timestamps and a short 10 expiration time. For example, server sends:

{Ts, U, HMAC({Ts, U}, Ks)}

Where 9 Ts is the timestamp, U is the username, and 8 Ks is the server's secret key. The user 7 sends this back to the server, and the server 6 validates it by recomputing the HMAC on 5 the supplied values. If it's valid, you 4 know when it was issued, and can choose 3 to ignore it if it's older than, say, 5 2 minutes.

A good resource for this type of 1 development is The Do's and Don'ts of Client Authentication on the Web

You could use some kind of random challenge 5 string that's used along with the username 4 to create the hash. If you store the challenge 3 string on the server in a database you can 2 then ensure that it's only used once, and 1 only for one particular user.

In one of my apps to stop 'replay' attacks 9 I have inserted IP information into my session 8 object. Everytime I access the session 7 object in code I make sure to pass the Request.UserHostAddress 6 with it and then I compare to make sure 5 the IPs match up. If they don't, then obviously 4 someone other than the person made this 3 request, so I return null. It's not the 2 best solution but it is at least one more 1 barrier to stop replay attacks.

Can you use memory or a database to maintain 15 any information about the user or request at 14 all?

If so, then on request for the form, I 13 would include a hidden form field whose 12 contents are a randomly generated number. Save 11 this token to in application context or 10 some sort of store (a database, flat file, etc.) when 9 the request is rendered. When the form is 8 submitted, check the application context 7 or database to see if that randomly generated 6 number is still valid (however you define 5 valid - maybe it can expire after X minutes). If 4 so, remove this token from the list of "allowed 3 tokens".

Thus any replayed requests would 2 include this same token which is no longer 1 considered valid on the server.

I am new to some aspects of web programming 2 but I was reading up on this the other day. I 1 believe you need to use a Nonce.

(Replay attacks can easily be all about 10 an IP/MAC spoofing, plus you're challenged 9 on dynamic IPs )

It is not just replay you 8 are after here, in isolation it is meaningless. Just 7 use SSL and avoid handcrafting anything..

ASP.Net 6 ViewState is a mess, avoid it. While PKI 5 is heavyweight and bloated, at least it 4 works without inventing your own security 3 'schemes'. So if I could, I'd use it and 2 always go for mutual authent. Server-only 1 authentification is quite useless.

The ViewState includes security functionality. See 9 this article about some of the build-in security features 8 in ASP.NET . It does validation against 7 the server machineKey in the machine.config 6 on the server, which ensures that each postback 5 is valid.

Further down in the article, you also see that if you want 4 to store values in your own hidden fields, you 3 can use the LosFormatter class to encode the value in 2 the same way that the ViewState uses for 1 encryption.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

Use https... it has replay protection built 1 in.

If you only accept each key once (say, make 4 the key a GUID, and then check when it comes 3 back), that would prevent replays. Of course, if 2 the attacker responds first, then you have a 1 new problem...

Is this WebForms or MVC? If it's MVC you 8 could utilize the AntiForgery token. This 7 seems like it's similar to the approach 6 you mention except it uses basically a GUID 5 and sets a cookie with the guid value for 4 that post. For more on that see Steve Sanderson's 3 blog: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Another thing, have you considered 2 checking the referrer on the postback? This 1 is not bulletproof but it may help.