mobile number authorization strategy using SMS, best pattern and practices

Question

In recent years, mobile number has become an important factor for authentication and hence more and more enterprises employ methods to capture their users' mobile numbers using SMS.

In a typical scenario;

1. the GUI which user is interacting with (whether it is a web site or an app) asks user to enter her/his mobile number
2. then server generates a token and
3. sends that token to the provided mobile number
4. then user must switch to a new GUI for instance, if the original GUI is a web site, user must switch to her/his mobile device's to find the received message in SMS inbox. it is the same if user was originally in an app. in that case user must switch to SMS manager app on her/his Smartphone
5. the user then, must copy or memorize the received token to
6. then user must switch back to the original GUI and
7. enter the copied or memorized token into the originating web site or app and
8. hit a key (for example) and
9. wait for the server to process the entered token
10. at the end, server validates entered token and if it is correct then authorizes that mobile number and may set it as an authentication mean for the user and
11. finally the result is displayed on the GUI

this is a typical scenario which most of well known IT companies (such as Google, Facebook and others) use to authorize their users.

now assume another scenario,

1. the GUI which user is interacting with (whether it is a web site or an app) asks user to enter her/his mobile number
2. then server generates a token and
3. shows that token to the user in the same GUI and asks the user to send it to a specified number (Server Messaging Centre Number = SMCN) using the mobile number that is entered by user.
4. the user may have to copy or memorize the displayed token,
5. then user must switch to a new GUI, for instance, if the original GUI is a web site, user must switch to her/his mobile device to type the token and send it to SMCN. it is the same if user was originally in an app. in that case user must switch to SMS manager app on her/his Smartphone to send the token. however in this case, app may employ smart device's programming API to call SMS Launcher and pre-fills the address and content of the message on behalf of the user.
6. the user just sends the message to SMCN,
7. then user must switch back to the original GUI and
8. hit a key to declare that the token has been sent to the server and
9. wait for the server to process the entered token
10. at the end, server validates entered token and if it is correct then authorizes that mobile number and may set it as an authentication mean for the user and
11. finally the result is displayed on the GUI

now the question is, which method is better in terms of security and other factors if there is any?

EDITED:

I have updated the question based on @Andre edit and answer for better understanding,

first, both methods may use in authentication as well as authorization. assume the case that someone have logged into her/his Internet Banking account and wants to transfer money, here the mentioned methods may use to authorize user and grant her to transfer money or not.

second, let's focus on comparing these two methods and not talking about downside of using SMS in authN and authZ process.

Third, comparing two alternatives, (as I said before) in both cases users have to memorize or copy something then leave one environment for another and type or paste it. So, it sounds like, in terms of usability both methods are the same; as in method one, user have to type something received in SMS into the original GUI and in method two, user have to type something seen in original GUI into SMS send|receive GUI. Therefore in both cases, user may make something wrong.

Answer 1

Lets look at some different attacks and how they impact the two different systems, followed by some usability considerations.

Control of phone (draw)

If the attacker has full controll over the phone, it is game over no matter what. However, an attacker may have been able to get a trojan onto ther phone that only has limited permissions. At least on Android, reading and sending SMS is different permissions. However, this secnario feels rather contrived and I see no reason why it would be harder to get one permission than is is to get the other.

Social engineering (#1 wins)

To fool some users to read the code is easy if that is all the message contains. Call the user, say that you are from the cell phone company testing the reception or whatever, and that they will soon recieve a message to read back. (A competent attacker could come up with a way better lie than I just did.)

However, this can be made hard if the SMS contains an explanation of what the code is (and perhaps an exlpicit warning against phising), thereby revealing all your social engineering lies.

A user that has to send an SMS can get not such warning. That user could fall for tricks like "just send this code to this number to claim your free sport car". Not everybody would fall for this, but some would, especially if it is for a service they seldom use so they do not recognice the number.

Eavesdropping on the phone network (#2 wins)

As GSM encryption is famously weak, and fake cell phone towers to use for MitM can be bought on the internet, an attacker might try to eavesdropp on the SMS communication. This is not a theoretical threat, but something that is done in the wild.

With system one, an eavesdropper has to read the passcode that is sent to the user when they try to login. The attacker then needs to use it before the user (should be easy if the process is automated). This requires the attacker to be in the physical proximity of the target when the user happens to login to the service.

With system two, it doesn't matter if the attacker reads the SMS. The passcode is (or at least should be) unique to the users device, and the attacker can not authenticate on his device even if he knows the passcode the user sent.

SMS spoofing (#1 wins, major issue)

SMS spoofing is a very real thing that is used in the wild. If the attacker can spoof the users phone number in an SMS, he can overcome alternative two. This is a major weakness in that approach.

I just googled "free SMS spoofing service" and came up with this site. Surely even your computer illierate uncle could do the same, thereby bypassing your authentication scheme.

Usability (#1 wins)

Alternative two has some downside when it comes to usability:

• The user has to enter a passcode and a number to send it to. This takes longer time. Two things to copy paste is twice as many as one.
• The user might enter the wrong phone number, resulting in a failed login. If the wrong passcode is entered in alternative one, it is easy to give appropriate feedback to the user. If an incorrect phone number is entered, it is hard for the server to know what happend and give the right feedback to the user.
• Sending a SMS might cost money for the user.

Conclusion

On security, it is 2-1 to alternative one. But how serious are the different vulnerabilities? I would argue that especially SMS spoofing but also social engineering are larger threats than eavesdropping. They can both be done from anywhere in the world, and require much less effort and technical knowledge. SMS spoofing could possibly be done automated on a large scale.

So even leaving usability to the side, I would argue that alternative one is the safer alternative.

TL;DR

You can spoof the sender of an SMS, making them useless for identifying the sender. Use the first alternative.

Answer 2

The two options are distinct in the following way:

1. The company sends the SMS to the customer
2. The customer sends the SMS to the company

If we think carefully about how identity is verified in telephone networks, we will discover the core security issue the leads companies to choose option 1. Whenever you place a call or send an SMS, you know what number you are calling. However, when you receive a call or an SMS, you have no idea where it originated.

Let's look at this issue from the company's perspective. Their goal is to verify the user's identity in two ways. The company already trusts itself. The user's identity is verified by password and by receiving an SMS. The company knows that the SMS will arrive at the phone number that they send it to, since this is how the telephone system works. So, if the same person has the password and the telephone, they also have the SMS message and the token it contains. Trust is established.

In the second option, trust cannot be established from the perspective of the company. The company will receive an SMS from an arbitrary source and will not be able to determine what phone number it originated at. (Ironically, the customer can verify the company's identity this way, but the company cannot verify the customer's identity).

This is the same reason that we are told never to give banking details to someone that calls claiming to be from our bank. Instead, prudent people will hang up and dial their bank's phone number to verify the identity of the person they are speaking to.