6

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 UI (whether it is a web site or an app) asks user to enter her/his mobile number
  2. Server generates a token sends that token to the provided mobile number
  3. User must switch to a new UI (i.e from a website to a mobile device to find get the SMS. Similarly if the user was originally in an app, then the user must switch to the SMS app
  4. the user then, must copy or memorize the received token to
  5. then user must switch back to the original GUI and
  6. enter the copied or memorized token into the originating web site or app and
  7. hit a key (for example) and
  8. wait for the server to process the entered token
  9. 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
  10. 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.

An alternative scenario:

  1. The UI which user is interacting with (whether it is a web site or an app) asks user to enter their mobile number
  2. Server generates a token and shows that token to the user in the same UI and asks the user to send it to a specified number (Server Messaging Centre Number = SMCN) using the mobile number that is entered by the user.
  3. the user may have to copy or memorize the displayed token,
  4. user must switch to a new UI - for instance, if the original UI is a website, the user must switch to a 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 app on a smartphone to send the token. (however in this case, app may prefill the message)
  5. User sends the message to SMCN
  6. User must switch back to the original UI
  7. Confirm the token has been sent to the server
  8. Wait for the server to process the entered token
  9. 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
  10. Result is displayed on the UI

Which method is better in terms of user experience, security and any other factors?

  • You wouldn't want to change the 'typical' process unless there was a significant gain in doing so. I don't have a problem with the second approach, but I'm not sure what the point of it would really be? Can you shed some light on why this would be better in your opinion? However, from a security perspective, I think both approaches are fine. – Monomeeth Apr 12 '16 at 7:53
  • Instead of listing out the processes, it might be easier for people to understand the difference with an example. For example, I think LinkedIn uses your first scenario, and Whatsapp uses your second scenario - is that right? – Midas Apr 13 '16 at 15:31
  • Thanks for your attention @Midas, I am not sure about which strategy Whatsapp has employed. anyway I've manage to add more details to the question and clarify the reason why I asked it. – anonim Apr 13 '16 at 16:08
  • Just to double check my understanding - are you asking what's a better UX/security approach - user enters code in app, or user texts code to a SMCN? – Midas Apr 13 '16 at 16:36
  • if you have international audience, do you want to set up SMCNs in all countries or ask the users to pay for sending international SMS? or if the number looks funny (e.g. only 4 digits), some users might suspect they will have to pay 5 dollars or whatever (like charity numbers) – Aprillion Apr 17 '16 at 18:28
6
+50

Both are equally good in terms of security.

According to me the first senerio is good enough and adapted one. We are used to first senerio. The second senerio doesn't making much changes and unnecessarily user will confused with the new approch to do things.

In terms of UX, the first senerio is much easy and user know this gonna happen.

Most of the Indian User don't know the SMCN, they have to search for it, this will also create frustration to the user.

In first senerio now user don't have to switch between app and SMS launcher. If he receives any token sms, the notification for SMS on mobile, have code shown in alert only, they just have to remember for atleast 30 seconds.

enter image description here

See the picture above, Now MIUI allows user to just copy the Token from Alert banner [No Need to Switch between Apps].

You can see the mobile manufacturers also adapted to the first senerio and making changes to their UI accordingly.

  • 2
    The OP was suggesting that in the second approach the GUI would specify the SMCN the user had to send the token to. So, having to search for the SMCN and being frustrated by this wouldn't actually be an issue. However, your argument that users are used to the first scenario is a somewhat valid point, although many sites and large organisations still haven't adopted this approach. – Monomeeth Apr 12 '16 at 7:51
  • I meant those are using tokens for verification, they use the first senario. – Abhishek Sharma Apr 12 '16 at 8:58
  • 1
    Are you sure they are the same security wise? I know there are plenty of services that let you spoof your number, depending on how you validate the sender it may appear as if that spoofed number is the real deal. However, as far as I know, no service lets you receive texts sent to another number. – DasBeasto Apr 18 '16 at 19:23
  • They are not equal in terms of security. – Abektes Apr 18 '16 at 20:52
  • What is the difference? – Abhishek Sharma Apr 19 '16 at 8:56
2

I have to be honest and say I have never liked the idea of verifying mobile phones as a security measure. More places are starting to use this as their sole verification method, which causes major problems for people without mobile phones as there is no way for them to create accounts with some of these providers. I do, however, think it is a perfectly valid 'option' for people who are happy to do it this way, just that it shouldn't be the only option available.

Anyway, getting back to your question and the two approaches you're seeking feedback on. Originally I thought they'd both be essentially the same in terms of security, however others here have pointed out that there are problems with the second approach. From a user experience perspective, I think they're both the same in terms of how clunky they are.

If I had to choose one of the two, then the better method in terms of user experience, security and any other factors would be the first one. It's also how more sites are doing it and therefore there may be a familiarity with this approach. Familiarity breeds expectation, and this usually leads to a better user experience because it matches what users are expecting. Here is some further reading to back this assertion up:

So, you don't want to step away from this unless you have something that is significantly better and therefore warrants the change.

A better 4 step process

All that said, I'd like to offer an answer to your main question title: "What is the best mobile number authorization strategy?".

I feel this suggestion would warrant a change because it's a much simpler 4 step process. Not only is it simpler, but it's just as secure, and offers a much better user experience. This is how it would work (let's assume the company is Apple)...

  1. The UI (whether it is a web site or an app) asks user to enter his/her mobile number
  2. The UI instructs the user they are about to receive an automated phone call and to follow the prompts when they do.
  3. The user receives the phone call and the system states something like "Were you expecting this call from Apple - press 1 for yes, 2 for no". If yes, the IVR then requests that the user confirms this again by either speaking or entering the last six digits of the mobile number they entered earlier in the UI. It then confirms the validation and hangs up. If no, the IVR says something like "Thank you. We apologise for any inconvenience".
  4. The original UI refreshes and confirms validation and that the mobile number is now authenticated for the user (unless, of course, the user opted for 'no' they weren't expecting the call).

End of story. Secure, simple, fast. And it offers a much better experience for the user!

This approach is a better option because users already know the six digits, so it's not something they have to 'remember' or switch between screens to access, and the server still does the security/authentication check to confirm the details (i.e. it still verifies the user has access to the mobile number they entered).

Another implementation of this four step process would be for the company to have their server randomly generate something (because they feel this adds to the security - I would argue not), then they could adopt a very similar 4 step process as follows (let's assume the company is Google)...

  1. The UI (whether it is a web site or an app) asks user to enter his/her mobile number
  2. The server generates a random 'easy to remember' word (e.g. "Superman", "Elephant", etc) and shows this to the user, instructing them that they are about to receive an automated phone call and to follow the prompts when they do.
  3. The user receives the phone call and the system states something like "Were you expecting this call from Google - answer yes or no". If yes, the IVR then requests that the user speaks the random easy to remember word previously provided to them. It then confirms the validation and hangs up. If no, the IVR says something like "Thank you. We apologise for any inconvenience".
  4. The original UI refreshes and confirms validation and that the mobile number is now authenticated for the user (unless, of course, the user opted for 'no' they weren't expecting the call).

Now personally I prefer the first 4 step process only because it avoids any possible issues around language or accents in terms of voice recognition or the user's comprehension. This issue is covered by research, for example:

If these risks were not an issue, I'd probably prefer the second approach. But either approach is to my mind a much simpler process that takes less than half the previous steps and offers a much better experience for users.

Another option, if the original user interface was a mobile app, is to fast track Step 1 by automatically acquiring the user's mobile number from their device (if it's a mobile phone). However, I do think you would still need Step 1 in that it would be asking the user to confirm if this was the number they wanted to use.

Anyway this is my take on the best mobile number authorization strategy.

:)

  • surly this is not authorisation in step 3 there is no new information here, as the receiver has the phone they know the phone number. The second one does do a check – user151019 Apr 17 '16 at 20:48
  • I disagree - to me all that is being 'checked' is that the mobile number in fact belongs to the user who entered it into the UI. If the system then calls this number, and the person responds "yes" that they were expecting the call, then this effectively verifies the number belongs to (or is used by) the user. You could almost skip entering the six digits altogether, but I think having both steps increases security because if someone accidentally answers "yes" they're likely to just hang up rather than proceed with entering the six digits. If both actions don't happen, then verification fails. – Monomeeth Apr 17 '16 at 22:55
  • However, your point is taken and that is why I provided the second 4 step option, because I know some people may feel that having something randomly generated is a more secure process. I've also slightly modified my first 4 step process so the system makes it clear that entering the six digits is a second confirmation that they were expecting the call. If not the user would just hang up (probably thinking it was a prank call). Either way, both the 'yes' and the 'six digits' are required for verification. – Monomeeth Apr 17 '16 at 23:20
1

Sorry to use the answer function, but I don't have enough reputation to comment yet. :(

I just wanted to say I really like the 4 step approach that Monomeeth suggests. I'm a huge fan of the KISS principle and this approach seems to fit.

The only negative of it that I can see is if you're laying in bed in the middle of the night next to your partner and you got a phone call, it may not go down too well, so the UI would need to let users know prior to them providing their number what the process was going to be, so they can decide at that point whether now was the best time to verify their mobile number or whether they should wait.

Otherwise though 4 simple steps would be much preferred to the 11 steps outlined in the question.

  • Haha thanks. I'm a big fan of the Keep It Simple, Stupid principle too. And don't worry, we all know what it's like to have to wait before being able to comment. :) – Monomeeth Apr 17 '16 at 23:16
1

I'm surprised that nobody has pointed out that this is wide open to a spoofing attack.

Sending an SMS with a spoofed originator (the sender) is incredibly easy and costs very little to do.

You can't trust that the message has come from the genuine owner of the number (or even that the number exists at all).

The traditional model (where you send the user a message) is more secure because you are verifying that:

  1. The number exists and can receive messages
  2. The person you are trying to "authenticate" has access to the service linked to that number
  • Excellent point! At the end of the day all we're really trying to do is verify the user has access to the mobile number the system is trying to verify and the second 11 point process outlined in the question can't do that with any certainty (at least not with the certainty required by IT Security professionals). It's also why I like my four step proposals because they do achieve that and do it so much more simply. – Monomeeth Apr 18 '16 at 18:32
1

Two-way verifications are much more secure due to using different communication channels. The first path will be better in terms of user experience and security.

You need to reduce the barrier

Two-way verification cycles can be embedded to sign-up process. SMS for an individual can cost money. If you make your user to pay for your SMS; they can feel that as another barrier. SMS is not the only way; automated phone communication is also used for completing these verification cycles. User will not want to pay for such basic patterns.

Where will user-journey continue? Stay there

In many verification cases; SMS are not the main channel and user will continue with browser or software piece. Since user will continue from Screen; returning screen and getting (proval/rejection) from screen will be better in terms of user experience.

SMS Sender number/text is not secure!

The sender number can be changed manually and it is not as secure as you think. As Daveoc64 suggested; trusting a number in SMS world is not pretty safe since it can be distorted. In addition to his point; SMS can be carried through different providers for using the unused capacity which leaves too much tracks and can be listened by other companies. There is a misunderstanding here; Two Factor Authentication makes you secure; not SMS channel itself

0

There is a lot already happening to improve this UX, of switching apps to see token value. Let me summarize:

1) A lot of apps today are able to wait and read the incoming SMS to detect the code and pre-fill it for the user. I think that is a very good way forward and more of a enhancement rather than a total new solution. It has a back compatibility that if the app is not able to detect than the user anyways can go and check for the SMS token. In most scenarios, the token is automatically read correctly. Reference: https://www.quora.com/In-any-mobile-app-transaction-can-an-app-read-the-OTP-SMS-and-auto-fill-the-bank-page-to-finish-the-transaction

2)As @Abhishek Sharma points above, that the alert is a great way to remember the token and add it. Most of us rely on that. Sometime time back I had written a post about PAYTM doing the OTP message wrongly, so as to put the token value deep in the message rather than in the first opening line, which makes it easy to view in a top bar alert. Article here: https://pregnantwithideas.wordpress.com/2015/08/07/paytm-com-user-experience-review/. Paytm changed this behavior post the same.

0

In terms of security, both will be pretty similar.

However, in terms of user friendly, I would not request my user to send a text message to my system. Not everyone has text messages in their plan, since the age of whatsapp, imessage and the like. It could possibly cost them a small amount of money and that could be a barrier.

Unless of course, it costs extra to send the text message to the specified number, and it is part of the earnings plan.

I think overall option 1 is more user friendly.

Also -this has been stated before-, when working on a mobile device, usually the incoming text message is briefly displayed while being in any app. That means a user might not even have to move out of the current app and can just type in the recieved security key immediately. This makes option 1 the faster option as well as the cheapest (for the user).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.