For new development, we encourage you to use the Verify API instead of the Authy API. The Verify API is an evolution of the Authy API with continued support for SMS, voice, and email one-time passcodes, an improved developer experience and new features including:
- Access via the Twilio CLI
- WhatsApp channel
- App-agnostic TOTP
- Push authentication SDK embeddable in your own application
Account security is difficult. Make the requirements too onerous, and no one will adopt your solution; make it too simple, and fraudsters will surely be able to circumvent any protection you provide. In this post, we’ll discuss how to use the Authy product to provide solutions for both regular and high-value users using features present in the Authy product suite. Before we outline that approach, it is best to understand how the current Authy user model and multi-device feature both work.
Authy User Model
There is a one to one correlation between a user’s phone number and their Authy ID. The user’s Authy ID is created or provided when you register the user with your service’s workflow. This Authy ID is core to how the Authy API interacts with end-users.
If you’re initiating two-factor authentication (2FA) via any of Authy’s authentication channels, the Authy ID is the only piece of unique user information used in the API call. No phone number, no email, just your user’s Authy ID.
Read more about the Authy User model here.
Multi-Device Circle of Trust
Authy provides several ways to authenticate with a second factor, including Time-based One Time Password (TOTP) generation and Push notifications. We have also architected the Authy platform to allow the customer to authenticate from any device they have added to their circle of trust. This multi-device feature is useful when carrier access is unavailable (airplane, battery dead, traveling) or when a device has been inadvertently put to pasture. End users can create this circle of trust by adding any iOS, Android, or Desktop application to their account. You can read more about multi-device support here.
During the Authy device setup, our backend will fingerprint each device and assign a unique device_id. Since we identify each of these devices, we will also generate a unique TOTP per device. When submitting the TOTP code or approving a Push notification, the backend recognizes the authenticating device and includes its device_id in the API response.
SMS for Some, Device-Specific TOTP and Push for Others
You can protect a variety of user types with our Authy API. For example, if you’re operating a crypto site, you may have some users who are just lookie-loos and create a basic account to dabble with a few hundred dollars. You may have other tech-savvy and security-minded customers who have invested a considerable amount of time and money into their crypto moonshot. These are two very different types of users and should be treated as such.
For those users who are just dabbling in crypto on your Bitcoin site, SMS is a satisfactory 2FA solution. Yes, they could be subjected to the SS7 or SIM Swap attacks but what hacker is going to exert that amount of effort to steal a trivial amount of crypto? SMS or Voice delivery for these users is an excellent solution as it doesn’t require too much effort to implement and provides a reasonable level of protection.
The high net-worth individuals are another situation entirely. You may want to guide these users away from SMS or Voice OTP delivery and towards device-specific TOTP and Push Authentication. This is where the device_id becomes very useful. When verifying a TOTP code or Push Authentication, the API response includes the device_id. If you check both the verification status (approved/denied) and the device_id, you have a very secure way to protect your high net-worth users.
Indeed, several of our customers with riskier use case scenarios will limit their users verifying device to the initially registered device. If they detect users authenticating from an unknown device, they will either ban the user outright or push their users through a new device process. The following workflow outlines this suggested approach:
- Register your user (PII-less or normal Authy user registration approaches).
- Instruct the user to install the Authy app if they haven’t already.
- Post-installation, have the user verify with either TOTP or Push.
- Record the device_id of the verifying device.
- All subsequent verifications will check device status AND device_id before granting the user access.
Best Practice Workflow for Device-Specific Approval
Authy is a pretty flexible security product and provides many ways to protect your users with two-factor authentication. For your high-value users, it is probably worth the additional effort to identify their authenticating devices and gate authentications from specific devices. Regardless of your user base, the effort to enable multiple channels is not significantly more work than enabling just a single channel. By combining this multi-channel approach with escalated device identification, Authy provides a very secure solution for even the most sensitive use-cases.