The problem with the Google Authenticator


A good mobile network coverage, cheap smartphones and the trend “bring your own device” led to a paradigm shift in two factor authentication. A few years ago two factor authentication was a topic for large companies and those with a high need for security. But now two factor authentication is handy and cost efficient.

And finally we all learned that we should do something about our data security.

I very much like that everybody is thinking about increasing their security, but when talking of smartphone apps, email or SMS, we also have to be aware of the limits, that come with these convenient solutions. In certain cases the so called two factor authentication again boils down to one factor.

The Google Authenticator

The Google Authenticator was one of the first apps, that provided the OTP functionality with a piece of software on your smartphone. The Google Authenitcator supports HOTP and TOTP algorithms. Possible other apps are FreeOTP (TOTP) or HDE OTP (TOTP).

Using your smartphone as an authentication device can indeed make sense. An important aspect of the factor “possession” is, that the user takes care of this factor and does not leave it on the desk or plugged into the computer when going for lunch or leaving the room otherwise.

The Seed (1)

The OTP algorithms HOTP and TOTP are based on a symmetric secret key which is also called seed. Using the algorithm, the seed and a moving factor the OTP value is calculated. This means that the seed needs to be protected. We doubt that you can protect the seed in the smartphone on a high security level. The smartphone is a powerful computer with old, not up-to-date software and usually a bad virus protection.

The Seed (2)

But the even much simpler misuse is during the enrollment process. The initialization of the smartphone app.


With the Google Authenticator this happens with a QRCode. The QRCode contains the seed in clear text. The above code has the contents:


The value O6LVCAVTS2IJ25NKXKOOGCNTJIOFNUXA is the secret key in the so called “base32” notation. This might look complicated to an untrained, human being eye. But the computer takes this as clear text for real.

As this is a timebased OTP token (TOTP), each device that scans this code will create the same OTP value. The value will change, but it will be the same value. On each device. Always.

A Self-experiment

Do you have two smartphones at hand? Install the Google Authenticator on both smartphones or HDE OTP or FreeOTP. The only prerequisite is that the smartphones have the exact time.

Experiment 1

Scan the QRCode with smartphone A and scan the QRCode with smartphone B.

Start the Google Authenticator and watch that both smartphons will show the same one time password. The same one time password two times? This is wired. Something is wrong with the naming here.

Experiment 2

This experiment gets even worse. Delete the token from smartphone B. Print out this blog article or at least the QRCode. Put it into the drawer for about a week.

After this week open the drawer, take the sheet of paper an scan the printed QRCode with the smartphone B. Smartphone B will show the same QRCode as smartphone A immediately.

The problem in your company

Due to the nature of the TOTP algorithm and the rollout procedure of the Google Authenticator you can create identical copies of those tokens. Even after a week or a year.

If – as a company – you want to avoid that users give their passwords to their colleagues you are in a mess. You must not rely blindly on the two factor authentication. The same QRCode can be scanned by all colleagues and thus each colleague can login as his pal without any hassle – since he has a copy of his second factor. And again you – as a company – can not reliably identify which employee logged in, when you see a certain user account. The idea of the second factor is void.

A possible solution

The problem is in the rollout process where the secret key is provided in clear text. A better rollout concept like the one of the TiQR-Token can help. In this case the smartphone creates the secret key. The scanned QRCode just contains a registration link, to which the secret key is sent by the smartphone. But this rollout process requires a slightly more complicated running infrastructure. The smartphone needs to be online, the registration link has to have a certificate trusted by the smartphone.

Especially the ease of the rollout of the Google Authentication probably lead to its success. So you see you need to plan and think things through when implementing a two factor solution in your network. A weaker security is only acceptable if you are aware of its side effects and consequence and you can accept the remaining risk.