Digitally sign communication of gateway and server

That was an explicit design decision, keep the gateway protocol as simple as possible to keep it embeedable. While we could decide to sign packets, the 2.0 release would most definitely NOT be blocked if this weren't implemented! Implementing it requires re-writing most of the gateway to support key exchange, which makes pretty much our entire architecture obsolete (what's the point of delegating auth to the auth server if we have secure communication with it?). It would also multiply the code size and bandwidth requirements, and probably add our first external dependency; Wifidog was born because NoCat had too many crypto related dependencies to be embeedable!

The only thing that can currently happen by accessing /ping is fake a hotspot being online! A little more problematic is /auth. If you can do a man in the middle and intercept the session id , you could inflate (but not deflate) the statistics and expire a session prematurely. But that is all you could do. It may be a problem if for example you sell access by the kilobyte, but then if you use a captive portal for security you've got larger issues to consider. If you are concerned about either of those issues , open a VPN to you auth server from each of the hotspots, and only allow access to the auth server through the VPN's subnet. Then both issues disapear. No need to make wifidog much more complex.

Would a much more basic shared secret be used? That and a quick C implementation of SHA-256 would provide authentication quite acceptably... Without a huge crypto hit. Perhaps if we have access to some form of local storage on the gateway side we can record this shared secret on first activation / installation of the gateway (or it could be relegated to a script). The auth server would generate say a 128-bit random value, record it in the gateway's db entry and transfer it to the gateway exactly once.