Security Notice: Authy Response To Cloudflare CloudBleed Incident
On Thursday 23rd February 2017, the security team at Twilio was notified about a problem with Cloudflare, one of our service providers. Cloudflare had identified a bug in their service that exposed customer data and some of it was cached in internet search engines such as Google, Bing and Yahoo. For more detail on the bug itself, please read the Cloudflare blog.
Before we get into detail, there are three important things you need to know.
- At this time, there is no evidence that any Authy data was exposed as a result of this incident.
- All 2FA tokens generated by the Authy 2FA API have been rotated, rendering any exposed tokens unusable.
- All 2FA tokens captured via QR code via the Authy app, are encrypted with a password never stored in Authy and only ever decrypted locally in the app.
Twilio and Authy are working closely with Cloudflare to understand the ongoing impact of the incident. According to Cloudflare, Authy data was not discovered in any known cache. However, we are nonetheless treating this incident as if we have been impacted.
There are two main concerns we have from this incident.
- Protecting our customers that use the Authy API to secure their applications
- Protecting our user’s data in the Authy app, where they store and access 2FA data
1. If you are an Authy customer and use the Authy API
The greatest risk is that your API key is exposed, therefore you must login to the Authy administrative dashboard or console and rotate or generate a new API key. You also have the ability to revoke the old key immediately, as soon as you’ve updated your production systems with the new key. You can also configure a whitelist of fixed IP addresses from which your application communicates to the Authy API. In addition, we have terminated all open sessions to our dashboard, requiring you to sign in again.
We have created a short video showing how to rotate the keys and how to set the whitelist for IP addresses:
2. If you or your users use the Authy apps
If you use the Authy app on iOS, Android or our Desktop version, all you need to do is start your Authy app, at which point it will communicate with our service and be told to regenerate its keys.
There are three kinds of data used in the app that are sent to our cloud service:
- Authy tokens generated by customers of our API. As soon as we knew about the incident, we immediately initiated a process to rotate all device keys that secure the Authy tokens. The next time you open the Authy app, it communicates with our service and will generate new keys. This is a silent action and doesn’t require any input from the user other than starting the app.
- Google Authenticator tokens that users have scanned and backed up to the Authy cloud service. Tokens are encrypted in the app using a key derived from the user-typed password, and the tokens are sent to us and securely stored. The password is never stored in Authy and therefore was never at risk from being exposed. Our general guidance, however, would be for users to re-enroll their Google Authenticator tokens at each site they use.
- Authy OneTouch requests generated by customers of our API. No key rotation is needed, as the private key data never leaves the devices.
At the time of the publishing of this post, there is no evidence that Authy data was exposed as a result of the incident. We are continuing to work closely with Cloudflare and our customers to evaluate any impact. We are also monitoring our service to ensure customers are rotating API keys, and we will be reaching out to customers proactively to prompt them to do so.
As with any incident, we will examine the impact and work on a range of improvements to further mitigate situations like this going forward.
This notice is part of our commitment to transparency. As a security vendor, we take issues like this seriously. If you have any questions or concerns about this incident, the security of your user data or your account, please contact us at [email protected] or open a support ticket.