Behind the 6-digit code: Building HOTP and TOTP from scratch

It would be, but you could still store an expiration time, and limit the number of attempts to use the code. Considering you're probably sending it to the user insecurely anyway (via email or text message), that's probably safe enough.

Thanks for all your insights, I have updated the post to outline this as a "theoretical" use-case rather than a practical one. I also revised it to include random number approach.

Perhaps you could also highlight how in usual TOTP implementations (“scan this code with your authenticator app”) there’s no channel to MITM? I think it’s one of the key pros of TOTP vs, say, SMS as a second factor.

I haven't mentioned MITM attacks in this article thoroughly. Can you give some examples on what authentication implementations carry a MITM risk?

I thought anything carried over SSL doesn't have a _significant_ MITM risk.

Not sure about emails (probably reasonably secure, I think most MTAs use TLS now).

For text message codes though, there’s plenty of attacks. In authoritarian regimes, government can monitor your text messages directly – I think some protestors in Belarus have lost their Telegram accounts due to this. There’s also the SIM swapping attack, where an attacker pretends to be you and ports out your number: https://en.wikipedia.org/wiki/SIM_swap_scam

> > storing that random number is similar to storing a plain-text password

> you could still store an expiration time, and limit the number of attempts to use the code

Storing plain-text passwords is bad because:

1. Users re-use passwords

2. An attacker can read the access token from the database (as with SQL injection) or capture it in transit (as on insecure connections) and log in directly (if that is still useful when having, e.g., SQL-injection-based database access)

I do not understand what threat limiting the number of attempts protects against. Even if you have that limit implemented on a hardware level, the attacker either knows the right code or can crack the hash if it's a hash of just a few digits. With something like PAKE you can protect against capturing in transit but on secure channels (e.g., if you already use TLS) that's typically overkill

(Of course, you absolutely need to have rate limiting on OTPs, but that is not to protect against the correct code being read straight from disk by the attacker; it's to protect from guessing the digits, a surprisingly common flaw)

> you're probably sending it to the user insecurely anyway (via email or text message)

(I kind of want to remark about this assumed insecurity: the user needs to be targeted for these to not be adequate. Attackers very rarely go after people to the point where they first compromise an email inbox and then look for your specific service, or drive up to the person with cell tower spoofing equipment. It surely happens in red teaming exercises, spy scenarios, if you have a stalker, and probably more, but it's not the common case. Anyway...)

I don't see how rate limiting and expiration helps against sending it via moderately-secure media either. This is necessarily plain text for random codes because the user would otherwise need a decryption key and then you're basically back at the TOTP scenario makes a difference for at-rest storage security. So with them being plain text, if someone is intercepting your SMSes or sitting in your inbox, they'll either manually trigger the code sending or wait for the legitimate user to do this and then log in. Similar to the previous bit: sure, the security of the transport method is relevant, but not for the security of token storage on the server