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.
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.
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.
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.
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.
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?
> 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.
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.)
> 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.
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:
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.
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
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.
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.
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?
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.
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?
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.
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.
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)."
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.
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)
[+] [-] dang|6 years ago|reply
[+] [-] Someone1234|6 years ago|reply
- 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.
[+] [-] drewg123|6 years ago|reply
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.
[+] [-] DCKing|6 years ago|reply
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.
[+] [-] 101404|6 years ago|reply
None at all. Or did I miss something?
[+] [-] asdfasgasdgasdg|6 years ago|reply
[+] [-] izacus|6 years ago|reply
I don't like that viewpoint.
[+] [-] Piskvorrr|6 years ago|reply
"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.
[+] [-] takeda|6 years ago|reply
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...
[+] [-] jakub_g|6 years ago|reply
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?
[+] [-] Aaargh20318|6 years ago|reply
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.
[+] [-] ppseafield|6 years ago|reply
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.
[+] [-] derefr|6 years ago|reply
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.)
[+] [-] edent|6 years ago|reply
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.
[+] [-] AdmiralAsshat|6 years ago|reply
[+] [-] gerash|6 years ago|reply
https://www.newsbtc.com/2017/06/03/coinbase-recommends-users...
[+] [-] whoisjuan|6 years ago|reply
[+] [-] fullstop|6 years ago|reply
[+] [-] chasingthewind|6 years ago|reply
[+] [-] djanogo|6 years ago|reply
[+] [-] otachack|6 years ago|reply
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.
[+] [-] excerionsforte|6 years ago|reply
[+] [-] antaviana|6 years ago|reply
[1] https://docs.microsoft.com/en-us/azure/active-directory/user...
[+] [-] Slartie|6 years ago|reply
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).
[+] [-] wpietri|6 years ago|reply
[+] [-] gerash|6 years ago|reply
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?
[+] [-] laumars|6 years ago|reply
[+] [-] thekyle|6 years ago|reply
[+] [-] notlukesky|6 years ago|reply
[deleted]
[+] [-] kjaftaedi|6 years ago|reply
The way the source article reads, it seems like the vulnerability would affect any OTP app.
[+] [-] edent|6 years ago|reply
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.
[+] [-] smt88|6 years ago|reply
Even if the code were bug-free at the time, dependencies, APIs, and attacks change.
[+] [-] ThePhysicist|6 years ago|reply
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.
[+] [-] nucleardog|6 years ago|reply
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.
[+] [-] zouhair|6 years ago|reply
This is one of the main reasons I stopped using any of their new projects.
[+] [-] fredley|6 years ago|reply
0: https://github.com/beemdevelopment/Aegis
[+] [-] Satwell2|6 years ago|reply
[+] [-] vzaliva|6 years ago|reply
[+] [-] edent|6 years ago|reply
I'm sorry I didn't make that clearer.
[+] [-] Avamander|6 years ago|reply
[+] [-] darawk|6 years ago|reply
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.
[+] [-] skyfaller|6 years ago|reply
[+] [-] zackify|6 years ago|reply
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....
[+] [-] notlukesky|6 years ago|reply
[deleted]
[+] [-] acdha|6 years ago|reply
https://www.yubico.com/products/services-software/download/y...
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.
[+] [-] danso|6 years ago|reply
https://apps.apple.com/us/app/google-authenticator/id3884976...
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] gaia|6 years ago|reply