0

I have seen many experts advising usage of some kind of OTP as second step of 2FA schemes.

I fully understand 2FA is more secure than Single Authorization, but it is also more inconvenient for a casual user.

What about replacing passwords with HOTP (HMAC-based One-time Password algorithm)?

We currently have schemes with strong passwords (not really so strong, current policy is: 8+ chars, mixed case, at least one numeric and at least one special) changed on regular basis and many users are already complaining.

I am wondering if replacing passwords with HOTP (possibly google-authenticator, supported by google-authenticator-libpam) would result in lower security than our present scheme.

Rationale is long random (generated) passwords will force users to write them down in some "handy" place, usually somewhere an attacker will find easily. Using [H]OTP would render this useless, while still being convenient as everybody has a smartphone on the desk, today.

Questions are:

  • Am I forgetting something important?

  • Is google-authenticator (or other OTP scheme) fundamentally flawed somehow?

  • If viable, what are pitfalls (if any)?

Note 1: I know multiple questions are usually badly received, but this really boils down to: Can I use this with reasonable security?

Note 2: We are not concerned with absolute security (as if such a beast would exist in the real world), but we wouldn't want to lower security level we have now either.

schroeder
  • 123,438
  • 55
  • 284
  • 319
ZioByte
  • 217
  • 1
  • 7
  • AIUI this is happening with FIDO2. Potential problems with doing it with existing TOTP: • you’d have to use a lot more digits, since if the number of options is low enough you either get brute-forced or have to implement strict rate limiting that probably allows an attacker to lock all of your users out of their accounts  • it’s probably more vulnerable to shoulder surfing – Ry- Sep 30 '18 at 14:40
  • @Ry- Care to explain better? I had HOTP (time based) in mind so even with low digit count (google-authenticator default is 6 digits) you have a 30s slot which, with the usual hold-back enabled, means you just have a few trials. I also fail to understand your reference to "shoulder surfing": getting hold to any (reasonable number of) successful logins won't help (much) to guess next required "pin". – ZioByte Sep 30 '18 at 16:21
  • To explain why 6 digits is completely broken: imagine you have a site with 100,000 users and unreasonably restrictive rate limiting (3 tries and your account and IP are both locked out forever) and windows (your clock + typing has to be in the same 30-second division for a normal attempt to be successful). If someone can make attempts on each account with a different address, they have a 26% chance of getting into one, which is *way* too high. – Ry- Sep 30 '18 at 17:21
  • Shoulder surfing = current authenticator apps just have the code sitting out there, so if you can see someone logging in you just have to log in faster than they do. (Have the ability to interfere with their attempt, if it helps, e.g. by disconnecting the internet.) Also in current apps: codes for everything being displayed at once, so you can log into an unrelated account. – Ry- Sep 30 '18 at 17:24
  • @Ry- Thanks for the explanation. HOTP, in our environment (Software development house, <100 accounts, often used by remote), still seems *way* more secure than current scheme (I often found valid passwords scribbled on scraps of paper "forgot" on desks)... and attacker has 40 days to use a stolen pass, not just 30 sec. Perhaps we could couple with normal pass when logging from unknown IP address. – ZioByte Sep 30 '18 at 18:14
  • Yep, normal 2FA sounds like what you need. U2F (/FIDO2) as an additional option, if possible. – Ry- Sep 30 '18 at 18:20

1 Answers1

1

Am I forgetting something important?

Yes. The HOTP scheme is not ment to be used as a single factor. You need to ask yourself, if the "possession" of a smartphone can be seen as a strong possession factor. When evaluating 2FA or - in your case - 1FA you should take a look at the possible attacks. One way @Ry already pointed out, being simply the odds/percentages.

Is google-authenticator (or other OTP scheme) fundamentally flawed somehow?

The google authenticator is not an OTP scheme per se. It is an implementation of HOTP and TOTP. Google combined a scheme that was defined in 2006 (RFC4226) with a QR Code (invented in 1994) and put it in smartphones, that have been there later. You should get the impression that OATH HOTP and TOTP was never ment to be used with smartphones.

The Google Authenticator has one major flaw (besides storing a symmetric key in an insecure device like a smartphone) being the enrollment process of a plain text secret key in the QR Code. I wrote a blog post about it a while ago.

If viable, what are pitfalls (if any)?

When doing 2FA (or 1FA with an OTP device) you need to carefully design your processes - enrollment, revocation, token replacement... You have done this with passwords. You defined the length and the contents of the passwords and the period when passwords need to be changed. You probably have a process to reset a forgotton password. You need all such processes, too, when doing 2FA or OTP authentication. The risk (or pitfall) is that you easily think - "oh I am doing OTP or 2FA, now - everything is good and better."

It is not, if you are not aware of your processes.

Community
  • 1
cornelinux
  • 1,993
  • 8
  • 11