9
$\begingroup$

Currently we have implemented One Time Passwords (OTP) as second authentication which works well. We use TOTP - RFC 6238

Some clients would like to have a "sms only" login, so it's single factor authentication. In the some cases (dependent of the data) that is fine. We will send the token via SMS and it won't have to be OTP-app compatible (e.g. Google Authenticator)

To our opinion the RFC 6238 (TOTP) is too weak for single factor authentication as the time component gives issues:

  • If the password is 30 seconds long, two login attempts in the the 30 seconds period will give the same password
  • If we change the time to 1 sec, we have to check multiple "frames"
  • Also, alphanumeric characters in the password isn't compatible with the RFC?

We are also aware there is a counter based algorithm (HOTP - RFC 4226), but their could be security issues if we won't sync the counter correctly (between servers).

So we are looking for a RFC to generate one time passwords with the following requirements:

  • Generate passwords, time based, no counter
  • Generate passwords with alphanumeric and numeric characters

The flow will be:

  1. Generate OTP
  2. Store the password in (server-side) session (including expiration)
  3. Check the token and clear the session.

We could use the following code to create a OTP

  1. Generate random (secure) bytes
  2. Convert to text

But that isn't compliant to a RFC, and RFC-compliance is preferred.

My questions:

  • Is there another RFC we could use that satisfies the requirements?
  • Are we RFC 6238 compliant if we: generate the TOTP with a short time (e.g. 1 sec), and store the result in session.
$\endgroup$

migrated from security.stackexchange.com Dec 8 '16 at 10:48

This question came from our site for information security professionals.

  • $\begingroup$ What "session" are you proposing to use to temporarily store the OTP? Is this just a server side record that is checked against what OTP the user enters? I'm also not sure what you're trying to accomplish with the 1 second time change. That seems too short for a user to receive a SMS OTP, enter it in your app, and have it validated. $\endgroup$ – PwdRsch Dec 7 '16 at 16:24
  • $\begingroup$ yes server side session. The second will work, as we don't support the a OTP app with "sms only" (only send sms) $\endgroup$ – Julian Dec 7 '16 at 16:24
  • $\begingroup$ I'm not sure I'm following the 1 second period, as that's way too short to be realistic if the intention is to reliably transfer the OTP via a public GSM network within that period, let alone the time it would take for a normal user to read and enter even a one-character code. $\endgroup$ – Gwyn Evans Dec 10 '16 at 10:41
  • 1
    $\begingroup$ SMS is not secure. A foreign ISP can impersonate you. To be rather complex, someone can hack a foreign ISP, impersonate you, and obtain a login credential. At best I suggest a smartphone app that uses public key infrastructure for authentication. $\endgroup$ – user3201068 Dec 12 '16 at 20:58
  • 1
    $\begingroup$ @otus yes, but if you detect a race condition, it should force a log-out. Regardless, computers are faster than people, so security based upon time delays will only hinder people. $\endgroup$ – user3201068 Dec 14 '16 at 23:40
3
+50
$\begingroup$

Assuming I have understood your requirements correctly, my recommendation would be to use HOTP but with a session key.

  1. The user enters their username in the client, which is sent to the server.
  2. The server generates a random salt and sends it to the client.
  3. The server generates and stores a session key, derived from the long-term key and the random salt (e.g. using HKDF).
  4. HOTP with the session key is used to generate a one-time password which gets sent over SMS.
  5. The client sends the random salt and the one-time password that the user has entered.
  6. The server verifies that they match the session key it has stored.

Since the one-time password alone is insufficient for logging in, it should be more secure than simply sending a token over SMS. Half the secret is sent over (hopefully) TLS and stored in the client cache (whether web page or app), so someone intercepting the SMS only would be unable to log in.

There is no time step. You can choose whether to store only a single session key per user or any number if simultaneous logins are required.

Note: please take care to associate the session key with the correct user so that the client cannot use the salt+OTP to authenticate as someone else.

$\endgroup$
4
$\begingroup$

From a security standpoint it is not necessary to reduce the time interval to one second. Your implementation has to assure, that there will be no second login attempt in this time interval. I recommend to save the latest timestamp and during authentication verify, if enough time has passed, and only then create a new TOTP value and send this via SMS. This is also, what the TOTP RFC recommends.

Also, the RFC says, that you should use 30 or 60 seconds time intervals. You should ask yourself: how often will the users try to login?

alphanumeric

The original OTP algorithm by Lamport creates alphanumeric values. But the problem is, that the use case for the lamport algorithm was a bit different. In my opinion the orignial intend was not to introduce a second factor but to disallow replay attackes.

It is a challenge response algorithm. I.e. you have to make a challenge all the time, you could calculate the response and save the response in the session and send it via SMS. But you also need to assure, that you really create different challenges.

TOTP alphanumeric

The thing with the HOTP and TOTP algorithm is that they were defined by hardware vendors to provide a second (possession) factor. This is probably why the output is ment to be digits and not alphanumerics. digit LCDs are cheaper and digits are easier to display than alphanumerics.

But you could however change the truncation algorithm to generate hex strings or some kind of alphanumeric values. The 6 digits or 8 digits is just a transformation from a sha1 output. You can also convert the sha1 ouput to lets say to 10 alphanumeric characters. See https://tools.ietf.org/html/rfc4226#section-5.3

OCRA Algorithm If you want to be absolutely RFC complient you can take a look at the OCRA Algorithm, which is the third member of the three musketeers HOTP, TOTP, OCRA. This RFC officially allows you to define the truncation function and even skip the truncation completely: https://tools.ietf.org/html/rfc6287#section-5.2

But honestly running the OCRA add some layer of complexity. I probably would go with HOTP and a modified truncation method.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.