Hacker News new | past | comments | ask | show | jobs | submit login
Warning: Google Authenticator upgrade loses all accounts
344 points by calvin on Sept 4, 2013 | hide | past | favorite | 168 comments
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




Too late for me, but a pleasingly fast and pro-active response from AWS (which rather shows Google up) just received by email:

"If you are an AWS customer who uses Google Authenticator for iOS as a multi-factor authentication device to secure your AWS account via AWS MFA (http://aws.amazon.com/mfa/), please read on. We are writing to inform you that Google has recently released an update to the Google Authenticator App in the iOS Store. We've received reports indicating this update is inadvertently deleting all MFA tokens from the smartphone; this could prevent you from authenticating to your AWS account.

At this point, it is our recommendation that you do not update your Google Authenticator App if you're using an iOS Device. If you have already updated your Google Authenticator app and are no longer able to login successfully you can request assistance from our AWS Customer Service team at:

https://portal.aws.amazon.com/gp/aws/html-forms-controller/c...

We have posted this as an announcement to our AWS Developer Forums at https://forums.aws.amazon.com/ann.jspa?annID=2091 and will be posting updates if new information becomes available."


And no word yet from Google... Their lack of customer service is going to end up killing them in a number of markets. I would never use Google for any critical business function (email, payments, cloud computing).


It's pretty ridiculous that I'll probably move from using GA for my Google accounts to Authy, but here we are.


They'll join this thread in a while and call us all novices for not understanding that this is deliberate, well tested, and our fault.

https://news.ycombinator.com/item?id=6166886


I don't think the people arguing with Justin in that thread are novices or naive users, but they do seem to be unaware that when you lend your computer to someone, you should set them up with their own user account if you don't want them surfing through your stuff.

It's funny how the tech community browbeat Microsoft for years about how Windows should have been designed as a multiuser system like Unix, and then when Microsoft finally took their advice and made the necessary user-level security improvements, their efforts were ignored.


Afraid you've missed the point in the same way as Justin did... Those people (me included) are perfectly aware of that. The argument is that your mother isn't, and while it's reasonable to expect her to be, you can't just assume such.


If so many people are missing the point, then maybe, just maybe, there isn't one to miss.


The majority are always right, for a subjective and wide definition of right.


Because all companies always act like one of its employees did one time.

Not defending Google, but pointing out the sweeping generalization.


To be fair, that wasn't just "one of its employees", it was the head of Google Chrome Security.


What's even worse is with a certain iOS update that may or may not be launching in the next few weeks will make this advice impossible. 3 words for you - Auto updating apps


Which can be turned off


Which 99% of iOS users won't do even if they are aware of it.


I for one won't turn it off, despite having been bitten by this. Life's too short to go around checking HN or Googling for possible adverse consequences of every app update.


That 99% is unlikely to be using two factor auth


Android store can also beturned off.but Google make sure to give you hell for it.

Open market "want to always auto update apps?". No.

Update an app after reading the change log. "want to always auto update apps?". No.

Update the next app... You get the idea.

Also, what's the fallacy about giving you a change log for each version of apps, but not allowing to install other versions? This is the sole reason people will give up those stores. Will not even be the abusive control and price for no added safety.


It's actually opt-in. When you open the App Store for the first time in iOS 7, it asks if you want to enable automatic updates.


I scan the 2D barcode on two apps Google Authenticator and Authy. I also set up SMS Backup and it works well for Gmail/Hotmail accounts.


Just because something is in the cloud doesn't mean you don't need backups.

Backup your entire Google account. Here's a tool to do it: http://www.syncdocs.com/ Print out the 10 password recovery codes Google offers. Here's how to do it: https://support.google.com/accounts/answer/180744?hl=en Having a backup and extra security is essential for everything stored in the cloud.


If you do happen to update and lose your 2FA keys, the AWS people are turning around these lost login requests in <15 minutes. You fill the form out, they call you and verify, and life carries on.


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


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


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


Thanks!


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.


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?


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.


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.


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).


I've been using Authy on iOS7 because of incompatibility issues with Google Authenticator


What do you guys do that duosec doesn't?


Aside from the screwup here, this is a good chance to check backup mechanisms for your various 2FA accounts. If your phone is broken or stolen, do you have a recovery plan?

I keep backup codes for each of my 2FA services in a Truecrypt container, which is mirrored on Dropbox. Additionally, I keep a copy printed out and kept in a fire safe. Phone backups for personal accounts have my wife's phone on record, and I try to keep printed copies of the QR codes I used to set up the account.

About a year ago, my phone was shattered while on the road, and while I was able to regain access to those accounts due to existing login sessions on my home computer, I'd have been sunk without them. Make sure you have a plan for what you do if your phone authenticator becomes unavailable.


A while ago the Android version was replaced by a new app (instead of just an upgrade), allegedly because the team LOST THE SIGNING KEY FOR THE ORIGINAL APP[1].

If there is one team you'd expect not to lose a signing key I would have thought it would be that one!

Everyone makes mistakes, but it's pretty scary to hear this happening too.

[1] http://www.androidpolice.com/2012/03/22/psa-googles-authenti...


The other option is if you are a developer and want ultimate control the app is open source. For maximum convenience aught.


woah, a crypto software team lost a signing key.

that's no good.


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.


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 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.


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.


> special page that isn't linked from anywhere

It's linked from https://security.google.com/settings/security which is itself linked from https://www.google.com/settings/account ...


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

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


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.


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.


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.


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.


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?


You can store the key (the alternative to using a QR code) you're given to set up 2FA in the first place.


Edited: Authy requires a mobile number and a remote server to store your tokens though.


Seriously. What's the difference between this and just setting up a webcam pointed at all your SecurID tokens?


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.


> 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.


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?


You certainly do for Authy, I was apparently wrong about Duo.

http://i.imgur.com/dY1zWUe.png


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).


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.


Quick solution for Google 2-step auth (do it QUICK so you don't lose access to your Gmail)

1) Go to this page https://accounts.google.com/b/0/SmsAuthSettings

2) Click "Move to a different phone"

3) Re-setup your Google Authenticator

Note: the 10 printed one-time access codes and all the application-specific passwords will still work after this "reset". But you still need to reset your other accounts that use the Google Authenticator


I use Google Authenticator on the 2 AWS accounts I manage. Fortunately, at least on the first, the master account didn't have 2FA on it, so took about 60 seconds to reset it. (remove device, then readd) However, most wouldn't have the master account (the entire purpose of IAM).

I suspect that Google may have an update that restores accounts. I know when I've restored my phone, losing all apps, when I reinstalled an app months later, the settings were still there. Obviously the settings are stored in a file somewhere, so my hope is that this is how Authenticator works, and this buggy release just failed to properly open that file. Of course, not everyone can wait and have to reset like I did.


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?


(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. :-/


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'


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.


Awesome. Yeah I clearly am out of my depth :)


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...


otpauth://totp/johndoe@google.com?secret=SECRETKEY1234567


I print them out and stash them in a safe. Also helps when adding MFA to other devices.


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.


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


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!


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.


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.


Yes, but this is the mobile app that lets you log into your account on Google.


This was a perfectly functional app except that it didn't look like google+. I would recommend switching to authy (YC) bc their Bluetooth 4.0 LE implementation is awesome: https://www.authy.com/thefuture#pairing


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.


To disable auto-update on recent Android:

Play Store -> Search "Authenticator" -> Select "Google Authenticator" -> Press "Menu" -> Deselect "Auto-update"


I don't think this is happening on Android, seems to be an issue with an iOS update.


I think this is a good reminder to use the auto-update feature wisely, on all platforms.


I saw Google Authenticator had an update this morning and thought "haha, wouldn't it be awful if it deleted the accounts when I updated!" Well, I guess I'm the goat [1].

I was still signed into Google so that was easy enough to generate a new key, but I believe I'm going to have to use my backup number to get into Dropbox.

[1] http://en.wikipedia.org/wiki/Duck!_Rabbit,_Duck%21


The broken update has now been pulled.


Use HDE OTP, its a better looking app anyway.


Do Google even test the stuff they put out? This is a pretty severe mistake to make for a company as big as Google. Do they not have teams dedicated to testing this stuff? The small design studio I work at does a better job QA'ing their websites than Google does QA'ing major product upgrades... Disgraceful.


Don't be ridiculous. Of course they QA their projects. Shit happens. This issue is of a serious enough nature affecting enough people that there will almost certainly be a proper route back.


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... :)


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.


I used my Pebble watch for TFA. You have to compile the app yourself but it's pretty easy. https://github.com/aaronpk/pebble-authenticator


Don't upgrade! I just had this unpleasant experience and warned everyone about 15 minutes ago: https://news.ycombinator.com/item?id=6325745


I'm not seeing the update in the App Store, nor the app itself. Must be pulled.


What an absolutely awesome time for iTunes Connect to be down for maintenance.


Almost as if Apple is twisting the knife.


The Authy app is great and supports Google, Dropbox, CloudFlare, Amazon…


Shit. I am running the iOS 7 beta with automatic app updates, and I already have the new app.

I am considering wiping my phone and restoring it from a previous backup with the old copy of the app.

Edit: I was still logged in from my browser, and was able to activate the new version without entering a code from the deceased version of the app.

From this, it seems theft of your cookies could let an attacker completely take over your account and two-factor device if they know your account password and you have chosen to trust the victim computer.


If you have a password on your backups, the codes are in your backed-up keychain. (Google Authenticator doesn't mark its keychain entries as "keep on device".) You'll need to patch iphone-dataprotection to handle a the iOS7 keychain format (I added a patch to the bug tracking database.)


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!


Unrelated to this particular snafu but still potentially problematic: if you have your Authenticator account named by its default name (foo@example.com) and you add another account with the same key, it will be blindly overwritten. I found this out the hard way after scanning my Meraki 2FA QR code that was tied to the same email that already had Google 2FA.

ProTip: rename your auth entry to something like "Gmail foo@example" to avoid this problem, whether malicious or accidental.


Luckily got a AWS reminder. And a shameless plug... my own 2FA app on http://gauth.apps.gbraad.nl can be used everywhere you have a webbrowser, offline when your browser supports it and updates without problems when a new version is available. Besides, no updates were needed in months due to good QA. ;-)


Fuck you, Google. Fuck you.


Shit, I am fucked by Google as well ... :(


What I worry about is a hacker feigning to be another user and claiming that they can't access their google account anymore because of a botched update.

I guess Google support might get too many reset requests to show due diligence in verifying authenticity of the requests.


Not an iPhone user, but I wonder if you could access the key data manually and restore it afterwards?

On Android that's possible (if you have root....) by accessing the key database (sqlite in that case). I did that to duplicate the keys from my handset to my tablet.


Yes, if you have synced with iTunes before the update. If that's the case you have to delete the updated app from the phone, connect phone to iTunes (do not sync or transfer purchases) and copy over the old app from iTunes to phone and it will restore the old version + app data.


didn't work for me - app was restored but not data


Restoring from an iTunes backup should restore both the old version and the app data.


Just in time for Github to add 2FA.


Chris Messina has a solution: https://twitter.com/chrismessina/status/375118991280205824


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.


Don't forget that Duo Security's mobile application supports Google Authenticator (and any other TOTP-enabled service). It also has already been working on iOS 7 for weeks.


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.


Related: will iOS 7 let you turn off the auto-update feature?


Thankfully yes it does.


Does this affect android? my phone is off and I am not turning it on until I can somehow disable auto update from the play store from web.


Happened to me as well, fortunately I disabled 2FA on my Dropbox account before the upgrade, thanks to this warning!


Thanks for the heads-up all! Looking forward to actually being able to distinguish Authenticator accounts on iOS 7.


iOS7 beta automatically updated my Google Authenticator. The 'updated app' indicator is taunting me.


This is the most pressing and actionable information I have ever gleaned from a news site. Thank you!


this is especially bad for mtgox as it does not have backup codes or cellphone backup.


lesson learned : do not upgrade anything unless you read some feedback about it.


Is anyone else just happy that the assets will finally be high-res? :P


I recommend using the Authy app instead, it's much better


I'm just glad it works full screen on the iPhone 5.


Some guys really needed retina support. Now you got it.


Damn it... This is stupid, I just upgraded too.


Thanks for letting us know.


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.


> 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.


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


Somewhat related, but when I setup two factor authentication I securely saved the initial TOTP tokens (using barcode scanner to extract it) for exactly this sort of situation (well in my case it was that I switched smartphones enough that having it tied to one was nonsensical).




Consider applying for YC's W25 batch! Applications are open till Nov 12.

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

Search: