Hacker News new | past | comments | ask | show | jobs | submit login
Google's Abandoned Android Authenticator App (shkspr.mobi)
313 points by edent on Feb 28, 2020 | hide | past | favorite | 169 comments

This is a bad article. Let me summarize my thoughts:

- The "security bug" it references isn't one at all. Accessibility Services can draw over other apps and interact with them by design. They're designed as an alternative way of interactive with android for disabled people consequentially they can do anything a normal user can do. The security "researcher" found a non-bug then convinced an ignorant journalist at zdnet to publish an article about normal/correct Android functionality.

- If it were somehow a bug, it is still impossible for Google Authenticator to patch/mitigate it. Accessibility Services act as the user, therefore they can do anything a user can do. You cannot block them for good reason (breaks disable user's ability to use Android).

- The third party apps they reference don't block Accessibility Services either, making it hypocritical to criticize one while pointing to others with the same fictitious flaw.

- Switching to a random open source TOTP/HOTP 2F app might reduce your security, not increase it. You'll either compile it yourself requiring enabling "Allow installation from unknown sources" (bad) or you'll more commonly just grab it from the app store, in which case that random OSS developer's account can feed you evil-ware either intentionally or via compromise. As soon as it is from the app store the "open source" nature is completely irrelevant, it isn't a security guarantee.

- No unpatched security bugs have been found in Google Authentictor. Google Authenticator's lack of updates are annoying though (unfixed bugs, poor backup support, QoL features like secondary pin, etc). Just not the way the article frames it.

> compile it yourself requiring enabling "Allow installation from unknown sources"

This is one of my biggest pet peeves about Android. I wish i could add my own signing key for apps I compile myself, rather than just being given the choice of Google play or anything at all.

In a round about way you sort of can now. The “allow installation from unknown sources” is per app-source now. You need to enable it for Google Chrome if you downloaded the package from Chrome, or for F-Droid if you downloaded it from F-Droid. So, the solution you’re looking for could be just a small shim app to download from your own repository of sorts. Janky .. but it’s a bit more possible than before I guess. As an added bonus you could do some signature validations too!

If you use F-Droid, you could also just set up your own local repository for your custom apps.

Yup! I was just running under the assumption the parent comment wanted no other apps period, with a smaller surface to attack.

I'm an iOS user, but I suspect I'll end up switching back to Android for my next phone in 4/5 years.

Is there a way around this where you can say "no, just let me install from anywhere" or is it forced unless you root the device?

The reality is it only takes 2-3 seconds to allow it, it’s a direct link to the relevant setting. Once you allow it for that app (say, Chrome or Google Drive) you don’t have to do it again unless, of course, you disable it.

Yeah Android 8 introduced it. It's a good change IMO.

There's nothing bad about "allowing installation from unknown sources" if you know your sources. It's just a scare tactic Google uses to quash competition.

An app you compile yourself (assuming you at least tried to read the source code, the open source Google Auth is pretty brief/readable, I've reviewed it before) is vastly more secure than installing whatever the Play Store serves you.

This is frankly a ridiculous statement. If you are an experienced software developer, and correctly apply supply chain security policies, you can likely build and install an apk correctly.

Literally billions of regular users cannot do that, and regularly install malware laden apks.

Consider that if I know how to get to my bank's website, and it gives me an APK to install, I know it came from my bank, unless my bank's server is compromised in some way.

I have no way to easily determine that an app on the Play Store actually came from my bank. At best, I can look at the install count, hope the app store does a half way decent job looking for fraud, and hope for the best. Maybe if I'm lucky they have some sort of verification program?

The idea we actually trust app stores from Google or Apple over a direct install from the institutions we want to interact with is hilarious, especially considering all of the rampant malware and fraud issues on the Play Store.

You go to the bank's website and it has a link to the app on the store?

If they dist an apk, how is the bank to provide updates for their app? Build their own updater architecture? If there was a mitmed update from a store they could cancel it centrally.

Telling people to prefer apks is setting them up to be hacked.

The hybrid approach gives you both benefits. Go to the website of the known institution, and follow their links directly to the downloads in the app store.

You are given a similar choice though. Write an app which can do whatever verification you want, gpg or anything, and only give that app permission to install from unknown sources.

What's going on here?

The article doesn't call this issue a "security bug" anywhere in the article. This and ZDNet's article don't claim this is a vulnerability or bug, but are reporting on the relative novelty of malware targeting 2FA apps.

The article doesn't even claim Google Authenticator or third party apps should mitigate it, or that third party apps are any better at it. The first three paragraphs and the last one of this comment are just railing against some strawman. There are 0 claims about vulnerabilities or security weaknesses in this article.

Finally, I frankly find your claim about open source apps being bad ridiculous. What's the alternative, never trust indie developers, only trust the big corporations? Also: the blanket "Allow unknown sources" has not been a thing since Android 8.0 - you have to select individual trusted sources (e.g. F-Droid, which actually has a superficial volunteer review process). You can't buy a new Android device which forces you to use blanket unknown sources anymore unless you really try.

I like contrarian arguments on HN as much as the next guy, but I only like those that actually respond to what the article says. At worst, the article's use of the ZDNet is too opportunistic to drive its other valid points.

> This and ZDNet's article don't claim this is a vulnerability or bug

> The article doesn't even claim Google Authenticator or third party apps should mitigate it

Second sentence of the article is "I doubt Google will ever release a fix for this issue". We could argue about the semantics of "issue" vs "bug" (though I'd rather not), but it seems pretty obvious the author thinks of this as a fixable "issue", when the parent comment's point is that it absolutely isn't.

> Finally, I frankly find your claim about open source apps being bad ridiculous.

Nobody called Open Source bad. What got posted was:

> As soon as it is from the app store the "open source" nature is completely irrelevant, it isn't a security guarantee.

Unclear how you got from "no security guarantee [with compiled open source in the app store]" to "open source is bad." Those two things aren't even similar.

The biggest problem with Open Source in the app store is actually automatic updates. It is conceivable to build the app locally and compare the resulting APK to the app store version. But it isn't very realistic to do that every update (or even just follow the repo changes long term).

Most of the time these types of issues aren't important because apps are well sandbox on Android. But in the case of password and two factor managers special consideration has to be taken because the data within the app's sandbox is highly valued, and extrication is trivial with all apps having the default android.permission.INTERNET privilege.

Is railing against uncharitable interpretations of other people your thing today? I'm sorry for summarizing that paragraph so shortly, I don't actually think you think open source is bad.

> poor backup support

None at all. Or did I miss something?

Wait. The vulnerability report says, "Abusing the Accessibility privileges, ..." the trojan can steal your OTPs. If you give a program accessibility privileges, it can read the screen. Is that all we're talking about here? What is the proposed mitigation that Google should implement on the app? You can't block accessibility on the OTP app because then blind people will not be able to use it.

There is a huge amount of push in media to cripple our devices because some users don't want to reason and use them responsibly. Because Apple limits something, the assumption is that every other platform now must be limited in the same way and prevent their users from running more powerful software themselves. Because some of them might cut themselves approving too many things.

I don't like that viewpoint.

It's not necessarily a good thing, but it is a lesson the software industry is going to have to learn.

For example, take the story from a little while back about how Gmail add-ons could access your messages. Any programmer looks at that situation, and they think, "Duh... OF COURSE an add-on could access your data, because how else on earth could it possibly work?"

But a non-programmer doesn't think this way. They think, "Gmail is a platform and a service that I use, which is run by somebody that I'm supposed to be able to trust to handle all that stuff for me. They ought to reason through all these things before they offer it to me." They very well may not have a good enough understanding about how software works to reason through the implications like we can. It isn't self-evident to them where your data goes and what will happen to it if you do this or that. moreover, Gmail (and tech generally) isn't the center of their universe, and they may not realize these add-ons come from a third party or may assume a certain level of vetting would be done if they do.

Whether this expectation is right is one question. In theory people ought to take responsibility for their own choices.

But putting that question aside for the moment, when designing a product, we ought to never forget that many users lack either the knowledge or the inclination to think through all this. You're building a product that you're going to hand over to users, and a lot of users, maybe even the majority of them, are going to approach it this way. I don't have a great solution to offer, but blindly assuming that all users are knowledgeable certainly isn't the right path.

It is indeed a difficult problem. It's not just that users cannot be expected to be knowledgable. They cannot know who to trust either. If you show them a warning that says "do not install this add-on unless you trust its publisher", what is a user supposed to do? There are thousands of add-on/app publishers with names that no one has ever heard of.

So I do understand Apple's approach. Unfortunately, Apple muddies the waters by mixing up security protections with their own business interests and the interests of authoritarian regimes. To a degree I fear this is unavoidable.

I think the best solution is to have that very restrictive app store that you can trust to vet things for you, but in addition to that they should permit side-loading for apps and content that you have to vet yourself or rely on a third party vetting system.

I recently had a discussion with someone who complained about the Gmail permission dialogue when adding his Gmail account to the Windows 10 mail program. He was absolutely convinced that he will not agree to giving Windows permission to view and send emails for him and instead requested that Google and Windows enter a contract that only allows him to do that.

It was completely impossible to explain to him the technical background (e.g. that him sending an email through the program and the program sending an email by itself is technically the same thing for Gmail) and he wouldn't accept that Google is quite rightly informing him about the implications (Google should change the text to say it only allows him to send emails).

As you said he expected Google to give him technically impossible guarantees and handle that the third party software can't do anything without him confirming it.

> some users

While that's technically the truth, it doesn't represent the actual state of events. 99%, and probably 99,9% don't use their devices responsibly. And then companies that bare no responsibility for the actual hack still suffer PR damage, because journalists don't report responsibly too.

It's like quarantine. You might think you're smart enough to wear the right gear and behave the right way to keep others safe, but because some people are irresponsible or don't know how to behave, we enforce the rule on everyone, to keep everyone safe.

When we realize that many exploits can mean that devices get co-opted by bad actors to serve some rather nefarious purposes, we have to do more than "trust that the user will be smart" in order to suppress dangerous or economically destructive criminal uses of these devices

More and more I realize that it's not our strategies that I dislike, it's how incompetent and error-prone users actually are. If we were perfect users, none of this would be required.

With quarantine you're preventing the spread of disease which is a general harm to others, with this you're preventing the spread of... your own 2FA codes, which only hurts yourself, if that. Sorry, but I don't think this analogy works. I should have every right to harm myself in any way I see fit. My hardware, my accounts, my control. Preventing accessibility "abuse" does nothing to stop malicious apps from attacking other devices but does a lot to harm accessibility and advanced user features.

Quarantine is actually an apt metaphore here. Apple wants you to stay in the quarantine for the rest of your life because when outside you might ignore the red light and get killed on the road crossing. Or die from other millions of dangerous sources.

But staying in a single apartment for the whole life is not healthy for most people or society. Modern computing grew because people were able to build and experiment on things way beyond what the original manufacturers of hardware envisioned. Even if that gave some people Windows viruses.

I understand the "old days" idealism of hacking things in the 80s, but there weren't million computer botnets conducting massive criminal attacks on banks and governments in the 80s. It's a different era.

It's like saying "quarantine is pointless in my rural village of 29 people, so therefore it's also pointless in my city of nine million"

Another app that stores credentials mitigates this by putting up a 30-second delay; the text goes a bit like this:

"It seems that you are using a screen reader or something else that uses the Accessibility services. If you have no idea what this is, do not continue past this screen. The below buttons will be enabled in 30 seconds [I know what is happening] [This doesn't sound familiar, exit]"

(Of course it only appears when you actually have something subscribed into the accessibility services, which is how I found out) Yes, it's inconvenient, but forces you to actually read the message instead of blindly barging through Accept Accept Accept.

That places the burden on people required to use such assistive technology. I’m sure life as a blind person is already full of obstacles, so we should maybe think twice before actively seeking to build new barriers.

And how does this actually prevent abuse? Wouldn’t malware happily wait 30 seconds and click “yes”? And if the dialog isn’t accessible to the screen reader, doesn’t it then exclude some users entirely?

I would think that the expected behavior is "if you don't know what this is, close the app manually." But yeah, it's only a mitigation.

Does it do that every time, or just the first time? If it just happens once I guess that might be a tolerable tradeoff. Still doesn't seem like it's worth classifying Google's app as abandoned just because they declined to implement this particular feature.

Each time. Annoying, but bearable for something I use once a day...

So after you posted to it I finally found the report[1] (three levels deep from this post :)

So actually that's not how it works. If it was just reading the screen it would only get a single OTP password which is only valid for up to 60 seconds.

The trojan is actually tricking user to enable accessibility privileges. Those privileges give the trojan ability to control the phone. With this privileges it actually can navigate settings and grant itself other permissions.

I suspect that with authenticator it can navigate and extract a private key somehow. I don't know how it's doing, because I don't see an option in the UI to obtain such key. So perhaps it is still somehow exposed to accessibility application but not the user. Or the report makes it look worse than it is and only talks about the one time code (it is not clear).

Anyway the real issue though is that accessibility is giving app full access to the phone. Restricting that though would affect accessibility, I believe Android though should make such accessibility request more scary.

I think the fatal flaw there is maybe allowing an app to prompt the user to enable accessibility settings. Although it is still not as terrible, an app can only send the user to the right setting page, but it can write whatever it wants in the description of the app (typically they say why they need the setting). The only warning from android is when you're about to enable the setting, but that warning is very dry, it lists the permissions, and some description for them. It doesn't seem to distinguish more scary ones from less scary ones. It also conflates them.

For example I have app called "back button" which basically emulates a back button (actually also other buttons), quite useful when it is broken. Though the only permission the app is requesting is "observe your actions (receive notifications when you're interacting with an app)" it doesn't say anywhere that it is more than that, the app actually can emulate pressing various buttons and nothing like that is even mentioned.

[1] https://www.threatfabric.com/blogs/cerberus-a-new-banking-tr...

AFAIU it's the trojan app that uses the accessibility privileges? Which are probably only activated when the user activates them in the OS settings.

Not sure if possible, but perhaps the authenticator app could detect that accessibility mode is on, and refuse to show the codes? (or at least do it behind a warning?)

Also, I think the trojan app would need to ask for accessibility permission from the user to be able to read other apps' text?

So you would prevent blind people from using 2FA because someone else installed a tool that also reads screen? Please no.

You build speaking the OTP code into the authenticator app itself, controlled by a setting in the app itself rather than the system wide accessibility settings, and possibly using its own text to speech library instead of the system wide text to speech facilities.

Whether or not it should use its own text to speech depends on whether or not you need to worry about malware subverting the system wide text to speech system.

If it does use its own text to speech, it might be possible for it to just use the system text to speech system on install to do generate speech for the 10 digits and save that, and use those recordings for speaking codes.

That avoids having to worry about system text to speech compromises except during authenticator app installation so is probably almost as safe is including a dedicated text to speech system, an ensures that they can handle all languages that the system text to speech can handle.

What about users that are deafblind and use external braille devices? Are you going to build support in for those too? Is the maker of every other security relevant app also going to?

But there's a lot more that goes into accessibility services.

Redirecting all output to a single mono headphone is really important, and most users who use talkback adjust the speed and how things are spoken to better suit them.

And it still doesn't solve the problem, as accessibility services can still tap into the audio output and run speech-to-text to get the codes back still accomplishing the same exact thing.

OK, so the idea of having the authenticator app entirely handle its own accessibility might not solve the problem in the case of users that are actually using accessibility features. Or at least it would require some serious system level support [1].

But how about the first part of my suggestion, which was to have whether or not accessibility features are used in the authenticator app controlled by a setting in the app separate from the system wide settings?

For people not needing accessibility, at least, and so have it off both system wide and in the authenticator app they would be protected. A rogue app getting system wide accessibility access would still not get access to the authenticator.

[1] The system might have to support two independent sets of accessibility privileges and settings, one for most apps and one for security apps, with severe restrictions on what regular apps can do when a security app is running.

> (or at least do it behind a warning?)

Couldn't the accessibility app just approve the warning? Otherwise how would blind users do it?

> What is the proposed mitigation that Google should implement on the app?

Why are 3rd party apps needed for accessibility ? How about Google take accessibility serious and make the OS accessible without expecting others to pick up the slack ? An API with this kind of far reaching access shouldn't even need to exist.

Accessibility is one of those long tail things, which is why the laws about it are written in relatively vague terms. If you need a wheelchair requiring everything be made suitable for the blind doesn't help you at all but a wheelchair ramp makes a big difference. If you're utterly deaf the wheelchair ramp is not helping.

Google undoubtedly has the resources to build say, Android for Blind People. But it's not realistic to expect Android for this one guy who can twitch his nose, but is otherwise paralysed; or Android for the woman whose brain can't process shapes properly.

By enabling a generic Accessibility feature it doesn't close the door to anybody. If you can adapt it, or get anybody else to adapt it, to be accessible to you then this feature will help you get that done. To do that it's enormously powerful, which means bad guys with this permission can take over your phone.

iOS supports password managers natively. When you focus a password input, the keyboard prompts you to open the password manager. For me it opens BitWarden directly from the keyboard.

Android doesn't support this, so a workaround is to use the accessibility service. The trade-off is having to grant all those permissions. You can also open the app directly and copy-paste, but that's a lot more extra steps. The killer features for password managers are that they're both more secure AND quick/convenient.

> You can't block accessibility on the OTP app because then blind people will not be able to use it.

You can block accessibility from the specific field of the OTP app, if you also have a system framework that retrieves exactly the contents of that field into your paste buffer when you interact with a privileged UI element (i.e. the keyboard-UI “autofill 2FA” accelerator.)

That won't work if someone it trying to use the code on their desktop. The screen reader won't be able to read the code to them, so they won't be able to log in.

You can autofill the field into a text editor, and read it from there. The security comes from the fact that you had to interact with a privileged UI element to do so, which an accessibility assistant cannot trigger; you need to use the system accessibility features (e.g. the voice assistant) to trigger privileged UI elements.

(See also: accessibility of elevation prompts in Windows.)

Thee is no reason not to have a special privilege level for screen readers.

There is a special privilege level for screen readers. The issue is that the hypothetical malicious app pretends to be a screen reader.

Do you mean it hypothetically actually functions as a screen reader but also steals data, or something that just requests the privilege while being something completely different?

Either one, but realistically the latter.

In the former case, you just call your app SuperLegitScreenReader, prompt the user to grant accessibility access, and then snarf up data. Bonus points if you bundle in some open source or pirated screen reader code so your app can act the part, but you could probably just say “fetching reader data, screen reading will be functional in ~60 minutes” and count on most users to not bother uninstalling the app or revoking permissions.

In the latter case, you call your app “CandyNinjaBirds”, and have it pop up and say “to let you share cute stickers to your friends, you need to enable accessibility access” and count on the vast majority of people to click “allow”.

The latter case is way more common because the former case limits your target audience to people who actually want a screen reader.

Ok - but given the small number of actual screen readers it would be easy for a store to have extra policing for this privilege.

The copy/paste buffer is also accessible via accessibility features. This isn't a fix for the "problem" presented by the article. (personally I think it is hardly an issue)

What about people who want to type the code into a different device?

But then how would disabled people access their 2fa codes?

Maybe the app should just read the code out to the user, provided said user has a headset on.

accessibility services can also tap into the audio output of the device.

> You can't block accessibility on the OTP app because then blind people will not be able to use it.

True - but you can make accessibility access an opt-in feature. I hate phrasing it like that. But a piece of security software should allow people to disable accessibility features when they aren't needed.

Accessibility services are disabled by default and need to be explicitly enabled by the user. At that time the user is clearly warned that the enabled service (by name) will be able to read the screen.

> you can make accessibility access an opt-in feature

It already is. You have to explicitly go and enable it per requesting program in the system settings.

Should opting in not be accessible by assistive tech as well, then? People requiring this technology obviously need a way to turn it on. Requiring them to have assistance to initially set it up would seem terribly insulting, regardless of how little trouble it might practically be for most people.

I switched to Authy some years ago. It took Google forever to add the ability to Authenticator to let you migrate 2FA codes to new devices, and even then, it was only Google codes. I got tired of having to deactivate 2FA on my 20 or so accounts, switch to my new Android device, reactivate 2FA, and then scan the QR codes on the new device. Authy made it a painless experience, particularly since I could verify codes were working on the new device before factory resetting the old one.

IIUC the Authy "feature" where it allows you to transfer 2FA codes to a new device defeats the purpose of 2FA. That is, if someone gets access to your Authy account they'll get access to your 2FA codes. This has been used to steal cryptocurrencies from users in the past:


True, but you can enable/disable the multi-device feature at any time. So you can theoretically just turn it long enough to port your codes over to the new device, confirm that they work, and then de-authorize the old advice from the account and turn the feature off.

I ended up doing as much when I lost my Android tablet at a bookstore on which I had Authy installed. It gave me a mild panic attack at the time, but, a year later and none of my accounts have been hacked yet, so, I have to hope that the other security measures on the device were enough to thwart the potential thief/adversary.

I use Authy, but God, I hate their UI and UX. Finding the accounts there is a pain in the ass, and for some reason, I always end up with duplicated accounts (when I just added them once). Also, it has been two months since their last iOS update, so it's not like Twilio is taking care of it either.

Give andOTP a try[0]

[0]: https://github.com/andOTP/andOTP

I love andOTP, it does one job and gives me (not my phone's firmware) control over the secret storage.

Agreed. My biggest complain is the sorting of the list, a very simple thing to fix. I mean, how come I can't change the order of some accounts on some platforms? I only login to my tax account once a year, but on the desktop app it is first alphabetically so it's always at the top. Meanwhile, I login to my vpn multiple times a day and it is alphabetically at the bottom. So, I've had to start prefixing names with bullshit just to get them in a convenient order. It's like they don't use their own product or they'd notice this flaw very quickly.


You've posted the same comment several times throughout this thread and in the past you've also, shall we say, name dropped saaspass repeatedly. While also ignoring questions about your affiliation with the company. Mind explaining why you bring them up so often?

Adding a disclaimer but continuously peppering the entire thread with your C/P seems beyond disingenuous.

I went to Authy and then to Yubikey. I can get to my OTP from just about any smart phone now or even my desktop.

Do Yubikeys have a shelf life? Something akin to a usb flash drive?

I'm guessing that the lifespan is longer than the security of the algorithms it uses.

What do you do in the event you lose your Yubikey?

Can't speak to the OP but I have multiple yubikeys. One I carry with me all the time, and at least one backup, which I keep somewhere safe. Most sites allow you to register multiple keys.

Another approach is to have your phone as the daily 2FA device and the yubikey is the backup.

You hope that you have printed backup codes for whichever services provide it, or alternative auth, or you go through ID verification to regain access.

Not much else you can do, the point of 2FA is that you can't get in without it.

Some services let you store multiple keys. So you can own a separate yubikey that you keep in a trusted place eg deposit box.

Yubikey recommends "having a backup device and registering both with your accounts". I vaguely remember some people saying that they have a backup Yubikey that they keep in their safe deposit box, so that it's as safe as possible.

Does anybody do this? I've read that as well but it doesn't make sense to me. How do I add my backup device if it is in a vault somewhere? For that to be useful I would have to have my backup device on me so I can add new accounts, but then that defeats the purpose.

I could see this working for a few very secure logins, but if the idea is to two factor everything it doesn't seem tenable.

No, your backup device need to be stored until you need it, not with you all times.

you add your main device and your backup device.

than you store the backyup device, after having it configured on your accounts, in the safe and use the main device to authenticate on a daily basis.

when you create a new account you add your main device and than when possible retrieve the backup device from storage and add the new account to it and store it back again.

on the event of you loosing your main device you retrieve the backup device from storage, use it to authenticate and remove your lost device from your accounts.

You can then acquire a new one key, add to all your accounts and store the backup in a safe again until needed.

Safe deposit boxes aren't that safe.

I save each OTP config on three separate Yubikeys using Yubico Authenticator. I also screen-shot the QR code and save that and any recovery codes to a veracrypt volume.

If the site allows for UTF I register each key for that too, but only if I can also use OTP since I can't yet use UTF with my android phone.

Multiple YubiKeys/FIDO authenticators. Registering them can be an issue. I haven't checked since last year, but the only website supporting them that allowed me to associate more than 1 to an account was Google.

You know you can have OTP on YubiKey and app on authenticator app on phone or laptop. Then you just connect your key to device and you are independent from a device.

I have two of them. In the event that both are lost, I still have my recovery codes in a safe.

Have more than one yubikey (I have one for home, one for work, and one in a safe deposit box)

I actually associated a Yubikey to my account because I was so annoyed at this problem. I wanted a better backup plan than the physical printed codes idea. I didn't realize that a better 2FA app would have solved this :P

Not everything supports Yubikey/FIDO U2F at this point, so that wouldn't work for everything, although I do have one. My Gmail account itself is behind a Yubikey (and a a backup Yubikey), not a 2FA app, because I'm trying to avoid a Game Over scenario. The Gmail address is the recovery address for my password manager account, so getting that pwned is basically the keys to the kingdom for every other account.

I realize not everyone wants to leave Gmail, but another reason I'm thinking of using tutanota aside from e2e encryption is you can create a second user that's tied to your master account. You can reset the passwords of your sub accounts from the main accout if they are compromised.. of course you have to pay for multiple accounts though.

The weird thing is: Yubikey was the only option for me in Gmail. Only after I associated a Yubikey with it, was I able to also use an authenticator app.

Does anyone know if this is normal behaviour, and if so, what the reasoning behind it is?

That's weird, probably a glitch. TOTP is the basic option.

Having printed access codes in your safe doesn't seem worse than a backup Yubikey in your safe? Maybe better, since electronic devices can break.

Either way, put it in a tamper evident envelope in the safe.

The QR code you scan is stored in app's db, you can use generic scanner to get the code and save it on paper or another encrypted DB or extract them from the Google Auth app SQL DB - if you have root access.

Good luck getting root access on a US Snapdragon Samsung phone. IIRC, they physically damage themselves in some way if they detect that they've been rooted, which then caps the battery from ever going beyond 70 or 80%.

I'm interested to read more about this, do you have a source for it?

That seems like it would be just asking for a world of warranty returns and support nightmares for whatever company built it into their phones.

Here's the only quick source I could find about the battery being capped while rooted: https://www.xda-developers.com/sampwnd-root-galaxy-s8-snapdr...

I'm pretty sure this was implemented across their phones after the Galaxy Note 7 debacle. I think the idea was that anyone who tried to root their devices and avoid Samsung remotely deactivating them would at least be prevented from charging the battery to full, which could cause the battery swelling/overheating/fire-catching problem.

I'll have to do more digging on the quote I remember about Samsung phones physically blowing a circuit somewhere if they detect they've been rooted.

To follow up on this (in case you see ever see this comment) - I don't think that the linked article suggests that rooting the phone -permanently- damages anything. To me, that reads more like "the phone's bootloader checks to see whether it's booting a signed kernel. If not, it tells the battery controller to limit charging capacity until the next boot."

In this particular case, it was probably a safety thing on that particular phone. I bet that Samsung pushed it in a firmware update because of their "batteries catch fire" issue, which was fixed with some patches to the kernel driver. Chances are this was intended to make sure that somebody running an unsigned/homebrew kernel (which might or might not have the patched charge-controller drivers) wouldn't be able to make their battery catch fire.

> I'll have to do more digging on the quote I remember about Samsung phones physically blowing a circuit somewhere if they detect they've been rooted.

This sounds like the ODIN QFuse.

These aren't really particularly dramatic- they're tiny, microscopic "fuses", designed to blow cleanly and easily. Most devices have plenty of them- used to lock the devices down after manufacturing.

Blowing one of those fuses because a device thinks it has been rooted is pretty extreme though, no? (If this is in fact happening.)


TitaniumBackup does the job quite nicely if you're rooted, transferred codes through 4+ phones so far.

I recommend to use anything but Google Authenticator. andOTP is my preferred considering you can make non-encrypted and encrypted backups of all entries.

I lost my phone once and was primarily using Google Authenticator at the time. Because I didn't backup the seeds when registering entries to Google Auth, I had to go through some recovery processes on many of my accounts which where time consuming, nerve wrecking, and annoying. This was at the height of crypto craze so one account was Coinbase in which I had to go through some in depth recovery process (with an ID an all, which ended up crossing some legal lines in my state).

Do yourself a favor and either use a service with a supported and up to date app or take control with an app like andOTP and take backups yourself.

I got rid of Google Authenticator in 2018 preferring Microsoft Authenticator after feeling weary about having to setup 2FA on a new phone and subsequently reading posts like https://smartphones.gadgethacks.com/news/google-authenticato... which made me aware that I didn't have to go through that pain anymore if I dumped Google Authenticator.

If you do not mind your phone contacts are shared with the app [1], Microsoft Authenticator is fine.

[1] https://docs.microsoft.com/en-us/azure/active-directory/user...

That would be valid concern if you could not deny the permissions meaning this doc is out of date. I have both iOS and Android and have the permissions set to deny as they are not essential to the operation of the application.

Also, these concerns would pop up in the reviews if you could not deny the permission if it asked for it. One of the reasons I looked at MS Authenticator because it is one of the highest scoring and reviewed authenticator apps, so it would have taken a hit on the score if this was not possible.

"Contacts and phone: The app requires this permission so it can search for existing work or school Microsoft accounts on your phone and add them to the app, helping to ensure your account works properly. This permission also helps save you time while adding your personal Microsoft accounts, by automatically filling in some of the info for you, like your first and last name."

Wow, they really did their best to find a sliver of justification for that permission. I don't need an OTP app to autofill my first and last name.

And to those arguing about their opt-out for this permission, ask what unnecessary permissions your coworkers/family/friends have denied on the last few apps they installed.

Recommend that you install the application first and check what it asks for before coming to a conclusion based on this doc. The score would have taken a hit based on what you are saying. Furthermore there is no argument here just facts based on user experience.

> Contacts and phone. The app requires this permission so it can search for existing work or school Microsoft accounts on your phone and add them to the app,

Keyword here is requires. This doc is out of sync with the application, unsurprisingly.

Honestly, I wouldn't willingly install anything by Microsoft. Everything is overloaded with unnecessary telemetry.

On that note, for anyone using Microsoft's VS Code, I recommend https://vscodium.com/

Why would you need to give it contacts permissions? Just deny it.

This looks like the same pattern observed with the iOS Google Authenticator app. That one was neglected for multiple years as well, up to the point at which it looked ridiculously out of place on newer devices because it was running in some compatibility mode for old screen sizes and screen resolutions. After multiple years of no support whatsoever, they finally updated it. But apparently that was just random luck - the current version is over a year old already as well, with the update news saying "Added support for iPhone X".

I don't get it why Google apparently does not get the notion that they basically "own" the brand identity of what we technically-minded people know as the TOTP 2FA scheme - and they own it because of the Google Authenticator app. Thousands of websites ask their users to install "the Google Authenticator app" if the user wants to enable 2FA - they don't tell them to install "an OTP app" or something like that, no, practically everyone refers to this scheme and the associated apps as "Google Authenticator".

And it can't be too hard for a company able to fund and drive the development of a leading web browser engine to keep a simple TOTP app up to date and well-supported in the two major smartphone ecosystems. Heck, a single full-time developer should be more than enough manpower to do that! And Google has like, what, 100.000 of them?

Instead, Google lets other companies slowly chip away at their mindshare in the 2FA market - during the years of Google's inactivity, lots of alternative applications sprung up, and many password safe apps added TOTP support to their feature catalogs. We're at a point at which most technically savvy people advise other people to use ANY of those apps, but NOT Google Authenticator, even if the website tells them so. It's just a matter of time until the sites catch up and quit suggesting Google Authenticator (after all, the shortcomings of Google's application, like inability to backup seeds, probably cause additional burden on support channels for sites explicitly mentioning Google Authenticator, and if there are other apps that cause less problems, suggesting to use those at some point in time will be more beneficial than the brand name recognition bonus provided by suggesting an app by Google).

I'm ok with Google truly owning something. And I'm ok with them not doing something at all. But i want them to stop jumping in, bigfooting a space, and then losing interest. I know they've given up on "don't be evil", but maybe they can at least adopt, "With great power comes great responsibility."

"2FA market". Wait now 2FA apps constitute a market? The whole article is inaccurate and tries to jump on the stereotypes we see in the news about Google to capture clicks.

Authenticator is still a secure 2FA app (unlike Authy) and the fact that the devs did not ship a new build or updated the UI recently might not be great but the app does its job.

If "awk" does not ship a new build in a few years would it be considered abandonware?

Command-line applications for consoles are not exactly comparable to smartphone apps in that regard, because their natural habitat changes only at a glacial pace nowadays, while the habitat of smartphone apps - the smartphone OSes - evolved at ridiculous speed during the last decade.

Even Unix utilities are not immune to this. Look at Linux net-tools (which provides ifconfig for Linux) for an example of one that became abandoned, and consequently dropped.

Screen also nearly suffered this, though my understanding is development has resumed since.

Regarding your point about mind share: It's been a long time since I've called that method of MFA "Google Authenticator" because of exactly that reason. But you're absolutely right that a few years ago that was exactly what I told people to install and what I crudely called TOTP 2FA.

I'm actually a bit surprised that Apple hasn't made their own OTP app for the iPhone yet.

The author doesn't explain why this is a google problem other than their code is "old".

The way the source article reads, it seems like the vulnerability would affect any OTP app.

The latest version of [andOTP](https://github.com/andOTP/andOTP/releases) indicates that it protects some of the fields from accessibility hijack. I suspect other apps will find a way to prevent this attack.

The problem I, the author, have is that it seems unlikely that Google can fix this. What are the risks associated with suddenly changing a codebase which is 2.5 years old? Is there anyone there who works on it day-to-day, understands how it works, and can release a verifiably fixed patch?

Security products need constant maintainance.

No user should trust the security of an app that was abandoned 2.5 years ago. It's irresponsible (and typical) of Google to keep the app available and unmaintained.

Even if the code were bug-free at the time, dependencies, APIs, and attacks change.

Good thing TOTP is an open standard, so there are some alternative apps available.

I guess they consider TOTP as legacy and are focusing on U2F, I think in their products you can’t even sign up for TOTP based 2FA anymore.

I amassed quite a collection of U2F Titan security keys that Google gave away for free at conferences, some of them have become obsolete already though and some had serious security issues (the Bluetooth one). I prefer using the Yubikey for that reason, though I find them quite a bit overpriced.

You can still sign up, but it's a bit of a pain.

When you initially enable 2FA, you won't be given the option. But you can register with SMS/U2F/etc. Once you've enabled the first authentication method, you can go into your 2FA settings and add a virtual 2FA device. Once that's done, you can go back and delete whatever you added initially to be left with only a virtual 2FA device.

And the usual Google neglect of its products continues. It's a vicious circle, they keep neglecting apps, people start using them less and less and as they notice people using them less they neglect them more and the cycle continues until they kill it.

This is one of the main reasons I stopped using any of their new projects.

I recently switched to Aegis, it's so much better, and open source[0]. Crucially it has biometric encryption, and import/export so switching to a new device isn't a horrific ordeal. It also has some great QoL features like custom icons, highlighting, and reordering. To anybody looking to move away from Google Authenticator, I highly recommend it.

0: https://github.com/beemdevelopment/Aegis

This looks good but I can't find any information about who is behind it and why I should trust them. I wish they were collaborating with a well known project like andOTP instead.

Potential vulnerability aside, I think the article leaves you with wrong impression about stat of Google Authenticator app. In my understanding Google Authenticator app you install from App Store is not the same as github app authors talking about. As it clearly says in README "While this fork is open source, the official version of the app still remains proprietary. There is no guarantee that the open source repository will receive any changes made upstream (or vice versa)."

If you visit the Authenticator app on https://play.google.com/store/apps/details?id=com.google.and... - you'll see at the bottom that it was last updated on September 27, 2017 As in, that's the last time an updated was published on the Play store.

I'm sorry I didn't make that clearer.

I don't think it actually needs an update. Supporting new features would be nice, but it's not a requirement.

Hmm. I see a lot of people here responding that disabling this would break the Accessibility Services, and I completely agree.

However, it does seem to me like there is a genuine problem here. Perhaps the solution is to have a two-layer accessibility permission system? One permission for reading the screen of non-inherently-sensitive applications, like web browsers and email clients, and another permission for reading high-sensitivity applications like Google Authenticator. Enabling the second permission would come with very strong warnings about security, and the admonition that you should really really trust this application provider a lot more than your average screen reader app.

I recently switched to Aegis Authenticator: https://getaegis.app/ It seems to be as well-maintained as andOTP, and I like that it is licensed GPLv3 rather than MIT.

The most frustrating thing about this app.... is that it ignores other algorithms such as sha-256 or 512.

But get this!

On iOS it correctly shows the right OTP code for these algorithms.

On android it acts like it’s a sha-1 and has the wrong code....

I'm a big fan of using the Yubico Authenticator instead of Google's apps:


In addition to being supported, it avoids the possibility of a future mistake leaking TOTP seeds since they're stored on the key rather than the phone.

FWIW, the iOS version was last updated on Sept. 12, 2018, a minor update for iPhone X support and "Minor bug fixes". The second-to-last update, from 2.3.0 => 3.0.0, was Feb. 2016:


Surprised there (this far) no mention of Authenticator Plus (https://www.authenticatorplus.com/) here. I welcome scrutiny of this option (but I am not affiliated in any capacity with them)

If Authenticator is actually abandoned, are there any suggested alternatives?

I know I can just get a yubikey, but I'm still not comfortable with the process for temporarily authenticating on a computer or phone that isn't mine. In those cases I much prefer to type in a code.

if you are on Android, I highly recommend Aegis https://github.com/beemdevelopment/Aegis

its open source, supports import of keys as well as export with a very active dev.

I've recently tried switching to YubiKeys to store all my 2FA tokens and only later learned that they have a hard limit of 32 stored tokens.

Does anyone know of an alternative hardware token that supports more than that and also all the other protocols that YubiKeys do?

I consider myself a highly technical person, and I don't have anywhere near 32 services that support OTP. I think for most people 32 is currently enough. It would be nice if it were a bigger number, how much space could it possibly take to store the secret and label?

I just migrated from LastPass to Bitwarden and took the opportunity to delete old accounts and enable 2FA or WebAuth or whatever else was available everywhere it is supported.

I'm working my way through the list aphabetically and at "Jetbrains" I reached 32.

This is over ten years worth of accounts. I'm sure I'll reach 50-60 before the end.

Why can't yubikey use a single root secret and derive all sub-secrets from that root secret?

Because usually the server sends the shared secret and there are just 32 slots for shared secrets available.

Yubikey and webauthn[0] supports public key authentication where the client chooses the secret.

[0]: https://webauthn.io/

Yes but that's a whole different 2FA implementation, where sites must support U2F (webauthn). Unfortunately, the implementation of TOTP is far more common than U2F.

Ideally all sites will implement U2F as two factor authentication, but there aren't that many users who have a U2F compatible token. The reach of TOTP is far more beyond U2F, which is probably why sites use TOTP more than U2F.

When sites offer both, choose U2F. When sites offer TOTP only, use it. It is better than nothing. When you have a yubikey already, use the Yubico authenticator app to store the TOTP secret to make your TOTP attack surface less and to have the availability to change your phone without losing TOTP secrets.

>When sites offer both, choose U2F. When sites offer TOTP only, use it.

This, 100%

In some sense TOTP, basically HMAC, seems like it would be harder to screw up than a public key system. RSA is amazingly hard to get right. I wonder if the order of preference should be:


(2). TOTP

(3). U2F RSA

(4). Google Authenticator


(Infinity). SMS 2FA

No idea where ECDAA [0] fits.

[0]: https://paragonie.com/blog/2018/08/security-concerns-surroun...

They should be doing that. Maybe the OP means the limitations on passwordless credentials and not u2f credentials.

I might get the terminology wrong. What I meant are the HOTP and TOTP secrets. They can only store 32 of them.

I've moved to Authy. They allow a backup password to encrypt all tokens on their servers. I think that is a valid tradeoff with a random password saved in Keepass. Otherwise, changing a cellphone (or hard resetting) is an arduous task.

It scans qrcode. It shows current 2fa code. It ensures no one will able to generate your 2fa code without stole the device physically (because it can't be backup).

What else do you need? Why do anyone need to update it if it is completely fine?

Wait, can it steal the stored secrets or just codes? I'd love for a utility that can "steal" the secrets so I can migrate to my yubikey 5c.

If you have a rooted Android phone, I wrote a tool to pull secrets from most popular OTP apps: https://github.com/puddly/android-otp-extractor

You might not even need a rooted phone. For at least one of these apps, you can extract the secrets from an ADB backup, which does not need root (it only needs the developer mode).

Interesting. Do you know which still one allows backups?

Isn't there a way to get it to display the qr codes for connected accounts? Then you could migrate via registering those.

No there's not unfortunately. Nowadays, I encrypt the QR codes using my GPG key and store them with pass.

I remember even installing Google Authenticator for some kind of Microsoft project, which seemed to legitimize it even more.

The fact that malware can steal Google Authenticator TOTP seeds, means that non-malware apps on your phone—e.g. other TOTP apps—could also steal (i.e. import) these seeds, no?

I’d quite enjoy if e.g. 1Password would import all my Google Authenticator tokens into itself automatically. I’ve been meaning to move them over for a long while now, but it’s a whole process, since there’s no place in the Google Authenticator UI to retrieve the original seed value.

It's just using the accessibility privileges to look at the contents of the screen like a screen reader would, and copy the shown code. This isn't quite as advanced as "stealing your seeds".

I thought the keyboard apps listed as abandoned at the end of the article were all rolled into the main Gboard app?

I use the lastpass authenticator and I like it. Works well in conjunction with the lastpass app

Website is blocking my access with a challenge that doesn't work :-(

I've had a few reports of that. Are you using Tor or something similarly exotic?

Assuming this is recaptcha, I have heard that sometimes your IP/cookie reputation can be so bad that they reject valid responses to the challenge.

I'm using PrivateInternetAccess as my VPN.

Is Microsoft authenticator interchangeable with Google's?

This affects any totp app like Symantec VIP, doesn't it?

Is the app truly abandoned? If there's one 2FA app I wouldn't expect to be abandoned, it is Authenticator.

At this point should we assume that ANYTHING Google does will be supported in the future? Fool me once shame on me, fool me over and over again and I'll replace you with someone who cares. This is a pattern of consumer abuse (privacy and abandonware) that Google continues to exhibit. Why should we continue to support them?

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact