1

i have two question about the "(H)OTP algorithm" regarding a security issue.

We all know how "TOTP" works, we scan a qr code and every 30 seconds a new 6-8 digits code gets displayed, almost no magic.

Now back to "HOTP", in addition to the payload from "TOTP" we also get a "counter" value.

Is it safe to display the counter value on the client side? Or does it cause any security issues?

And a general question: Is the "secret" value always 16 digits? (I am asking because i saw mfa-applications accepting less than 16 digits)

Thanks!

Steve Vinoski
  • 19,847
  • 3
  • 31
  • 46
Creative crypter
  • 1,348
  • 6
  • 30
  • 67

1 Answers1

3

Question the First: Is it safe to display the counter value on the client side?

The "counter" is not a secret. While the "secret-key" remains secret, knowing the the current or a recent "counter" value is of no use to an adversary. If the "secret-key" is compromised, then you are in trouble. RFC4226 says a lot about keeping the "secret-key" secret, and nothing at all about keeping the "counter" secret. (And with TOTP, clearly it isn't !)

If an adversary does learn the "secret key" and the "counter", they are in. If they have to guess, and the 8-byte "counter" is randomly seeded, then this starts to look like a brute-force attack. Section 7.1 of the RFC, gives requirements for the authentication protocol P, including:

RP2 - P SHOULD NOT be vulnerable to brute force attacks. This implies that a throttling/lockout scheme is RECOMMENDED on the validation server side.

so there is some additional security in keeping the "counter" securely, but neither the client nor the server is required to do so. And even if the client does, the server might not. And that's not part of the formal security analysis.

The "E.4. A Counter-Based Resynchronization Method" (of the RFC) requires the client to send their "counter", and we have:

RP3 - P SHOULD be implemented over a secure channel in order to protect users’ privacy and avoid replay attacks.

...no mention of securely sending the "counter", except as a side effect.

So, the short answer to your first question is "yes", "yes it is safe to display the counter value on the client side" -- where by "safe" we mean "safe while the secret-key remains secret".

Question the Second: Is the "secret" value always 16 digits?

I'm guessing that this refers to the "secret-key", also known as "shared secret" -- so by digits you mean bytes ?

The RFC section 4, "Algorithm Requirements", includes:

R6 - The algorithm MUST use a strong shared secret. The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits.

So a "secret" of less than 16 bytes is not conformant.

Chris Hall
  • 1,707
  • 1
  • 4
  • 14
  • Hey just one more question. So anything greater than 16 bytes is ok? Because i just saw that google authenticator accepts all secrets where the length is "length % 8 == 0". So it will also accept a secret with length 8.. does it conform to the specification? and is there a max length like 64 ? – Creative crypter Apr 26 '20 at 17:16
  • The Shared Secret is fed into SHA-1 HMAC. SHA-1 blocksize is 160 bits, so a shorter Shared Secret will be zero extended to 160 bits, and a longer one will be run through SHA-1 to "compress" it to 160 bits. So, on the face of it, a longer Shared Secret does not add much. Mind you, if you have a low-entropy Shared Secret, then the longer the better... though you could hash that yourself down to 160 (higher-entropy) bits. Far be it from me to comment on Mr. Google's code... I note that `length % 8 == 0` would by itself also accept `length == 0` ! Are there other checks on the `length` ? – Chris Hall Apr 26 '20 at 18:22
  • Lets say the provider(e.g. google authenticator) allows for sha1, sha256 and sha512. What would be a good validation rule for the shared secret? Only 16 bytes? 16, 20 and 24 ? – Creative crypter Apr 27 '20 at 17:21