After reading this question about how for-pay wifi routers identify specific devices it got me thinking about what a secure alternative might be. I know that certain research has focused on identifying devices by their browser signature and by their hardware clock skew signature. The former can be defeated by changing the browser signature, and the latter is difficult to implement and takes time to create the baseline.

MAC addresses can be altered, IPs can be rotated, and cookies can be hijacked or accidentally erased (eg. in the case of the for-pay wifi router, that would be undesirable). Are there any practical alternatives to identify a specific device? Are there characteristics of hardware that are consistent, unalterable, and undeniable (eg. CPU IDs [are they even still implemented?], but TPMs perhaps?)

How would you secure a for-pay wifi router to prevent others from gaining free access?

2 Answers 2


The only way to accurately identify a specific client on a network would be with cryptography. If each client had their own asymmetric key pair and you used a SSL VPN then it would be a lot easier to enforce resource usage rules.

Panopticlick would never work for this. The browser signature will change because of updates or installing new plugins/languages/etc. Not only that but this value is about as easy to spoof as a MAC Address, just run Panopticlick on the victim's browser and then modify your system to match. The bottom line is that software fingerprinting is too easy to fool and is error prone.

My gut feeling is that hardware fingerprinting is not the right path. What if the attacker has identical hardware? Macbooks are pretty popular these days. Again this kind of fuzzy matching is error prone and could produce false positives/false negatives.

  • 2
    +1 for strong crypto. Anything else is just a hack.
    – bstpierre
    Jan 1, 2012 at 22:40

How would you secure a for-pay wifi router to prevent others from gaining free access?

There is context missing here, but I will try to make reasonable guesses.

For who?

This is the most important question. If your target audience is compulsivly honest and unerringly punctual in payment then most other questions are of little concern. However, a more realistic answer would include a significant percentage of users willing to cheat or steal. Then who need to estimate their computer abilites to determine their ability to cheat the system given the opportunity.


Let's arbitrarly choose Vancouver in the downtown area. This will attract a variety of users from vacationers to business people. Certainly a area with a high flow rate of people can produce bursts of high demand and reliable dead times.

How much?

This is critical to your question. When the cost goes above what some users consider a fair amount, some percentage of users will attempt to steal service. They might attempt to pay for some service and use more than they are entitled to or they may attempt to recieve service without paying. The higher the cost the better your proffit but the more users will attempt to steal service. Unfortunatly it is difficult to tell what most users consider fair and what they consider fair may be below the cost of providing service (meaning negative profit). Still if it is feasible I would recommend a simple survey of what likely users would be willing to pay.

Fee basis.

How will you charge users for WiFi service? My best guess is flat daily rate with a price breaks at three days, five days, weekly, and monthly.


This is tricky. I would prefer in-person initial transaction, but given the nature of the business this seems impractical. I think I would allow remote registration and payment over a SSL connection. Then generate or register a public key and link payment to the public key.


OAuth Its already implemented and in significant use. An alternative would be Microsoft PKI using Windows Server 2008, but it may be more difficult to authenticate users with Linux, Android, Mac OS X, etc.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .