52

Warning: sharing your TOTP seed with third-parties breaks the very basic assumption of multi-factor authentication that the TOTP seed is secret.

So, I'm aware of the documentation on this, found here: Google Authenticator Key URI Format

When I follow this example from that page:

otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example

And I 'splice' it into a Google Charts URL, thus:

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example

It will display a valid QR code, and if I scan it with my Google Authenticator app on my phone, it will begin to generate valid OTPs.

However, in the display on the phone, for the entry created by the QR code, I get the OTP, and under it, I get 'Example:alice@google.com'. What I want, is to have 'Example' displayed above the OTP, and 'alice@google.com' displayed below the OTP. I can't help but notice that's the way all the professionally produced apps do it. For example, Google, Wordpress, Amazon, etc. The company name is above the OTP, and the username is displayed below the OTP. Yes, this is purely a cosmetic issue, but I want to get it right.

Can anyone offer me a clue?

kravietz
  • 10,667
  • 2
  • 35
  • 27
Mark J. Bobak
  • 13,720
  • 6
  • 39
  • 67
  • 9
    I would not consider it wise to use online generators for this kind of think. After all, you post all the login information plus the secret to the web. So everyone finding this info (e.g. in a log file) will be able to log into your account. – Ber Mar 20 '18 at 15:59
  • @Ber, not sure what the issue is here. Even if Google logged everyting you submit to a log file, all the log file would contain is the SECRET. Ok, but without having any idea what server, what username, what password, the type of account, etc....Where is there a security threat? – Mark J. Bobak Mar 27 '18 at 14:56
  • 5
    The threat is that you're posting a secret key to a third party which violates a dozen of security best practices, nullifies the assumption of the key being "secret" and most likely violates your organization's security policy. In authentication all the remaining information can be guessed or derived from other sources - for example `Referrer` header in case of Google - and this is precisely why secrets should be, well, secret. – kravietz Jun 24 '19 at 12:12
  • 3
    And yes, you are also conveniently sharing the username (`Example:alice@google.com`) – kravietz Jun 24 '19 at 13:13

4 Answers4

58

The responses recommending usage of Google Charts are absolutely terrible from information security point of view. That's essentially sharing the TOTP secret as well as your username (alice@google.com) and issuer (Example) with a third-party company with no legal obligation to keep them secret, and doing that over a GET request! Doing so you violate not only every single assumption underlying multi-factor authentication but also most likely your organisation's information security policy. It nullifies any value added by MFA since the only factor that protects you from compromising your account in case of password breach is itself breached.

Just use any QR code generator as long as it's processing your data locally.

NEVER USE ONLINE QR GENERATORS FOR MFA SECRETS

On Linux I'd recommend the python-qrcode library that can print your QR code using UTF-8 characters on the console.

pip install qrcode

Then:

qr "otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example"

enter image description here

anothermh
  • 9,815
  • 3
  • 33
  • 52
kravietz
  • 10,667
  • 2
  • 35
  • 27
37

I use a different way using a local qrencode installation:

qrencode -o- -d 300 -s 10 "otpauth://totp/YOUR_IDENTIFICATION?secret=YOUR_SECRET" | display

In this way I can rebuild my lost authentication key library from what I had on my laptop.

If you are worried about the SECRET showing up in the bash history you can read the secret in hidden mode and use it:

read -p "Write your secre here (no output expected): " -s YOUR_SECRET
qrencode -o- -d 300 -s 10 "otpauth://totp/YOUR_IDENTIFICATION?secret=$YOUR_SECRET" | display

In this way, when you close the bash session, no trace of your secrets will available.

Zioalex
  • 3,441
  • 2
  • 33
  • 30
  • 2
    Take heed of David Thomas' answer below (which truly should be a comment here) to include `issuer` and also of https://gist.github.com/ragusa87/f9d82ca631df0d4d32a0 this script. – chx Sep 03 '17 at 18:03
  • 4
    This is much safer than using online generators. – Ber Mar 20 '18 at 16:01
  • 1
    Except this approach shows up in plain text via the command `history` in the Terminal. – Daniel Hallgren Oct 14 '20 at 18:10
  • 1
    @DanielHallgren you are right. An easy way to avoid this is to start the command with a space. – pgr Jan 21 '22 at 15:53
3

Just want to note, newer versions for Google Authenticator will use the issuer parameter, documented here:

https://github.com/google/google-authenticator/wiki/Key-Uri-Format#issuer

e.g:

https://chart.googleapis.com/chart?chs=200x200&cht=qr&chl=otpauth%3A//totp/User%2540Realm%3Fsecret%3DKO5DE2YD3Q2ZXEOO%26issuer%3DIssuer%2520Name&choe=UTF-8

David Thomas
  • 4,027
  • 3
  • 28
  • 22
-5

Warning: sharing your TOTP seed with third-parties breaks the very basic assumption of multi-factor authentication that the TOTP seed is secret.

Just figured this out.

As it turns out, I needed to encode all the special characters in the 'oauth', i.e., '$', '%', '=', etc.

So, using the same Google Charts URL as before, but encoding those characters, like this:

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/Example%3Aalice%40google.com%3Fsecret%3DJBSWY3DPEHPK3PXP%26issuer%3DExample

And it works correctly.

kravietz
  • 10,667
  • 2
  • 35
  • 27
Mark J. Bobak
  • 13,720
  • 6
  • 39
  • 67
  • 33
    downvoted because while this may solve the problem, this violates the whole point of adding an additional security layer by then sharing your secrets with unknown parties. No-one should do this. – masukomi Jul 01 '19 at 18:32