Provisioning codes for Google Authenticator

Hi PCFreak, hi Kris,

thanks a lot for this good point.

Choosing between totp and hotp is always also a kind of a matter of…
…believes.

If the secret key gets compromised, you have a problem.
Many people say, you already have a problem, when using HOTP.

In the past I saw users, who were handed an HOTP hardware token.
As these users were lazy but clever, they pressed the button a hundred
times, and wrote down all the OTP values.
They generated a “TAN list”. They could use this sheet of paper to login
with these OTPs, which they crossed of the list.

Such things can not happen with TOTP.

You are right, that - if the seed is compromised or copied on purpose -
there can be 2, 3 or a thousands copies of the token, without realizing
it. So it is harder to tell, if you are compromised.
In addition, the user himself could scan the QR code twice. Or have his
friend and colleagues scan the QR code. In some scenarios this is a
problem. When IT knows, that the users already gave their passwords to
their co-workers. They probably will also give the TOTP seed to their
co-workers. In this case HOTP would be a better choice.

Anyway, if I was the attacker and get hold of the HOTP seed, and my
latest OTP does not work, I am smart enough to try

HOTP(current_counter + 10)
HOTP(current_counter + 20)
HOTP(current_counter + 40)
HOTP(current_counter + 80)

And I will get a hit…
Nevertheless, the original user will realize, that his next OTP value
will not work - since I used it.
The question is, if the original user is smart enough, to think of the
possibility, that his token is compromised.

It is hard to tell. I personally prefer HOTP token, since I experience
it to be more robust.

Thanks a lot for your input and bringing up this topic
CorneliusAm Freitag, den 12.06.2015, 07:26 +0200 schrieb Der PCFreak:

Hi Kris,

I only would recommend to use event based otps (hotp) instead of time
based otps (totp) when you use software based otps.

Why?

Imagine someone is able to get a working and configured copy of a
software otp you deployed, then he/she could always use it because if
time based it always shows the same as the “original”.
When useing totp (event based), the otp is based on a counter which will
(if someone stole a copy of your app) not work if

a) the otp on the stolen device is “from the past”
b) the otp counter on the stolen device is too far away (usually
configurable on the server side) from the “original”

so you will detect if someone “stole” a hotp and used it because it will
fail sooner or later. with totp it will work like the “original”.

Maybe you already thought of this but I just wanted to mention.

Kind regards

PCFreak

On 11.06.2015 18:54, Kris Lou wrote:

  1. For some users that do not want to use their mobile devices, I’ll
    give an encrypted USB key with a provisioned Google Auth app
    (https://winauth.com/). I also have some users at an off-site
    location that is obviously more difficult to provision.

I realize that this is not a best case for 2FA, but thought I’d ask.
It seems like my boss goes through 3 phones a year.


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (819 Bytes)