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)...
- The UI (whether it is a web site or an app) asks user to enter his/her mobile number
- The UI instructs the user they are about to receive an automated phone call and to follow the prompts when they do.
- 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".
- 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)...
- The UI (whether it is a web site or an app) asks user to enter his/her mobile number
- 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.
- 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".
- 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.
:)