Using SMS as an authentication factor for a website.

Question

Hello,
This question is a follow up to a previous question I had
http://stackoverflow.com/questions/2822885/im-trying-to-implement-2-factor-authentication-on-the-cheap-how-would-i-do-that

I'm exploring the idea of using an android phone to SMS or robot talk a pin/token code to a user's home phone or mobile device. I'm looking at using android because the hardware would be cheap and I'll be able to install the application I'd make with no issues.

User's should be logging onto the system about once a day. The application currently has 75 users. User's are not guaranteed to have a cell phone.

I have a few questions:
Is this a viable 2nd form of authentication?
Is there a cheaper way of accomplishing this?

The workflow is as follows.

User goes to webapp enters user name, selects type of notification they want, SMS or Speech and submits.

The webapp (in my case C# .net) verifies the user exists and looks up the phone number we have on record.

The web app creates a token that will expire in a set amount of time and somehow communicates this and the phone number to the android device. (XML, files or anything really)

The android phone has an application that checks the XML file or folder containing files with the information on a set interval and performs a SMS or phones the person and tells them the token with the robot voice.

The phone then notifies the webapp that the message was sent or failed and the webapp notifies the user.

Here is a picture of what I'm thinking.

Thanks for any feedback. Security is not my strong suit.

Answer 1

That sounds fine in principle, but remember to be very conservative about exactly what information this gives you: you have proved that the person entering the code is in possession of the phone, nothing more.

In combination with the fact that they also know the right password this is generally enough to be confident that the right user has been authenticated. You just need to make sure that an attacker cannot guess or sniff the code. You can prevent guessing by generating cryptographically random codes, but you'll have to check to see how hard it is to sniff SMS. I'm guessing fairly hard except for particularly dedicated attackers, but presumably we're not talking national security here.

Make sure you have mechanisms for revoking passwords / cellphone numbers when login attempts fail or a user reports a lost or stolen phone. You'll also need to have an alternative for those users without phones.

General mantra for authentication: something you know, something you hold. The password you know, the phone you hold.

Answer 2

You can do this for SMS, but not for a voice recording. You also probably don't want to... but I'll get to that in a moment.

To get the android phone to do things as the delegate of your webserver, you probably want to enable usb debugging on the phone, then use the adb tool to set up a port forward so that a particular local port on the web server forwards to a port on the phone, where you will have a service listening. Keeping that service running may be a little tricky as android is really designed around user-interactive applications, but it probably can be done, especially if you root the phone and launch a native executable with its OOM killer values set to protect it.

You cannot play recorded voice messages into the call audio on today's android phones because the in-call audio bypasses the linux subsystem and is handled instead by the other (radio, etc) processor core. You might be able to do something with a headset cable wired to loopback... but this is getting extreme.

Probably an android phone is not the solution to your application problem... you are going to be dependent on the cell network, on maintaining a plan, and your carrier might allege some grounds for objection.

I think it would be far more appropriate to look into using an sms gateway service, and probably a voip gateway service if the user elects voice notification. Probably someone is already selling a solution to your complete problem.