DO NOT UPGRADE Google Authenticator or you'll have a really bad day.
People on Twitter are starting to complain:
"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:
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."
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.
Not defending Google, but pointing out the sweeping generalization.
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.
Backup your entire Google account. Here's a tool to do it:
Print out the 10 password recovery codes Google offers. Here's how to do it:
Having a backup and extra security is essential for everything stored in the cloud.
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..
Past discussions on HN here , , .
I'd appreciate an application directly in the app. In doubt, I simply deny such requests.
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
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?
> 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
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.
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 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.
that's no good.
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.
"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.)
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.
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.
It's linked from https://security.google.com/settings/security which is itself linked from https://www.google.com/settings/account ...
Do you think they would have released it if they knew about it?
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.
Not when iTunes Connect is down for maintenance, they don't. Worst possible timing.
Skeumorphism is dying, thankfully.
Duo does not, for the record. Download and go.
As for the mobile number, I didn't have to type that into Duo Mobile when I installed?
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.
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 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.
The QR codes simply divulge a URI with the secret key for generating tokens. They look like:
The QR code itself doesn't have any sort of time limit on them; they only serve to transmit the secret key.
I haven't actually tested it though. :-/
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).
# sqlite3 /data/data/com.google.android.apps.authenticator2/databases/databases 'select email, secret from accounts'
Just be mindful that whenever these screenshots get compromised, you lost all your tokens.
I use two factor auth but not this app, so I am not sure why people are going to have such a bad day...
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.
* or a backup phone number that's been verified (i.e. send a verification code and confirmed).
Edit: tweet with picture: https://twitter.com/jawj/status/375144792126410752
Play Store -> Search "Authenticator" -> Select "Google Authenticator" -> Press "Menu" -> Deselect "Auto-update"
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.
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.
ProTip: rename your auth entry to something like "Gmail foo@example" to avoid this problem, whether malicious or accidental.
I guess Google support might get too many reset requests to show due diligence in verifying authenticity of the requests.
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.
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.
Edit: oddly iOS 7 hasn't autoinstalled this yet.
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.
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.
That is odd - it installed several hours ago for me.
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.
Till then, we are stuck with silly can phones :(