views:

80

answers:

3

We're considering creating a program which sends a POST request to a server-side program for some processing. We'd like to consider some sort of verification to make sure the POST request isn't a random spammer attempting to overwhelm our system or something. I don't know too much about this stuff, but I was thinking the client might send a date-num and an "encrypted" date-num (not securely encrypted, just using some special algorithm). The server would then both encrypt the date-num AND decrypt the client-encrypted date-num. If either the encrypted date-nums or the decrypted date-nums didn't match, obviously it wasn't a request from our client, so the server will not act on the request.

As I said, I don't know that much about this. Am I going about it the right way? Is there a better way? If this is an ok way, whereabouts might I go looking for "encryption" algorithms? (most of the algorithms I find are for secure-encryption and can only be decrypted on the same machine. I don't care that much about security--I just am looking for verification).

Thanks a bunch for your help.

PS I'm not sure if this is a duplicate, because I didn't really know what to search. I couldn't find any other questions about this, but that doesn't mean anything.

EDIT: To clarify, the server code should be as "drop-in" as possible -- e.g. if it can be done using straight PHP or ASP.NET rather than mucking around with server configurations, then that would be better. Same on the client end. Keep in mind this does not have to be secure, we're just attempting to keep spammers from POSTing random data a million times.

+1  A: 

You could use ssl and client certificates and let the webserver handle it transparently. This way both the server and the client can be (more or less) sure about whom they are talking to.
What will your webserver be? IIS, Apache, ... ?
If it's an apache take a look at httpd 2.2 docs, Client Authentication and Access Control.
If it's an IIS see Enabling Client Certificates in IIS 6.0 (IIS 6.0)

VolkerK
Would we have to pay money to get a "verified" certificate? or would it work with a "non-verified" certificate? Or am I misunderstanding completely?
NickAldwin
It would work with a self-signed CA. But the client also has to trust the server certificate. If your client is a "normal" browser the user will have to add your certificate (at least) once. _If_ a self-signed certificate is feasible depends on your "clients" - the application as well as the human beings :-)
VolkerK
+1  A: 

Try using a cryptographic nonce.

  1. On the page from which the POST is launched, a random number is generated and stored in the database with the requesting IP address and an expiry time (15-30 minutes?).
  2. The same random number is stored as a POST variable.
  3. On POST, in order for the processing to occur, there must be a successful lookup matching the nonce and IP address before the expiry time.

Combined with a honeypot captcha, it should do a good job of preventing bots from straining your system.

cpharmston
That sounds like an excellent strategy; however, we were thinking of doing the POST request directly, without a "launching" page (because it'll all be handled behind the scenes in this program). But the honeypot captcha would definitely help.
NickAldwin
A: 

The usual approach for a problem like this is the inclusion of an HMAC. It allows integrity checking and sender authentication by the use of a secret key.

Bombe
Hmm, this looks promising. I'll look into it.
NickAldwin