STE WILLIAMS

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.

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!

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/KUbESaxAeDM/