Printed next {HOTP,TOTP} at provision time is not usable

google / google-authenticator-libpam

Apache License 2.0

1.8k stars 286 forks source link

Printed next {HOTP,TOTP} at provision time is not usable #104

Closed mgorny closed 6 years ago

mgorny commented 6 years ago

When setting up, the google-authenticator tool prints:

Your verification code is XXXXXX

However, given that with the default settings the code is valid for no more than 30 seconds (and often less than that), it is quite unlikely for the user to manage to set the app up fast enough to actually see the same code. Ergo, the code can't be verified using it and it's useless.

I can think of two ways to solve this. Either:

the easy way: print a few successive codes so that the user would have a better chance of matching at least one of them.
the hard way: ask the user to type the generated TOTP code in to confirm it works (the way most of the sites handle it).

mgorny commented 6 years ago

Ok, I've actually looked into the code, and tested with the official Google Authenticator Android app, and it doesn't make sense at all. Apparently the code is generated for tm=0. However, in the Authenticator Android app I didn't see any option to see a 'verification code' at all.

FWICS, with HOTP:

FreeOTP generates another code first (i=-1?), then this one (let's name it i=0), then another (i=1),
Google Authenticator on Android starts with i=1 code immediately.

So with HOTP only the FreeOTP app let's you make use of the verification code, and only after the second tap (I haven't tested if earlier code lets you log in).

With TOTP the generate code has no relevance to the clock, so it makes no sense without a dedicated implementation supporting this special kind of verification code.

ThomasHabets commented 6 years ago

What are you asking for in this bug?

Reopen if you make this bug actionable. TOTP and HOTP certainly work and are useful.

mgorny commented 6 years ago

What I'm reporting is that I can't find use for 'Verification code' printed by google-authenticator. What I was asking for was printing something that could be actually used by the user.

ThomasHabets commented 6 years ago

Ah right.

I've just submitted changes that should hopefully fix this:

For TOTP: Ask for a code, confirm that it's correct
For HOTP: Inform of the next usable code (tm=1)

ThomasHabets commented 6 years ago

Left to do: add switch to suppress code confirmation, to ease automation.

ThomasHabets commented 6 years ago

You could already do "quiet" (-q) to suppress confirmation). But -C is coming soon to not need quiet.