API authentication with mobile app (by SMS)

Question

We are currently tasked with implementing a (preferably simple) authentication system for a mobile application communication with a RESTful API. The backend has user-specific data, identified by the user's phone number. I am trying to understand more about security in general, the different methods there are and why they work the way they work.

I thought of a simple authentication system:

• The client sends a verification request to the api which includes their phone number and a generated guid.
• The server sends an SMS message to the phone number with a verification code.
• The client verifies their device by sending their unique guid, phone number and verification code.
• The server responds with some kind of access token which the client can use for further requests.

I have the following questions:

Are there any major flaws in this approach? Assuming we use HTTPS, is it secure enough to send the data otherwise unencrypted? Can access tokens be stored on mobile devices safely so that only our app can read them? Anything else we haven't thought of?

We already figured that when the mobile phone is stolen or otherwise compromised, the data is no longer secure, but that is a risk that is hard to overcome. Access tokens could be valid temporarily to minimize this risk.

I am assuming this approach is way to simple and there is a huge flaw somewhere :) Can you enlighten me?

Answer 1

There is a flaw. The system is susceptible to a brute-force attack.

Suppose I am an attacker. I will generate a guid for myself and send it along with some arbitrary phone number.

Next, I will just bruteforce my way through the possible SMS codes - if it's 6 digits, there's only 10^6 combinations. The bruteforce will be a matter of seconds - and then I will gain acess to the data of the person having this phone.

Also, as was pointed out in the comment by Filou, one can force you to send you arbitrary number of SMS, effectively making you sustain a financial loss at no cost.

There's also no valid defense from this attack:

1. If there is limited amount (N) of attempts for a given UID, I will re-generate the guid every N attempts.
2. If there's a limit of requests per phone per amount of time, I can execute a DoS/DDoS attack by flooding every possible number with fake requests - hence, noone will be able to perform any requests.

A login/password or certificate authenication is mandatory before an SMS. Also:

1. Never use things like GUID in cryptography/security protocols. GUIDs are deterministic (i.e., knowing one value, you can predict future ones). Use crypto-libraries built-in functions for generating random streams
2. Never try to design security protocols yourself. Never. There's an awful lot of caveats even SSL 1.0 creators fell to - and they were sharp guys, mind you. Better copy common and proven schemes (Google's auth is a great example).