Comment by ucarion
5 days ago
Six-digit verification codes for something like a "forgot password" flow are OTPs -- they're only good for one login -- but they are not HOTP/TOTPs. HOTP/TOTP has a registration step, where you copy a server-generated secret to your phone through a QR-code-encoded otpauth:// URI (https://github.com/google/google-authenticator/wiki/Key-Uri-...). That doesn't happen in a "forgot password" flow.
Incidentally, if you think of TOTP as being HMAC(unix mod 30, secret), one idea would be to do public key crypto instead of symmetric HMAC stuff. That's basically what a security key is.
If you additionally made it so that you couldn't phish the security key -- by having the OS + web browser know which apps can ask for which security keys -- you'd have reinvented WebAuthn.
P.S.: Make you sure you have stuffing protection in place against these kinds of six-digit-code auth schemes. A million possibilities is often acceptable for a secondary factor, but it's useless if attackers can just try all million codes.
Since they're in the thread, nice article 'dogacel! I've never seen an article on this that also took the time to dig into HMAC internals and that gnarly DT function.
Doing similar idea with asymetric cryptography is problematic due to the size of messages involved that are not exactly convenient to type. Lower bound for the signature size is going to be something on the order of 128bits if we include "weird" signature algorithms (ie. string that looks like MS Product Key), 240b for Schnorr with safe-ish parameters, at least 512b for anything widely accepted.
You can probably come up with something related to S/KEY (which was kind of a precursor to HOTP) that can be made to work with arbitrary sized one time passwords and is technically asymetric (and quantum resistant at that), but the security trade-offs involved in that and somewhat wild user registration step of S/KEY make HOTP/TOTP more sane choice.
All very valuable comments! Actually I had a small edit on the "forget password" flow.
I agree that an asymmetric key makes much sense. Secret key can be left at the user device while server only contains the public key. That sounds much more secure. I will dig deeper!
True about the stuffing proteciton, I actually want to do further reading on how TOTP is secured from random attacks. Statistically you are expected to crack 1 account in every 1 million attempts in 6 digits codes. Those numbers look pretty huge in the context of security, and a bot-net can potentially brute force couple hundred accounts every day.
> HOTP/TOTP has a registration step, where you copy a server-generated secret to your phone through a QR-code-encoded otpauth:// URI
RFC4226 and RFC6238 do not specify anything but the actual algorithm(s), which is exactly what OP implemented.
And many actual implementations work the other way around. Which opens the user to credential compromise but is much better user experience (and only one possible with several kinds of hardware tokens).
[dead]
Incidentally, if you think of TOTP as being HMAC(unix mod 30, secret), one idea would be to do public key crypto instead of symmetric HMAC stuff. That's basically what a security key is.
If you additionally made it so that you couldn't phish the security key -- by having the OS + web browser know which apps can ask for which security keys -- you'd have reinvented WebAuthn.
Another key part of FIDO2 phishing protection is challenge-response. The relying party sends some random material/nonce that the authenticator has to sign. This avoids replay attacks that e.g. a time-based method would have, since when a phisher tries to authenticate, the RP will send a different nonce and the phisher cannot sign it.