Warning: Google Authenticator upgrade loses all accounts

344 points by calvin ↗ HN
I upgraded Google Authenticator to the latest version this evening on my iPhone. It lost all my accounts.

DO NOT UPGRADE Google Authenticator or you'll have a really bad day.

People on Twitter are starting to complain: https://twitter.com/search?q=google%20authenticator&src=typd

175 comments

[ 3.8 ms ] story [ 216 ms ] thread
Use HDE OTP, its a better looking app anyway.
How did 3 minutes of dogfooding not catch this?
(comment deleted)
I actually just switched to Duo Mobile earlier today because of iOS 7 issues with Authenticator; this just cements my decision to switch.

Edit: oddly iOS 7 hasn't autoinstalled this yet.

> I actually just switched to Duo Mobile earlier today because of iOS 7 issues with Authenticator; this just cements my decision to switch.

I moved all my non-critical stuff over (to test it out), saw the Google Authenticator update, and then had to go and reconfigure those accounts anyway.

I highly recommend making sure your backup phone number is updated and verified and/or you have backup codes prepped.

Luckily I was still logged into all my accounts (my Dropbox account suddenly dropped from Google's app like a week ago)

Duo seems to be quite nice, I doubt I'll end up using the backup codes.

Incidentally, GitHub has it right - "download a text file of your backup codes" is much easier than "print this page nad hope you don't lose it"; I find find(1) outpaces my frantic drawer-emptying.

I've just noticed that Google has the download-as-text functionality now too.
I wonder how many machines have those backup auth token text files sitting on the Desktop or in the Downloads folder?
oddly iOS 7 hasn't autoinstalled this yet.

That is odd - it installed several hours ago for me.

For those looking for Google Authenticator alternatives, I recommend either Duo Mobile from Duo Security or Authy. I ditched Google Authenticator a while ago and haven't missed it one bit -- having a single app manage my two-factor tokens / keys is much more convenient.
Edited: Authy requires a mobile number and a remote server to store your tokens though.
This is not at all true. Both are generating your tokens clientside with no internet connection. Try disabling internet access, it should work.

As for the mobile number, I didn't have to type that into Duo Mobile when I installed?

Seriously. What's the difference between this and just setting up a webcam pointed at all your SecurID tokens?
> Both require your mobile number and for a remote service to store all of your tokens though..

Duo does not, for the record. Download and go.

I seem to have recalled that one wrong then, or they've changed their service since I last saw it.
(comment deleted)
Duo does not require this at all. And Authy only requires you to store their "Authy" token. You can add additional, e.g. Github, tokens to Authy and choose not to sync them with the Authy servers. That's what I do.
Authy requires your mobile phone number and the creation of an account to work at all … or am I missing something? I haven't found a way to use Authy without providing my mobile phone number and creating an account.
In light of this incident with GA, do either/any of the alternative support "export" of the underlying secrets, for instance to migrate to a new app?
(comment deleted)
You can store the key (the alternative to using a QR code) you're given to set up 2FA in the first place.
I switched to HDE-OTP[0] a while ago and never looked back. I've not encountered any bugs with it and it's also better looking.

[0]https://itunes.apple.com/gb/app/hde-otp-generator/id57124032...

You have a beautiful screen on your iPhone with great font rendering and ... it mimics a 7 segment LCD display.

For shame.

Almost like building a notes app and putting leather stitching all around it.

Skeumorphism is dying, thankfully.

Yep, HDE OTP works great and looks nice. Thanks.
I second the recommendation for Duo. Its a great application, and if you're looking for adding 2FA to your own systems (IT or otherwise) has a multitude of interaction options (secondary password LDAP, etc).
If you offer two-factor authentication for your website, be prepared for a surge in support requests today. When I talked to one of my providers on the phone, they stated they are already getting a surge in calls because of this app update.
The Authy app is great and supports Google, Dropbox, CloudFlare, Amazon…
If they had released this two weeks later, iOS 7's auto-update feature would have bricked everyone's accounts.

Google Auth 2.0 redefines two-factor auth: something you know + something you DON'T have. Their entire purpose in life is this second part and they completely and absolutely botched it. I can't believe this passed testing at both Google and Apple. There wasn't even a warning in the release notes.

>There wasn't even a warning in the release notes

Do you think they would have released it if they knew about it?

Probably not, but I use several apps that put a big "BACK UP YOUR APP DATA BEFORE UPGRADING" in their upgrade release notes. I'm just shocked they didn't know about it because the upgrade process wasn't even in their test plan.
This isn't addressing the (obviously rhetorical) question of whether they knew in advance, but now that they do know, fwiw:

They have the ability to yank the updated version any time, 24/7, at a moment's notice, until a fix is available.

They also have the ability to update the release notes after the fact.

They have the ability to yank the updated version any time, 24/7, at a moment's notice, until a fix is available.

Not when iTunes Connect is down for maintenance, they don't. Worst possible timing.

I think Google's thinking on this is that 2FA tokens are definitely "one of those things you don't want stored in an subpoenable manner by your Cloud provider." If your 2FA token is synced to iCloud, for example, then it's no longer something you have--it's something else you know (your iCloud username+password.)

"Something you Have"-type tokens provide security basically because they're immune to rubber-hose cryptanalysis: if you really just don't have the key to a safe, nothing an attacker does can make you give it to them. As such, tokens are also the factor that protect you from contempt-of-court charges if you're compelled to provide it. (Though they can then ask you "who does have a key?"; if this is an accomplice, it's best if they live in a separate country, and hopefully one which doesn't like the US very much.)

I'm sorry, I don't follow your logic. Are you trying to say you think Google actually had a rationale for this behavior? Where does "the cloud" come into the equation? This data isn't being synced to iCloud. That defeats the whole purpose.
Because Google fundamentally wants everyone to use Google+ for everything, and their Google Accounts to sign into it. If they weren't thinking about the security implications, Google Authenticator would definitely be a "sync your credentials to your Google Account" app.

I assume that the implementation of 2FA was a 20%-time project (it's sort of sloppily integrated; you need to find a special page that isn't linked from anywhere whenever you need to add an application-specific password, for instance) which reeks of it not being orders from on high. So, the people who implemented 2FA at Google were probably just some people who fundamentally care about 2FA. People who know what "Something you Have" actually means.

I don't think this argument makes any sense with regard to TOTP, as Google (or Dropbox, Twitter, etc.) most certainly knows the seed/secret for your account at their service and could be forced to divulge it via court order. Or they could simply cough up the plaintext data sans faffing about with 2FA at all. 2FA of this sort only makes it harder for an attacker to get in.

Defense against rubber hose cryptanalysis comes into play where the key only exists in one place, such as the asymmetric private key on hardware security module, or perhaps a symmetric key stored on a physically-unavailable USB key. But 2FA like TOTP does not imply encryption, even though it relies on some cryptographic primitives.

Keep in mind that Google Authenticator stores arbitrary third-party credentials, though. Subpoena Google and you could get Google's TOTP token for you, along with the rest of your account, sure. Sync Google Authenticator to Google, and suddenly they don't have to subpoena anyone else--just use their Gmail account to reset all their passwords for every other service, and use their TOTP tokens to sign into them. This basically removes the "Principle of Least Privilege" way that subpoenas work.
Thanks for the heads-up all! Looking forward to actually being able to distinguish Authenticator accounts on iOS 7.
Every time I upgraded to a new iOS 7 beta, it wiped my Google Authenticator account tokens. It wasn't a big deal with Google or Dropbox because both allow me to move. But I can't log in to my CampBX account anymore. I tried Authy today after another comment here on HN and it's been working so far.
I'm just gonna point out that the previous update was somewhere around 2 years ago, and it's just now getting retina, so we should be glad there's even this much.
Yeah, now I can view my missing one time codes in retina, edge to edge quality. Yay!
When I add sites to Authenticator, I take a screenshot of the QR code and tuck it away in an encrypted document (OneNote for the record, which uses uses AES to encrypt).
Have you tested this? Are the barcodes not time pertinent?
otpauth://totp/johndoe@google.com?secret=SECRETKEY1234567
(I've studied two-factor authentication using HOTP and TOTP, and built a node.js implementation of it.)

The QR codes simply divulge a URI with the secret key for generating tokens. They look like:

  otpauth://totp/[keyname]?secret=[secretkey]
The secret key is used in the app in conjunction with a moving factor (usually 30-second intervals of time) to generate a numerical hash of sorts for that interval of time, which is then truncated to 6 characters.

The QR code itself doesn't have any sort of time limit on them; they only serve to transmit the secret key.

This. I scanned one QR code with a regular QR code reader and came to the same conclusion...

I haven't actually tested it though. :-/

fine, outdo me haha. Saving the Key is useful with AWS MFA because if some reason you loose your MFA Virtual Key (app updates and you loose the key) you have to contact AWS to have it reset, Can't just do it yourself.
Would this mean that these two values are stored locally? Could they be extracted from the GA app?
Technically, yes. The name of the key is set by default as the account name in the app. I haven't looked into how the secret is stored in the Google Authenticator app—hopefully it's stored securely or with some level of obfuscation, but the app definitely needs to be able to retrieve the secret key somehow to do the token calculation.

One thing to note is that neither Google Authenticator nor Duo Security let you display the secret itself in the app. Another thing to note is that Google Authenticator keys seem to be backed up if you back up your iPhone to a computer using iTunes (mine were still there after a restore).

If you've disabled the built in protections on Android for the /data/data/ folder (such as "root"ing it), getting the keys out is as simple as:

$ su

# sqlite3 /data/data/com.google.android.apps.authenticator2/databases/databases 'select email, secret from accounts'

They are not. I've done time many times now. Very handy when switching between phones because you don't have to recreate the tokens every time you switch.

Just be mindful that whenever these screenshots get compromised, you lost all your tokens.

Yes I have tested this and it works. Of course make sure those screenshots are safe and encrypted too.
Or print them out and store them in a bank safe...
I print them out and stash them in a safe. Also helps when adding MFA to other devices.
Man, someone is going to have a really really bad day tomorrow.
Someone should be having a really bad day right now. The app needs to be pulled from the App Store immediately.
I cannot login to my AWS account right now, thanks to Google, nicely done... :)
Authy (YC W12, [1]) is a nice replacement for the GA app. Besides being more stable, it has also the "benefit" of allowing you to back up your keys, and recover in the case of a lost phone or deleted app.

Thankfully, backing up is entirely optional, and turned off by default. While they claim backups are encrypted with PBKDF2 [3], I still would never ever use something that sends my tokens to a remote server, as it'd defeat the purpose of 2FA in the first place.

Still, I can see the use for casual users that care enough to have 2FA, but not that much to worry about tokens being stolen and decrypted from Authy..

Past discussions on HN here [2], [3], [4].

[1] https://www.authy.com/thefuture [2] https://news.ycombinator.com/item?id=6133648 [3] https://news.ycombinator.com/item?id=4916983 [4] https://news.ycombinator.com/item?id=4330050

You had me until "backups are encrypted with PBKDF2". PBKDF2 is not encryption, it is a Key Derivation Function (it says so right in the name - KDF). Given that one of the developers is claiming that they are "encrypting" using PBKDF2 (which is in the same category as claiming that they are encrypting using MD5!), dissuades me from ever using it or recommending it.
I may be totally wrong, but isn't PBKDF2 useful exactly as a way to generate an encryption key from a password?
Sure, in the same way that MD5 is (although you'd want to use PBKDF2 instead of MD5). But you can't actually encrypt with PBKDF2 itself, much like you can't with MD5
From the linked discussion ([3] above):

> 1. We use a 256 bit key derived using a salt and PBKDF2.

> 2. AES is used in CBC mode with a different IV for each account.

> 3. The key is store on the cellphone only and is never transmitted

> 2. AES is used in CBC mode with a different IV for each account.

Depending on the actual implementation (if everything is just one encrypted blob or if individual records are encrypted separately) using the same IV for all data in one account can be pretty bad.

You're perfectly right. PBKDF2 (Password-based Key Derivation Function 2) takes your password as an input, derives a key from it and outputs that. This key is then fed into an encryption algorithm like AES in order to actually encrypt anything.
I've been using Authy on iOS7 because of incompatibility issues with Google Authenticator
Nice idea, but I hated the workflow of setting up an account - first I have to type in a phone number manually twice, which is easily readable from Android. I also missed an explanation why I needed to set up an encryption token rightaway (I get what the point is, I'd just much rather try using the app first without having to set up all kinds of passwords and credentials first).
Authy wants to 'make data available to nearby bluetooth devices' and – even if you don't allow for it – asks for Bluetooth to be turned on. What's the reason for this requests?

I'd appreciate an application directly in the app. In doubt, I simply deny such requests.

Screenshots:

http://i.imgur.com/jTC5msY.png http://i.imgur.com/seytfhy.png

It gets even more confusing:

Authy asks me for my mobile phone number – once to 'securely identify' me and once to create an account, apparently with Authy.

Why is an account necessary for such an app? Can't I use Authy without an account?

Authy is first and foremost its own 2FA system based around ownership of a phone number. Where most phone based 2FA systems just send you a SMS message with a code you need to enter, Authy installs an app on the phone in question that fingerprints the phone. The fact that you can also use Authy to store other 2FA codes as well is just viewed as a bonus feature by Authy.
Authy has a desktop client that can request tokens from your phone via Bluetooth, so you don't need to generate a token and type it in manually.

https://www.authy.com/thefuture

Good, so when the user requests a bluetooth connection you ask for permission or tell the user to turn bluetooth on

Don't ask the user to approve something he: doesn't know what you want to do with it and the thing screams "don't do it" at the particular situation

This is why you keep backups of your TOTP authenticator keys. I was really put off by 2 factor until I figured a way to do a backup. Authenticator URLS look like this:

otpauth://totp/KeyNameHere?secret=SECRECTKEYSTRINGHERE

You can save it in some passworded zip archive somewhere or print it out. If you print them I suggest printing them with QR codes to aid in recovery speed. You can easily generate QR codes by putting the text URLs into a QR code generator. If you just have a QR code, use a general QR code scanning app to extract the string.

Also the new google authenticator version has a %100 repo crash bug when you scan two QR codes in a row on iOS 7 phones.

What does it mean that it 'loses all accounts'?

I use two factor auth but not this app, so I am not sure why people are going to have such a bad day...

You add your Google (and potentially other) accounts in the app - then you need to open the app to log in to your account.

The app is "forgetting" and no longer displaying the accounts you add, such that you open Authenticator and it's empty.

You can no longer log in to your Google account without one of the 10 printed one-time access codes you made when you first set it up.

> You can no longer log in to your Google account without one of the 10 printed one-time access codes you made when you first set it up.

* or a backup phone number that's been verified (i.e. send a verification code and confirmed).

Hm, the point of authenticator is to not use the phone, because phjone numbers may be more vulnerable. wasn't there a case of social hacking where the telco forwarded to hacker's phone?
That was a case of them circumventing the 2FA he had, they just granted access. Authenticator is a mobile phone app, how are you supposed not to use your phone with it?
You could set it up on a tablet.
Which are still quite a bit rarer than smartphones. Plus it makes your password way less portable.
I measnt not use the phone network, because the SMS could be diverted.
You get greeted by a "let's begin" screen, and all your accounts/credentials have magically gone away. This happened to me 5 minutes ago.

Edit: tweet with picture: https://twitter.com/jawj/status/375144792126410752

So your account has not gone away, nor has it been deleted, nor has any magic happened; your account is still there safe and sound on Google's servers, it's just that the settings in this one mobile app have been wiped, correct?
Without the settings in your authenticator you're locked out of accounts that require a 2-factor token from it, unless you've got backup tokens printed out.
Yes, but this is the mobile app that lets you log into your account on Google.
(comment deleted)
Correct. As long as you have a backup method of logging in (one time use password, phone # recovery, etc) you can get back in and register new 2FA.
Well, depends on where you're looking. The app's record of the account has gone away. Given that this is an authentication app, that's a rather serious problem.
That seems awfully similar to what keeps happening with their G+ and Hangouts app: every few weeks, the apps think you never logged on the damn thing, and take you back through the whole process including a welcome tour!
Just in time for Github to add 2FA.
That's only good for Google accounts. Dropbox and others aren't reset as easily.
Dropbox has the option to add a backup SMS phone number in addition to offline TOTP code. Here are some other steps you can follow if your Google Auth app got wiped:

- https://www.dropbox.com/help/364/

Dropbox gave you a code when you turned on 2FA and told you to keep it safe.

You can also recover your Dropbox account from any connected computer. It'll log you in on the web console without a password or 2FA.

What an absolutely awesome time for iTunes Connect to be down for maintenance.
Almost as if Apple is twisting the knife.
This is the sort of "nightmare scenario" I'm afraid of, and why I'm still not using 2FA. I'd rather risk having only a weaker password, than risking losing my accounts for good. You can't get back into your accounts if something like this happens, right?
To get back into your account you're provided backup codes that you're supposed to store somewhere safe. Otherwise, if your phone were stolen you'd be out of luck, yes.
I was about to respond "Haha, no big deal, I use my Google Voice number". The flaw in this was readily apparent.
I cannot fathom why people still rely on Google for their core business needs.

At my last place of work I built an SMS system to be used as the second factor in the intranet login. I _could_ have used a 3rd party 2FA, but the most _logical_ reason to have our own system was ... well.. we didn't want to rely on anyone except ourselves.

Didn't take me long and the most difficult part was finding enough USB-connected phones to be used as SMS senders.

Guess what? The system still works today, why Google is broken.

Our company started writing their own verilog & soon we'll have chips for our custom designed smartphones. Yay !

Till then, we are stuck with silly can phones :(

You have your own mobile network? Sweet. I just use this open source thing that doesn't rely on anyone else
> didn't want to rely on anyone except ourselves.

And the remarkably secure telecom system, of course.

Google's style of 2FA is IMO technologically superior in that there is no communication after the initial seed. It also appears to be somewhat standardized -- see others posting about Authy. You could have your own handwritten program running the algorithm if you wanted to be independent.

The real screw up on Google's part is not instructing users to have an encrypted backup of their 2FA data.

Well, they do instruct people to print backup codes.