Page 1 of 1

Imperfect Site-to-Site Authentication

Posted: Thu Jan 25, 2007 6:29 pm
by Christopher
I have a client that is going to be distributing what I will call mini-websites that clients can install on their server/webserver somewhere. These mini-sites will have no server side scripting available -- only Javascript. Users will browse the mini-website and based on their input I need to post data back to a central data collection server.

I doubt there any way to guarantee that the data sent to the central server was really generated by the mini-site or spoofed in someway. That is probably OK because the chance is low that anyone will try to spoof it (given the user base) and because the mini-site will be installed on corporate intranets where the company is motivated to get accurate data.

I think the thing I am trying to do is make it so that you can't just copy a URL and change a value or two to create false submissions. I had assumed at a minimum that I would Ajax POST the data and maybe create a MD5 or SHA1 hash from a couple of values so that it would at minimum require creating the hash to create a valid submission.

So my question is: any ideas on how to improve this system (e.g. challenge-response)? Or is it not worth it do so more that something minimal because anyone serious could falsify data anyway.

Posted: Thu Jan 25, 2007 6:37 pm
by feyd
I think challenge response is a very good idea. There are implementations of sha256 in Javascript as well, so I would also suggest using one of those as the hashing algorithm of choice.

Posted: Thu Jan 25, 2007 6:55 pm
by Christopher
But given that the pages of the mini-site are beyond my control and the all code completely visible, is it worth going to too much trouble. I guess challenge-response assumes that you have to go to the trouble of writing/modifying code to simulate the exchange. That probably sets the bar high enough. Have you every done anything like this?

Posted: Thu Jan 25, 2007 7:10 pm
by feyd
I've done challenge-response many times before. On pages where I don't have much control, it seems to work pretty well.. isn't that hard to integrate, and does offer some piece of mind. However for someone experienced, it's not too hard to fake the challenge-response either.

I'm assuming you'll be pulling the Javascript file from your main site?

Posted: Thu Jan 25, 2007 7:33 pm
by Christopher
feyd wrote:I'm assuming you'll be pulling the Javascript file from your main site?
No. It needs to be able to run without the central server, but you get data collection if they open up an internet connection.

I suppose I could get the Javascript from the central server if I there was a connection -- maybe even have PHP generate that Javascript with a generated ID in it. I need to look into loading scripts with Javascripts -- doable. But they can still fake the data that is sent. That's the problem.

Posted: Thu Jan 25, 2007 8:04 pm
by feyd
It's always possible to fake the data, but you can make it much much harder for them. ;)

For example, one that communicates back and forth several times or enforces fetching requirements (x, y and z files must have been fetched for this transaction to work), possibly using generates URLs (mod_rewrite) some other creative ways of mixing it all up. Cookies and sessions, etc.. you get the idea I suspect. ;)

Posted: Thu Jan 25, 2007 9:31 pm
by Christopher
Yeah, I get it. I have two reservations ... first it is just extra time (so less profit) for not much extra security, and second I need the system to be very robust so I want to keep the transaction clean and as quick as possible. And it needs some kind of error recovery scheme that is fairly user friendly.

Posted: Thu Jan 25, 2007 10:15 pm
by feyd
Yeah, it does take a little bit of extra time. However, like OOP and Unit Tests, I chalk it up to basic prep time. Once you have a fairly decent system, it should easily be tunable to changing needs amongst various jobs. The major work, which for myself, isn't really all that much. An array of fields is intermixed together, hashed with some provided one-time salt and added to the submission stream. The other end verifies based on what it sent as the salt. It fails, it sends back a simple failure flag.