What is Silent Network Authentication?
Time to read: 5 minutes
Silent Network Authentication (SNA) is a form of secure consumer authentication to protect end-users, accounts, and transactions without requiring users to wait or leave your app. It uses direct carrier connections to verify possession of a phone number in the background without requiring user input. There are neither 6 digit passcodes nor authenticator app downloads, which also means there is nothing for a fraudster to phish. Because of this, SNA is immune to social engineering while continuing to be a user friendly solution.
Silent Network Authentication is built on top of the same system that carriers use to authenticate mobile phone calls and data sessions on the network so your business has a high level of assurance for each verified phone number.
The underlying authentication system is standardized and well trusted but extending this type of authentication to businesses via an API like Verify's Silent Network Authentication channel is relatively new. SNA is sometimes known as "Phone Number Verification" (PNV) or "Header Authentication".
This blog post will walk through what SNA is, how it works, and whether this type of frictionless authentication is a good option for your business. Jump ahead to:
The most attractive feature of SNA is that the authentication process happens in the background.
First, the user provides their login credentials. This can either be a phone number or something like an email address that's linked to a phone number in your application database.
While step #2 is optional, the direct carrier connection and verification can take 1-4 seconds* to complete (still much faster than a one-time passcode flow!). Therefore, we recommend showing the user an interstitial screen while they wait so that the user knows that something is happening in the background to authenticate.
Once the mobile network has authenticated the user, you can redirect them to gated content in your site or application.
Silent Network Authentication is used at sign up, login, or transaction time to validate that a user's SIM (Subscriber Identity Module) is both actively connected to the mobile network and not spoofed or cloned. The SNA technology is built on top of the standardized GSM (Global System for Mobile Communications) authentication.
When a user triggers SNA during login, checkout, or whenever you want your app to perform this verification, the browser or mobile application starts a mobile data session on the device. In order to leverage GSM authentication, SNA must be done using mobile data, not Wi-Fi[1].
Here's an overview of how GSM authentication and SNA work on a technical level:
Step 1:
Mobile network (a.k.a. carrier) activates a SIM with a unique authentication key (known as Ki). This would happen when the user gets a new SIM card. Both parties have the unique key but it is never shared over the network again.
Step 2:
SNA initiates an authentication challenge. The mobile network sends a 128-bit random number (known as RAND) over the network to the SIM.
Now the mobile network and the SIM both have two important pieces of information: the authentication key (Ki) and the random number (RAND).
Step 3:
The SIM and the mobile network both use Ki and RAND as inputs to a one-way function. The output of the one way function is a "signed response" (SRES).
Step 4:
The SIM sends its SRES back to the mobile network.
Step 5:
The mobile network checks to make sure the two SRESs match. If they match, the user is authenticated.
This form of symmetric key cryptography makes it very difficult for an attacker to spoof the SRES, which makes this authentication method both secure and deterministic. SNA has a similar level of security with authenticator apps (TOTP) like Authy or Google Authenticator.
Notice that a user didn’t have to do anything or provide any input in order for the SIM to be authenticated–everything happens in the background. This is the secure and seamless authentication experience that both businesses and end users want.
Check out the documentation to learn more about Twilio Verify's API layer that implements SNA.
Silent Network Authentication is an especially useful form of authentication if your company wants to:
1. Reduce OTP related friction
SNA is the only method that validates phone number possession without requiring additional user input. Watch a side by side comparison below of SMS authentication (left) and SNA (right).
2. Reduce customer support costs related to authentication
If a user encounters too much friction in the authentication process, they'll either abandon their effort or contact support, both of which cost your business money. The frictionless nature of SNA means that the user does not need to remember a password, wait for an OTP, or download an application to authenticate. This saves your business money and time.
3. Improve account security posture
Businesses like SMS for authentication because it's easy to implement and works out of the box globally. However, OTPs can be phished. Defaulting to SNA where possible removes this risk and bolsters security for your app and your users. Then, you can fall back to SMS authentication coupled with SIM Swap detection for a seamless experience.
What are the limitations of using Silent Network Authentication?
Every authentication method has its pros and cons, and while SNA offers a great frictionless experience, it doesn't work in all circumstances. Some things to keep in mind include:
1. Users must be on a cellular connected mobile device (not Wi-Fi)
In order for SNA to work, the session must use mobile data to trigger the underlying GSM authentication process. Wi-Fi bypasses mobile data so SNA will not work over Wi-Fi. You can force requests to be made over mobile data from within your mobile application, but will need to tell the user to disable Wi-Fi if they're using a mobile browser like Safari or Chrome.
2. SNA is only available in certain countries
Twilio Verify SNA will be live in 10 countries, including the US, Canada, UK, Germany, France, Spain, India, Indonesia and more. Reach out to learn more about our coverage.
3. Phones with dual SIM cards require additional configuration
Some users have dual SIM devices which could use two different data networks. The Verify API has built-in dual SIM checks but will require the IP address of the active data session in order to authenticate the user with the correct network. Read more about how to manage dual SIM or reach out to learn more about how we handle this and other edge cases.
Learn more about how to handle these edge cases in Best practices for implementing Silent Network Authentication in production.
For more information about the Verify API implementation, check out the documentation. Then, reach out to sales to get approved and start building.
You might also enjoy these account security best practices:
- Best practices for phone number validation during new user enrollment
- Best practices for managing retry logic with SMS 2FA
- Mobile Intelligence Packages in the Twilio Lookup API
I can't wait to see what you build and secure!
Related Posts
Related Resources
Twilio Docs
From APIs to SDKs to sample apps
API reference documentation, SDKs, helper libraries, quickstarts, and tutorials for your language and platform.
Resource Center
The latest ebooks, industry reports, and webinars
Learn from customer engagement experts to improve your own communication.
Ahoy
Twilio's developer community hub
Best practices, code samples, and inspiration to build communications and digital engagement experiences.