Skip to content
Naked Security Naked Security

Google recalls Titan Bluetooth keys after finding security flaw

Google had egg on its face this week after it had to recall some of its Titan hardware security keys for being insecure.

Google had egg on its face this week after it had to recall some of its Titan hardware security keys for being insecure.

Titan is Google’s name for its family of hardware security keys that provide two-factor authentication (2FA) for web users.

Launched in July 2018, they offer a level of physical authentication to complement website passwords. Google provides the Titan key for accessing your Google accounts, but you can also use it with other accounts that support the FIDO U2F standard for hardware keys.

When you switch on hardware key support in a website, it asks you to present your Titan key along with your password before it will let you in. This stops thieves who steal your password from accessing your web account.

How do you present your Titan key? It comes in two flavours: a USB key that you plug into your computer, and a Bluetooth-based key that connects wirelessly to your device. This works with computers and with your smartphone, giving mobile users extra protection for their web accounts.

The problem lies with the Bluetooth key, and in particular with its implementation of Bluetooth Low Energy (BLE). This is the protocol it uses to communicate wirelessly with the device it’s authenticating to.

In normal operation, you’d first register your BLE-enabled Titan key with the web service you’re using, generating a secret that is stored on the key.

Whenever you want to access the web-based service, you enter your username and password as you would normally, but the site also asks you to use your hardware key. You press a button on your Titan key. The key uses BLE to connect with your computer or mobile device and send it the secret. The browser on your device then sends the secret on to the web service, which verifies that you’re legit.

So far, so good.

The problem, however, is that Google misconfigured the BLE implementation, so it was insecure. It allows a so-called Man in The Middle (MiTM) attack, in which someone could get between your Titan key and the device it’s communicating with. That person could then intercept communications from the key and use them to sign in as you.

Fortunately, the attack can’t be pulled off from the other side of the world: an attacker has to to be within about 10 meters; has to launch their attack just as you press the button on your Titan key; and needs to know your username and password in advance.

But anyone else in the same coffee shop as you, for example, automatically satisfies the first two conditions, so this sort of attack is definitely possible.

The issue only affects the Bluetooth-enabled keys, not those that you plug into a USB port. To solve it, Google has recalled affected keys and offered a free replacement.

The company also argued that the security flaw still renders the Titan keys more secure than relying just on your password for access:

It is still safer to use a key that has this issue, rather than turning off security key-based two-step verification (2SV) on your Google Account or downgrading to less phishing-resistant methods (e.g. SMS codes or prompts sent to your device).

Google made its own Titan key rather than partner with key manufacturer Yubico, which created the U2F standard with Google in 2014. Yubico threw shade at Google’s Bluetooth choice last year arguing:

While Yubico previously initiated development of a BLE security key, and contributed to the BLE U2F standards work, we decided not to launch the product as it does not meet our standards for security, usability and durability. BLE does not provide the security assurance levels of NFC and USB, and requires batteries and pairing that offer a poor user experience.

Google’s Bluetooth misstep bolsters Yubico’s point. It also won’t do any favours for the concept of hardware keys overall.


Like (nearly?) all tech products, there will be back doors/exploits. I hope there aren’t intentional ones put into MFA devices. But, be it a factory worker, disgruntled or blackmailed programmer, or xxx government agency, there will be though, always is. Meh, keeps me employed.


Typo? “although this attack is tricky to pull off, it’s far from impossible.” perhaps you meant _not_ far from impossible.?


Reworded to make it clearer – it is indeed far from impossible, i.e. definitely possible, so I said it that way instead.

(To be clear: that particular clumsy sentence did not appear in Danny’s original text but was the outcome of my editing. So I am correcting myself, not the original author.)


The last sentence is the most prescient. Security Keys are a complex solution to deal with careless users. They contribute needlessly to more environmental pollution, because it’s yet another bit of plastic and circuitry to be mined and manufactured. And worst, they contribute to lazier passwords, because users figure the key will compensate for laziness; that’s fine until the key is stolen or misplaced.


2FA for me has to allied with other technologies – random password generators and managers. And of course one needs at least 1 backup somewhere in a safe. I have been using Yubikeys for ages.


There will always be a trade-off when making security selections, and I guess choosing the connecting method between USB and Bluetooth may be one of them, but in this case perhaps an early implementation of BLE was a bad choice.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!