Warning: Google Authenticator upgrade loses all accounts
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 ] threadEdit: 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.
As for the mobile number, I didn't have to type that into Duo Mobile when I installed?
http://i.imgur.com/dY1zWUe.png
Duo does not, for the record. Download and go.
[0]https://itunes.apple.com/gb/app/hde-otp-generator/id57124032...
For shame.
Skeumorphism is dying, thankfully.
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.
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.
"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 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 ...
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.
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.
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).
$ su
# 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.
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
> 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'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 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?
https://www.authy.com/thefuture
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
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.
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
- https://www.dropbox.com/help/364/
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.
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.
Till then, we are stuck with silly can phones :(
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.