I’m in the process of writing a pair of applications that allows two hosts to interact. The idea is that one application (the “server”) would run on any desktop computer, propagated by Bonjour/Zeroconf (?), and the other application would run on a cell phone (iPhone, Android).
How, then, do you authenticate the cell phone? A question as simple as this has kept me busy for three straight days and I can’t find a good answer to it. Ideally, the service would be installed as a package (on OSX) and there should be no user interaction at that stage, and the service would continually be available through launchd (like inetd). Authentication-driven authorization is needed because other users would be able to maliciously connect to the service while you don’t want them to. That, then, gives us two goals:
- When the user itself is requesting authorization, it should be as easy as possible on both the desktop and server side
- When a malicious users is requesting authorization, then the authentication mechanism should automatically reject the connection, without any interaction on the desktop. I might at this point be writing an important document and would not want to be disturbed with silly dialogs saying “would you like to authenticate this user”.
So how do you implement authentication over a network that meets both of these requirements?
- I am considering using the password of the currently logged-in user on the Mac as key for authentication. However, I have yet to find a way to actually check a password for validity in Mac OS X. Its security model (rightly so) places actual authentication in a process separate than the running application (securityd and Security Agent), which means that I can’t do my own version of that. Of course, the password would be sent encryptedly over the network.
- I could use a separate password, but then the desktop-service would require configuration, which sucks.
- Bluetooth pairing-style authentication/authorization involves actual interaction, violating condition (2) above.
- You could pop up a dialog on the desktop asking the currently logged in user if it’s OK for the iPhone to connect, but that again sucks for the reason given in condition (2).
Dear lazyweb, any ideas?
What about a dialog in the desktop application that would show a random 4 digits code that you would have to type in any client you want to allow ?
Maybe see http://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup for some ideas. It’s implemented in wpa_supplicant now, but I don’t know about any UIs. Might not solve your problem at all, but maybe some of the methods could be usable — I don’t know off-hand, just seemed like WPS is like what you need.
Bluetooth-type authentication does not have to violate your second requirement, if you implement bluetooths ‘discoverable’ status. So on one of the devices, you set the device to be discoverable. The device shows you some kind of code. The other device now can see the first device, you type in the code and they connect.
As long as the implementation is correct (make sure you use secure random numbers) this works reasonably seamless and secure. The only thing that can happen is a man-in-the-middle attack and that would require the attacker to intercept all communication, which is rather impractical.
Since you are specifically authenticating a mobile phone, I would suggest a one-time pad delivered via SMS. The user registers their mobile phone number, and when they require access, the server sends a code via SMS which the user then copies into the client application. The Google SMS gateway would have been ideal for this, unfortunately it was shut down due to abuse from a certain iPhone application.