SMS Based Login

[soulweaver]

We have been trying to implement an easy SMS based login (a la Hotstar) for a website (The website is for tests and assessments). We have tried some sms vendors, but they all seem to be failing to deliver to one country or another. We have users from across the world. Is there any service that serves all countries without being unreasonably expensive?

The site is looking at about 10K users per year.

Any suggestions about how to implement this would also be welcome.

• Should the users always login via SMS?
• Should the website keep them logged in?
• Is there an easy, non painful way of switching users over to passwords?

These are all questions we are pondering over. So inputs from you guys will be very helpful.

 

[kalph09]

Have you considered broker apps like Ping ID? It is similar to Authy we use here.

PingID offers you to enter a 6-digit code or something simpler like gesture-based (swipe up/down) to complete 2FA.

 

[soulweaver]

Have you considered broker apps like Ping ID? It is similar to Authy we use here.

PingID offers you to enter a 6-digit code or something simpler like gesture-based (swipe up/down) to complete 2FA.

Thank you for taking time and suggesting this.

From what I can see, PingID seems like overkill. Please do let me know if I am wrong. We are looking at only logins.

Once a user comes on to the website, s/he clicks on a test.
To take the s/he needs to be logged in.
Once the user clicks take test button - if they are not logged in, a login screen pops-up where the user is prompted for a phone number.
The user gets an OTP.
Once the user enters the OTP, the login is done
The user is redirected to the Test page.

Something that like that. From my cursory look into the services of PingID, I wasn't too certain it would suit our needs/be overkill.

I will ask someone who is more technically inclined than I am to also look into it!

 

[kalph09]

In our case, we have deployed PingID for 200k employees. It works similar to RSA SecureID when offline (no cellular connectivity needed)

From an organizational standpoint having a large number of apps, pingID works brilliantly.

For your use case, am assuming this is for external users across different geos and not employees. In such a case, PingID might not be feasible as the app must be pre-configured before they can use it and needs a team to manage the accounts and its infra.

 

[valar007]

We have been trying to implement an easy SMS based login (a la Hotstar) for a website (The website is for tests and assessments). We have tried some sms vendors, but they all seem to be failing to deliver to one country or another. We have users from across the world. Is there any service that serves all countries without being unreasonably expensive?

The site is looking at about 10K users per year.

Any suggestions about how to implement this would also be welcome.

• Should the users always login via SMS?
• Should the website keep them logged in?
• Is there an easy, non painful way of switching users over to passwords?

These are all questions we are pondering over. So inputs from you guys will be very helpful.

Before answering your questions, I have a couple of questions:

• Are you firm on your users using a phone number for login? Could this be changed to an email ID based login as some people might not be comfortable with sharing their phone number.
• What is your users' demography? A couple of top countries will be fine
• What is the use cases for initiating an SMS? Is it only for login or is it also for sending the test results/analytics?

Our company's majority of the users are present in US. So, to send an SMS to them, we make use of AT&T (https://www.att.com/support/article/wireless/KM1061254), Verizon, T-Mobile's email delivery service where we send an email to these mobile providers, the title being the user's phone number and the body being the text content. This helps us save costs. For the other users, who are not present in US or whose carrier's do not support email based SMS sending, we make use of Twilio to send the SMS. But Twilio itself has some limitations. While testing, we found out that users in India cannot receive the SMS after 9PM due to some anti-spam rule. Also Twilio's delivery success percent is like 60% for India. Other service you can use to send an SMS is https://docs.aws.amazon.com/sns/latest/dg/sns-supported-regions-countries.html

I think I get why you want to use phone number and OTP based login. You don't want to store the password of the users. There are many tools that help in managing users and their data. You can look into Keycloak, AWS Cognito. I recently completed a project where we implemented Oauth2 and openid based login. You might want to take a look at that. By implementing oauth2 based login, you'll get 3 tokens, access, id and refresh token. Usually, id and access token has 1 hour validity and refresh token has 30 days validity. You can then send access token to authenticate the request and verify this token in the backend. You can store the refresh token as a part of cookies in the user browser. When the user navigates to the site, you can use the refresh token to fetch the new id and access token. By doing so, the user can have access to the site for 30 days (this can be configurable) after logging in

 

[soulweaver]

@valar007 Thank you for a detailed, painstaking response.

We started off with email based logins but the users were mistyping email addresses or using wrong email addresses. When time came to reset passwords or request for information or ask for help, there were out in the cold as were we. It was getting cumbersome, and was leaving us with a lot of dead ends. A lot of support tickets could not be closed.

Apart from India, we have users from Eurasia (primarily the former USSR states and Southeast Asia), South America, Africa. We have some users too from USA, UK, and Australia. So the mix is fair.

Even with SMS, like you said, the success rates are pretty low, and we are struggling to find a way to sort it out. Being a small company, the budgets are also limited since we are not using user data in any way (no storing, marketing, selling, cross-selling, nothing). we do not want this to be a money sink.

Even if the user is logging in via sms, we have no issues with them setting their own passwords and using only that later and if they do forget it, they can have the option to login via SMS. The option to have an email based login too is going to be available.

 

[valar007]

We started off with email based logins but the users were mistyping email addresses or using wrong email addresses. When time came to reset passwords or request for information or ask for help, there were out in the cold as were we. It was getting cumbersome, and was leaving us with a lot of dead ends. A lot of support tickets could not be closed.

I think I see a problem with this step. I think your flow is this: User registers themselves with an email ID and password. They click on save email ID and password for this site. Once they land on the login page, they click on autofill option. Once the user registers, you'll have to send them a confirm registration to their email ID. Only once they click on that verification email, they'll be able to access your site. Once this is sorted out, you'll be able to close more number of tickets and at a much quicker rate.

Even with SMS, like you said, the success rates are pretty low, and we are struggling to find a way to sort it out. Being a small company, the budgets are also limited since we are not using user data in any way (no storing, marketing, selling, cross-selling, nothing). we do not want this to be a money sink.

Look into this: https://avtech.com/articles/138/list-of-email-to-sms-addresses/ . You'll have to let them add their number and choose their carrier. Once it is done, have an option for the user to trigger a test SMS to that number. By doing so, you'll reduce the number of SMSes sent to the incorrect number and also the user can rectify their mistake then and there itself. We were primarily using Twilio to send SMSes and we were getting charged $100 everyday. By implementing this, email to SMS method, we have reduced the Twilio costs to less than $10 a day

 

[singenaadam]

If your service involves financial transactions or confidential info/IP, better stick to standard 2FA providers like Google, MS, or the above-mentioned Authy. SMS-based logins are being phased out due to security concerns.

 

[soulweaver]

I think I see a problem with this step. I think your flow is this: User registers themselves with an email ID and password. They click on save email ID and password for this site. Once they land on the login page, they click on autofill option. Once the user registers, you'll have to send them a confirm registration to their email ID. Only once they click on that verification email, they'll be able to access your site. Once this is sorted out, you'll be able to close more number of tickets and at a much quicker rate.

We do have email authentication, but most users are not doing it. That is why we wanted to switch to SMS based. In fact, we do not like SMS based and much prefer email based auth. But the crowd we are targeting do not seem to be interested in checking their email at all.

We thought of enabling login via Google/Facebook, but did not want to for several reasons.