Google coding glitch locks Apple iOS users out of on-line accounts

Filed Under: Cryptography, Denial of Service, Featured

Google has once again found itself all over the IT news for a spot of bother with its security software.

The good news is that the problem isn't quite as dramatic as the recent code verification bugs in Android, because it doesn't open any security holes.

In fact, it doesn't affect Android users at all.

It's a fault, apparently, or was until the app was withdrawn, in the Google Authenticator software in the Apple Store.

The bad news is that if you were affected, you'd have found quite the opposite of security holes: you'd have been locked out of your own accounts.

To explain, the Google Authenticator app is a software based Two Factor Authentication (2FA) token.

More precisely, it's a One Time Password (OTP) generator, commonly used to implement the second factor in a 2FA login process.

To protect an account with the Authenticator, you prime the app with a random secret key generated by the server hosting your account; this secret key is saved on the server side, too.

The secret key may be provided as a barcode you simply scan in, or as a character code you type in by hand.

Later on, when you want to login, for example from your laptop, you type in your username and regular password in the regular way, and then read off the relevant one time password displayed by the Authenticator app:

This completes the 2FA process, with your username and regular password being the first factor, and the OTP the second.

To make the OTP unique for every login, either a counter (which is bumped up by one every time you try to login) or the current time (to the nearest 30 seconds) is mixed together with the secret key, and hashed to create the OTP.

→ Google Authenticator has some features specific to Google accounts, but can be used with many third party sites as well. It is based on open standards called HOTP (HMAC-Based One-Time Password Algorithm, RFC4226) and TOTP (Time-based One-time Password Algorithm, RFC6238).

The big deal in this, of course, is that both you and the server need to have and to hold the secret keys, from this day forward, for better for worse, for richer for poorer, in sickness and in health...

...because if either of you forgets the secret key that goes with an account, you won't be able to come up with matching OTPs next time you try to log in, and that will be that.

As the Authenticator app itself warns you when you try to delete an account on its list:

Removing this account will remove your ability to generate codes, however, it will not turn off 2-factor authentication.

Before removing: turn off 2-factor authentication for this account, or ensure you have an alternate mechanism for generating codes.

Sadly, removing all your accounts is exactly what happened during a recent upgrade to the iOS version of the Authenticator.

Update. The iOS version is back in the iTunes store, with the bug fixed. Seems that the accounts weren't physically deleted. They were just "visually deleted," i.e. not displayed. [Added 2013-09-07T16:34Z. ]

As I said, at least it wasn't a security hole, though that's probably cold comfort to anyone who ended up locked out of their own accounts.

And remember that a bug of this sort, no matter how regrettable, is not the most likely way you'll lose access to accounts that you've protected with Google Authenticator.

You'd be just as stuck if you went on an overseas trip and left your mobile device behind by mistake, or if someone stole it, or if you accidentally dropped it over the side of a Harbour Ferry.

So, to reduce the risk of a Denial of Service against yourself, no matter how much you trust the Google Authenticator software:

  • Keep backup copies of the barcodes or starting keys for any account you add to the Google Authenticator. (NB. Don't store the backups on the laptop you're protecting with 2FA in the first place! Encrypt them and store them offline, and preferably offsite.)
  • Consider using alternative OTP software, instead or as well as the Authenticator, that makes it easier to take a secure local backup of the secret keys for your accounts after they've been activated.
  • Generate account recovery codes for services on which you will be activating 2FA, and keep them in a safe place.

Backup is still important, even in the modern Cloud Era!

, , , , , , , , ,

You might like

10 Responses to Google coding glitch locks Apple iOS users out of on-line accounts

  1. Mary M. · 767 days ago

    So if we are among those locked out of their account - what's now to be done?

    • Joe · 767 days ago

      Contact the support departments and/or go through the available account recovery options the services where you have affected accounts offer you.

    • James · 764 days ago

      If you apply the update 2.0.1 from app store your old accounts come back. I had already had to readd mine, and after the update I had the new and old entries.

  2. Nick D. · 767 days ago

    Can't you just send the verification code via SMS? I've had to do this in the past when I re-installed the software on my smartphone.

    • Linda · 767 days ago

      How insecure is SMS? Very!! Never use it for anything that has any security implications, even vaguely!
      That's why you should not send, nor ask to be sent any verification codes that way.
      Who can read them? Almost anybody with the desire to pry on your activities- that includes government departments anywhere in the world!

      • Ray · 766 days ago

        What a ridiculous comment! Paranoid much. Not to mention preaching very inaccurate information.

        If you've got your mobile in hand, there is no reason why you can't use SMS codes for verification. It is no different to using the Authenticator app on your phone. The code can only be used once and they are only valid for a short period of time.

        Get a clue, seriously!

      • Paul Ducklin · 766 days ago

        The main disadvantages of SMS-based authentication are:

        1. SMS delivery isn't guaranteed, which can leave you locked out.

        2. Mobile phone numbers can be "ported" to another SIM - as your mobile phone shop will do if you lose your SIM card, or someone else socially engineers them into believing you have done so.

        If you see your mobile phone has lost service where you would not expect it to do so, report it as soon as you can. (Sadly, when crooks do a "SIM swap" they get hold of your authentication codes, but you can't call the mobile phone company to warn them!)

  3. Lee · 767 days ago

    What I can't believe is that they didn't test the new version of the app on accounts with data in them, like a normal upgrade. Really? Something needs to be done about QA here...

  4. Fred · 766 days ago

    Gmail has an option to generate a set of 10 back-up one-time codes, to use in case you lose your phone or simply don't have mobile service. But since these 7-digit codes are good until you use them, doesn't this obviate the benefits of a 2FA system with codes that expire every minute?

    • Paul Ducklin · 766 days ago

      As long as you store the "emergency" codes offline somewhere, they can be handy in case the Authenticator app blows up again :-) Or in case you lose your phone, or whatnot.

      The emergency codes still work once each only, so as long as you store them where they can't be sniffed/logged/grabbed, they do perform as OTPs.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog