What is more secure for voice and SMS OTP: A random number or generated similar to HOTP?

Question

Many providers are creating OTP authentication for their sign in. However I noticed that all the voice and SMS OTPs I've come across are a series of 6 digits... similar to the HOTP RFC Standard emitted by Google Authenticator.

I see these six digit OTPs when:

1. Authenticating using a phone call (Google & some banks ...)
2. SMS to my phone (Facebook & Google ...)
3. Verifying an account through verified email address
4. Verifying my home address (Google Business, IRS strong authentication)

... namely any OTP that doesn't use a smart OTP token or device (YubiKey, Google Authenticator,Gemalto, etc)

Question

With regard to protecting the IdP that issues the OTP, what are the benefits and drawbacks of using a random number vs a seed like HOTP?

Here are how a few scenarios could play out if the one time password is stored in a database. One scenario is HOTP-style seed based, the other scenario is random number based:

1. If the (salted) password database is stolen/extracted, it's likely that the HOTP seed is stored in that same location. Datacenter security in this scenario relies exclusively on protecting the database & HOTP seed.

   The attacker would have the HOTP seed until that seed is reset, which is likely never.

2. Conversely, if the number is generated from random() and written to the database then there is no seed to compromise. The only way it could be exploited is if the attacker had real-time read access to the database.

From that quick outline it appears that seeded OTP (like HOTP) should not be used in these scenarios (voice, and SMS).

Is this a correct conclusion?

Answer 1

The tricky point is pre-usage synchronization. When you want to use a one-time password, the client must "somehow" learn the one-time password to use. HOTP is for situations where this out-of-band synchronization is through a counter which is maintained both client-side and server-side.

If you have another out-of-band mechanism which can be invoked on a per connection basis (e.g. a SMS), then you do not need the counter management that HOTP provides. HOTP is also a good PRNG, but it is simpler to generate random one-time-passwords from the OS facilities (/dev/urandom and its ilk). As you point out, HOTP is similar to a PRNG with a secret key, and key theft implies compromise. With a fresh random password for each connection, an attacker who can peek at the server database might learn the current OTP for a given users, but will know nothing about the next OTP, so the damage is contained in time.

Using HOTP (or its time-based variant TOTP) in the SMS-based scenario is not awfully weak -- this is a good model which supports user tokens. HOTP is sane usage of cryptography. But if you have an out-of-band channel available for quasi-immediate transmission of the OTP (such as a SMS), then you can use random generation which will be even better.