httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Bastin" <nick.bas...@gmail.com>
Subject Re: handling authentication
Date Fri, 13 Jun 2008 18:28:13 GMT
On Fri, Jun 13, 2008 at 9:08 AM, Sam Carleton
<scarleton@miltonstreet.com> 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

Mime
View raw message