Authy trust-chain for added devices

Authy trust-chain for added devices

Lately, we've seen a number of news items concerning SIM swapping. That's where hackers take advantage of limitations in mobile devices and SMS-based communications to commit identity theft or account takeovers. There have even been some questions about whether authenticator apps that don't rely on SMS for token delivery are also susceptible. Or whether or not a SIM swap would enable a hacker to assume control of a phone number and install an authentication app to gain access to an already-protected online account.

Twilio is now providing tools to help our authentication customers address this  issue. Working together, the Authy authentication API and the free Authy 2FA app create a chain of trust that allows Twilio/Authy customers to determine which end-user apps to trust for authentication. They record uniquely identifiable numbers assigned to every installed app, as well as the sequence of app installs and the methods of installation. Through the Authy status API, Twilio authentication customers can protect their users 24/7 by examining each authentication attempt to decide,  instantaneously, which are trustworthy.

Let’s look at a hypothetical scenario featuring a crypto-trader and a hacker:

Meet Bob
Bob, who’s dipping his toe in the world of Bitcoin, decides to open an account with the Gemini exchange so that he can buy, sell, and securely store cryptocurrencies. When he signs up for his new Gemini account, he is prompted to also enable two-factor authentication (2FA). Gemini employs Twilio’s Authy API for 2FA, and since Bob has never used Authy, he downloads and installs the free Authy app to his iPhone. In the process, Bob is required to authenticate his identity to the app using a one-time password (OTP) via SMS message or voice.

At this point, Bob has 2FA enabled as part of his login to Gemini. In doing so, Gemini records that Authy was installed on Bob’s iPhone, regards it as the initial trusted device, and knows that the Authy API has assigned it an AuthyID. For purposes of this article, let’s assume the ID given is “1111” and has a creation date of 1/1/2019.

About a month later, Bob learns that Authy offers the added convenience of authenticating from multiple devices. He decides he’d like to be able to use Authy on his iPad and installs it there. To activate Authy on his iPad, Bob is given the option of selecting “Push” as a method of authenticating himself. Upon selecting this option, the Authy app on his initial trusted device, his iPhone, receives a push notification, which leads him to approve the installation of Authy on his iPad. The Authy API assigns this device with the AuthyID “2222” and a creation date of 2/2/2019. It also reports that device id 2222 was registered via Push notification, and lists AuthyID 1111 as the approving device.

When Bob next signs in to Gemini and authenticates using Authy, the Authy API examines where the authentication token — also called a time-based one-time password (TOTP) — came from. If Bob used his iPhone, Gemini looks at the device id and, based on the creation date, understands that it was the first instance of Authy on Bob’s account. Therefore, it can be trusted for authentication.

If Bob used his iPad to authenticate, a red flag goes up, because Gemini has never before seen this device being used by Bob for authentication. Before allowing authentication, Gemini reviews both the device id (2222) and how the device was registered. It recognizes that the iPad was registered with Authy via Push, and was approved from a known device (1111, Bob’s iPhone) after the known device was registered. With this data, Gemini concludes that Bob’s iPad can be added to the list of trusted devices and allows Bob to log in successfully.

Meet Eve
Eve is a hacker. And not an ethical one. She’s after cryptos and has decided to target low-hanging fruit novices like Bob. Because Bob tends to reuse passwords, Eve guessed that his Gemini username and password would be identical to those exposed in a recent data breach of a social network. Through a SIM swap Eve also took ownership of Bob’s phone number.

Eve probably knows that Gemini doesn’t trust SMS for device installation and instead relies on the superior security of Authy for user authentication. She doesn’t have access to any of Bob’s devices, so Eve downloads and installs a copy of Authy to an Android phone. Then she registers it using SMS, just like Bob did on his iPhone. Authy records this as a new device, an Android, and assigns it the AuthyID “3333” with a create date of 3/1/2019. It also records that this device was registered via SMS.

Eve attempts to log in to Bob’s Gemini account using the stolen login credentials and her Authy app. Just like when Bob logged in to Gemini using his iPad, the Authy API is unfamiliar with this instance of Authy tied to Bob’s account.

Gemini reviews this device id (3333), the registration date (March 1st), and the registration method (SMS), of this authentication attempt. The company determines that this isn’t the first device to be authenticated, nor has it been approved by another trusted device. Therefore, there is no link in the chain back to either of Bob’s already-trusted devices. Eve’s Android cannot be trusted. At this point, Gemini emails Bob asking if this device should be approved.

Authy Remembers
Not giving up, Eve tries to get around this chain of trust. She installs Authy on an Android tablet this time, using her Android phone to approve by responding to a Push notification. This generates another AuthyID — “4444” — with a notation that it was registered via Push. In an attempt to cover her tracks, Eve might even use the Authy app on her Android tablet to remove device id 3333, her Android phone. But the Authy API still remembers the previous untrusted device, and this new device, linked via the registration data back to the untrusted device, is a dead end.

Back to Bob
By this time, Bob has responded to the email from Gemini, letting them know that it was not him trying to login. He has since returned to his account, entered his login credentials, and used his second trusted device — his iPad — to successfully authenticate and gain access. After changing his password, Bob can relax knowing that Gemini is keeping his cryptos secure. Bob can also take a moment to revoke access via his SIM-swapped iPhone, and add another device if he likes. Authy suggests that users set the “allow multi-device” toggle to OFF on both devices to keep future attackers from installing fraudulent Authy apps with just an SMS or voice call.

Key Takeaways

By looking at the sequence of app installs, combined with the methods of installation, a chain of trust has been established to help Gemini determine which app installs they can trust and which they can not.

In short, here’s what a Twilio authentication customer should know:

• If an SMS-based one-time password (OTP) is passed, no risk assessment is made (unless there is already a device assigned to the user account).
• If a time-based one-time password (TOTP) is given from a known and trusted device, allow the login.
• If a TOTP is provided from an unknown device, and SMS or phone call is the device registration method, do not trust the device and contact the account owner for account denial/approval. However, it is helpful to check the IP of the unknown device to see if it matches an IP previously used by the user.
• If Push notification to an already-trusted device is the registration method, trust this new device. Push notification is a more secure method of approval for adding new devices.