The basic mechanism is quite simple really, here is a brief description of the
The captive portal knows of:
1. URL for the authentication server
2. Its own 'location' (by default the system name)
3. Shared secret.
When the user comes along and attempts an HTTP GET he is snagged by the portal
in the normal way. He then gets redirected to the authentication server with
a GET and some embedded variables in the URL. (These are the initial URL he
was trying to get to, the user MAC address, the location and a security
The Authentication server pops up a page asking for username/password. If
these are correct, and match the MAC address recorded for this user, then the
authentication server responds with a redirect back to the portal.
This is a GET with embedded variables (MAC address, original URL, security
token, expiry time). The Portal checks the MAC address against the one
currently being used, if it is the same the portal is opened for this MAC
address up to the expiry time. The user is then redirected to his originally
requested site as normal.
The communication between the user and the authentication server (when the
username/password is exchanged) goes over HTTPS so it cannot be sniffed.
The outgoing request contains a token that is an md5($mac . $location .
$secret) and the returned token is md5($origtoken . $expirytime . $secret).
So if somebody replays the original token they would get access (because the
reply has no unique characteristics). The solution lies in digital
signatures on the server side and I am working on a protocol for this. (I
think that all that is needed is for the server to sign the original token
and send back the sig, which can then be verified against a known public
If you can see any holes in this, please let me know because fraud protection
is an important requirement for this system.
On Thursday 10 June 2004 02:10, Dinesh Nair wrote:
> On Wed, 9 Jun 2004, Peter Curran wrote:
> > important (or relevant). Having authenticated via the external service,
> > the user is redirected back to the portal with some embedded values in a
> > GET request.
> isnt this method susceptible to a man-in-the-middle replay attack ? a
> traffic snooper could read the redirected http request from the client,
> and replay this packet to the m0n0wall in order to get access.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.