On Fri, Jun 13, 2008 at 9:08 AM, Sam Carleton <[EMAIL PROTECTED]> wrote: > There are three different issues need to be implemented: > > 1: Making sure the browser is one of my kiosk browsers application > (right now I am doing this by changing the user agent, but am open to > other approaches)
That's a bad idea from a security standpoint. If you have ANY concerns over the physical security of the boxes such that someone might install and/or use another browser, then you should use SSL Client Auth to verify the client browser. > 2: Making sure each browser is uniquely identified. Client-auth helps you here too, since each browser would have a different signature. > 3: Making sure that the number of browsers connected does not exceed > the customers license. Once you have unique identifiers for each browser, this just comes down to heuristics and policy. Since http is mostly stateless (even with AJAX there are times when the browser is "connected" but not communicating with the server), you'll need to decide what a "connection" means, and how to time them out, etc. > When using cookies, where should I put the timer? Should I have the > Apache module track when the last time a said cookie connected to the > module or should I simply set the cookie to timeout in X seconds and > renew it on each request? I am thinking it should work like this: If you feel like you have sufficient control over the browser application, opting the browser into the timeout isn't a horrible idea. However, again, if you're concerned about client security, you can of course implement this all on the server (client sends cookie, server checks each timeout on request). All that being said, assuming you don't expect the kiosk browser to crash, you could use a totally separate connection when the browser starts up to loan it a license, and have it give that license back when/if it quits. Then establish a significantly longer timeout on the off chance that it crashes so that license isn't locked out forever. > From a security standpoint, is there anything I am missing? It all comes down to how much you trust the physical security of the kiosk, and who is likely to attack it. If you feel you cannot trust the kiosk at all, then all security must be implemented in the server. If you're in a situation where you feel that you can detect if the kiosk has been compromised, then you can opt-in the kiosk itself to some levels of security. I think SSL client-auth is your best option for making the system tamper resistant and uniquely identifying kiosks, but there are still a few hurdles after that. -- Nick
