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:
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).
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.
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.
Authy (YC W12, ) 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 , 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..
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.
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.
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).
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.
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.
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.
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.
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).
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.
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.
(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:
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.
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).
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.
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.
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?
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?
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.
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.
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.)
Unrelated to this particular snafu but still potentially problematic: if you have your Authenticator account named by its default name (email@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. ;-)
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.
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.
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.
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).