Proof of Concept: Simple Authenticated Internet Access

Sitting in the train at Amsterdam’s “Centraal Station” I was considering what the simplest method would be to provide public authenticated internet access – such as the one I was using in the train – with a payment/self-service to track the users. I’m not saying that this is possible to do with low end systems such as your provider gives away as part of the DSL subscription.

I’m into quick paper prototypes, so there could be an even simpler way in practice, and I think I mostly covered it in the diagram.

Image may be NSFW.
Clik here to view.

1. Firstly the client must be able to connect, which is symbolized by this arrow. I don’t want the user to be redirected to the internet immediately so I have the “proxy” redirect the user, this could be based on the MAC address that the user’s computer broadcasts to the Access Point, IP allocated in the DHCP lease, or both. The risk here is that the IP and MAC can both be spoofed. In a system for which payment is needed the risk is theft of the connection from the real customer or a DoS due to the IP address collision. The choice here is to accept and budget for it, making all the honest customers pay for the crimes perpetrated against them, or reduce this by using the Access Manager (AM) to ensure that the current user is the user who authenticated by using some browser magic.
2. The user goes to the Self Service and either creates and pays for an account, or requests some type of (limited/trial) access. There is a risk here that identity theft can take place, as the network is not secured with a password, and this risk can be reduced by using SSL to encrypt the session.
3. The user then uses the created data to authenticate, again this risk can be reduced by using a SSL connection.
4. After authentication the user session is passed on to the AM.
5. The AM checks the access rights for the user/session and passes this data on to the Self Service so the user can see the current status of the account.
6. The “proxy” is also updated at the same time as the Self Service, this to ensure that the user can make use of the service that has been acquired.
7. The user starts to use the service which has been acquired. To avoid the theft of the user’s information due to an insecure wifi network the choice can be made to tunnel the connection to the internet over SSL, the issue is naturally that each page or item will get a SSL security warning. And this may give issues with sites which do use SSL. The simplest strategy is to warn the customers of the risk during the Self Service in a EULA that they will never read, although the nicest way would be to warn them in a more prominent way – still the treatment of this risk is to not become involved in any resolution.

Any comments?

Image source: purpleslog