Alternative for RFC 6238/4226 - one time password via SMS (single-factor authentication) 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:


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


We could use the following code to create a OTP


Generate random (secure) bytes
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.
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.