Interesting news OP. Let me see if I can dissect it. First it will help to know how Google Authenticator works so we don't, you know, talk about a black box. The knowledge of the
protocol of Google Authenticator is publicly known as there used to open-source versions of it. It is now a proprietary app but obviously it must be backward compatible with its older versions because a website using this protocol will needs to accept users using both of these clients. The Google Play Store app is the proprietary version of Authenticator.
I use One Time Passwords (OTPs) generated by Authenticator, with a QR code, to log into university computers so I have at least some knowledge of how Authenticator works.
(Lots of the following content was sourced from
https://en.wikipedia.org/wiki/Google_Authenticator)
First of all, this is a vulnerability in
Authenticator so it doesn't matter whether you use username/password or QR code to login.
Second, the way Authenticator works is that it takes a 80-bit secret key that a service creates (as I will explain below this is a big security hole) in the form of a base32 (A-Z and 2-7 characters) string, possibly wrapped inside a QR code. If you don't know base32 then all you need to know about it is each character like A, 2, etc. can store 5 bits of entropy so the string ABCDE234 contains 40 bits of entropy. So, it doesn't matter how the secret is imported into Authenticator, it's ultimately the same secret string.
Third, the secret key is passed along with a periodically changing number (Google Authenticator uses TOTP variant of OTP), such as:
the number of 30-second periods since the Unix epoch
This is why OTPs are valid for only 30 seconds or so. Both of these are passed into a cryptographic algorithm (HMAC-SHA1 to be precise) that creates a hash out of them. Then it's modulus'ed by 1000000 (mod 1000000) to get a six-digit code. The hashing algorithm itself was
not broken.
Last, and most importantly,
wallets that don't use Authenticator are safe. Authenticator is a mobile app, there is also a browser extension available. So all desktop wallets that don't route you through the browser extension or mobile app to authenticate are not affected by this. I don't know how many bitcoin websites (could be web wallet, cloud mining, whatever) use Authenticator, I know Oxbtc makes you scan a QR code to withdraw but you'd have to be logged in with username and password anyway.
Here is the official Google Authenticator codebase (at least the open source part):
https://github.com/google/google-authenticator-android/This is the part of the code that handles secret entry. Notice how MIN_KEY_BYTES has a value of only 10 i.e. 80 bits:
https://github.com/google/google-authenticator-android/blob/efac95c88ef8d9f8be3c887fbcd2c2fdf4f45dbe/java/com/google/android/apps/authenticator/otp/EnterKeyActivity.java#L121-L126And this is the part of the code that hashes the secret into a 6-digit code:
https://github.com/google/google-authenticator-android/blob/efac95c88ef8d9f8be3c887fbcd2c2fdf4f45dbe/java/com/google/android/apps/authenticator/otp/PasscodeGenerator.java#L152-L163Clearly these code snippets indicate that while Google Authenticator supports more bits, it foolishly sets the minimum to 80 bits despite
strict requirements by RFC 4226 (yes OTP is an RFC standard) to use at least 128 bits and recommends 160 bits, double the amount that Authenticator-aware web services use. Remember that web services are the ones creating these very small keys, not Authenticator.
So while OTP authentication provides strong security if used properly, Authenticator tokens fall very short of the minimum security requirements, so they were never secure to use in the first place. Again though, Authenticator supports more than 80 bits, it's just the web services don't make more bits.
It's worth noting that other TOTP authentication software works with the same sites as Google Authenticator, but are only as secure as the length of the secret key that the web service gives it.
Now, about the vulnerability:
According to the security whitepaper buried in the article OP linked (
https://www.threatfabric.com/blogs/2020_year_of_the_rat.html), this is an
Android virus. It uses code specific to Android. This is
not an iOS virus. And apparently this virus existed since Mid-January this year.
The feature enabling theft of device’s screen lock credentials (PIN and lock pattern) is powered by a simple overlay that will require the victim to unlock the device. From the implementation of the RAT we can conclude that this screen-lock credential theft was built in order for the actors to be able to remotely unlock the device in order to perform fraud when the victim is not using the device.
Definitely sounds like mobile phone malware to me. Note that the use of the word "screen lock". This is only applicable to phones not browsers, as if this was e.g. a Chrome vulnerability it would've been mentioned in the paper. So, this doesn't work for web browser extensions of Authenticator.
What about desktops? Well those are only as safe as the web browser is, as Authenticator for desktops lives in the browser as an addon. No Windows or Linux, or even Chrome or Firefox, vulnerabilities were detailed here so those parts should be safe.
I wonder if the news about 2fa being compromised is true, haven't heard any reaction from Google about this rumor, if it is true then google would be fast enough to react on this and notifiy their users about the incident.
Please don't conflate different types of 2FA together, especially since there isn't really a technical protocol that all 2FA methods use and so you can't say
all of 2FA is compromised by a single vulnerability, like the one in the article. Again:
- Only Authenticator for Android is affected
- Other Authenticator platforms are safe from this (for now)
- Even though only Google Authenticator for Android is affected right now, other authentication apps might get targeted in the future. It's only been 6 months since the virus (called Cerberus) was updated with this.
- 2FAs that doesn't use OTP are safe from this
I wish the security company made available the part of the Cerberus code that intercepts the Authenticator 2FA tokens so we would have a clearer idea of what type of information is being stolen right now. Remember that viruses are slow to update they have to be patched at hacking forums for months.
That being said, there is a long list of flaws in SMS 2FAs and I would take OTP based 2FA over SMS 2FA any day. SMS 2FAs have no cryptographic strength over OTPs because the security of SMS 2FAs relies entirely on your carrier to not have telecom engineers who've been bribed by criminals to replace your phone number or intercept your SMS messages. Heck, famous people's accounts have been hacked by people who compromised SMS 2FA.
it is very easy to hijack a SIM. The most damning part about SMS authentication is that mobile carriers
don't do anything about this. (Think about it. It's their managers and employees, whose internal decisions can override a complaint you make about their services.
That's how much security there is in SMS 2FA.)
And then there are notices like this:
T-Mobile Is Sending a Mass Text Warning of ‘Industry-Wide’ Phone Hijacking Scam:
You know a security method is very, very insecure if the only counter-measure operators can take is warning people not to fall for it. This particular message reeks of generic lack-of-concern towards the users when there is a danger with catastrophic consequences going on. Reminds me of Facebook security notices sometimes.
Long story short, SIM 2FA is not secure, and the way OTPs are being used right now is not secure either (web services need to get their act together already). If you ask me I wouldn't use any 2FA until most web services make secret keys at least 128 bits long. I would use a BIP39 passphrase instead. I'm not a security researcher and don't claim to be one, I just thought I would clear up some of the misinformation in this thread.
P.S. link to the security whitepaper that's buried inside the article OP linked, in case you didn't see it above:
https://www.threatfabric.com/blogs/2020_year_of_the_rat.html