Holiday shopping is upon us (actually, it started weeks ago), and e-commerce apps are depending on customers moving through shopping flows and completing sales. Marketing experts will tell you that “friction” is the enemy: stoplights in the process that slow down customer traffic and create frustration and abandonment.
While optimizing shopping flows is an important aspect of this process, the biggest hurdle is fraud prevention. Users find themselves constantly being stopped to log in with usernames and passwords, copy and paste SMS authentication codes, check emails for passcodes, click on each picture of an intersection, or type nearly impossible-to-see text in CAPTCHAs.
Authentication is a necessary hurdle to keep consumer information safe. This applies to more than just shopping, as financial services, medical and health, utility companies, and more collect identifying information. Keeping that data safe and preventing fraud is a priority. Users are constantly bombarded with tracking twenty-character passwords, multi-factor authentication steps, and accepting cookies.
Twilio offers a glimpse of what the future of frictionless might look like. Silent Network Authentication (SNA) can protect user accounts and transactions without copying and pasting passcodes or selecting only pictures of birds. The advantage of this process is two-fold. Not only can customers conduct their transactions safely, but the lack of information sent via web forms or text messaging provides fewer opportunities for fraudsters to phish identifying information.
How does Twilio’s Silent Network Authentication work? SNA requires a phone operating on a mobile network (not Wi-Fi). On a shopping app, for example, the user submits a valid phone number or email address associated with their account. With one click, the authentication process happens in the background with no further user interaction needed.
The mobile network generates a unique key using the user’s SIM and a random 128-bit number. These two pieces of information are sent to a one-way function via API. The output of this function is called a signed response (SRES). The SRES is sent back to the mobile network, which checks the user’s SRES against the SRES it currently holds. If the two match, the user is authenticated and logged in.
Learn more about Twilio Verify’s API layer that implements SNA.
The benefits of SNA include:
- Reducing friction and complexity that come with making customers use an SMS or CAPTCHA-based authentication process;
- Reducing passwords or forcing customers to download an authentication app like Google or Microsoft Authenticator;
- Eliminating form entries or exposed security steps that can be phished to capture customer information.
If the customer has swapped their current phone SIM for another since the last authentication attempt, the authentication system can fall back to an SMS-based passcode or another authentication process.
There are a few important considerations when using Silent Network Authentication, though.
SNA requires a SIM-based cell phone and a mobile network to generate the signed response key. This key requires a mobile network and cannot be generated over a Wi-Fi connection. SNA currently applies only to phone apps or web browsers connected to a cellular network. In some cases, the app may have to tell the user to disable Wi-Fi if using a mobile web browser (such as Chrome or Safari) to force the phone to use the cellular network. This represents an extra step in the authentication process and may not be desirable.
Twilio’s Verify API can handle dual SIMs (a cell phone for one region that can switch over to a different cell phone region) but requires the IP address of the active data session to authenticate the user with the correct mobile network. These and other edge cases may also apply.
The possibilities of SNA are only beginning as Twilio plans to roll out SNA to the United States and many other countries. To learn more about how Twilio and Terazo can build something great together for your next project, contact us at firstname.lastname@example.org.