A little off-topic from the matter of adoption and usability by the greater masses, but I personally prefer these RFC 6238 TOTPs that I have the choice to take into my own hands, as opposed to internet-required, server-side based like my banking app and Okta.

I have a copy of all my TOTP generators (minus my dev Okta account) in a common authenticator app and an offline copy stored in an offline password manager, further replicated with an encrypted backup service.

I was able to create my offline copy in the first place thanks to a rooted phone to export what I already had up to that point out of the authenticator app.

Of course, the discussion starts to morph when we bring in the "un-phishable" software passkeys.

I thought the Authenticator apps were great until I upgraded my iPhone and the apps lost all of my Authenticator setups. Good thing it wasn’t super critical.

I agree, for personal use cases, RFC standard TOTP that can be backed up and managed by the user is the ideal balance of security and availability.

Enterprise TOTP apps like Okta and MS Authenticator have some enhancements. Push notifications are convenient when you have to access things many times a day. More importantly, push notifications with a number-matching confirmation reduces the chance of TOTP poaching, since the user themselves are interacting with the service requiring auth.

In enterprise environments, there should be a restore process for a lost phone or authenticator. Some kind of backup code with voice/manager approval, or coming into a physical office to reset credentials. This isn't available for regular people/regular retail services except maybe banks, but banks can't even do regular TOTP correctly.

> To add insult to injury, MS Auth can only have one account per email address (id@realm/whatever you want to call it)

When this was discussed [1] on HN a few weeks ago, I don't recall anyone reporting reproducing it. Several people, including me, reported having many accounts in MS Authenticator that have the same email address with no problem.

The otpauth URI that is encoded in a TOTP QR code looks like this:

otpauth://totp/LABEL?parameter_list

The LABEL is supposed to serve as a unique identifier for the account. It has the format "Issuer:Account". The "Account" part is required. The "Issuer" is optional (and the ":" omitted if the issuer is not present).

The parameter list is an & separated list of name=value pairs. It includes the "secret" parameter which gives the TOTP secret. An optional parameter is "issuer", which should match the "issuer" part of the label if that is present.

It sounds like what is happening is that there are some sites who do not include the "issuer" part the the label, and they let the user use a user provided email address as the account name.

If a given user uses two such sites and provides the same email address to both, then there will be a collision. If they also do not include an issuer parameter an authenticator app has no way to know just from the data in the codes that they are from different sites.

[1] https://news.ycombinator.com/item?id=41275846

I'm increasingly coming around to the idea that in reality, there's only one factor, at least as far as the Internet is concerned: Something you know. There's different ways of knowing it and various difficulties involved in knowing it, but "something you are" is only every a fancy way of presenting something you know (because if you know it, you can generally forge it with reasonable effort) and "something you have", over the Internet, is just "something you know but is pretty difficult to directly extract".

TOTP was what really kicked me into thinking this way. They tried to make it "something you have". They tried to lock it behind apps and pretended really hard that it wasn't just a particular shared secret... but it is. It's just something you know.

The rule is, if it could be stuck in your password manager, it's a thing you know. That includes even things like Yubikeys, which are things that can be cloned and stuck in a password manager. They're just really, really hard to clone, and that's a valid step up from "a password". I'm not saying that the differences between all these "things you know" are irrelevant; they matter a lot. Having a password + a TOTP is a legitimate step up from having just either one alone. I'm just saying that analyzing things in terms of the other two factors isn't particularly relevant.

I don't think this is right. If there's a shared secret like a TOTP seed, that's in theory a "something you know", but if I don't know it, then who does? The point of "something you have" is that you own a device that "knows" it for you, and you never even need to see or expose the underlying secret, you just copy a token proving that the device you have knows the secret. I think that does count as an additional factor.

Of course if someone is memorizing the TOTP seed and generating the proof on the fly every time, then there's no shift in factor, but no one is doing that. And if they're saving the password on the same device that stores the TOTP code, then we're back to one factor, but now it's just 2x "something you have" at that point.

"that's in theory a "something you know", but if I don't know it, then who does"

An attacker. Your knowledge is much less interesting that the knowledge the server has, which is what the attacker can obtain. Grabbing a TOTP key out of a database is not materially different than a password.

TOTP's different characteristics mean it's harder to intercept, but passwords tend to be stolen nowadays moreso than intercepted, if only because you can intercept only one at a time but can steal the entire database.

The different characteristics mean it can add a bit of utility to a normal password, but I think it's less night-and-day than it was presented as.

> That includes even things like Yubikeys, which are things that can be cloned and stuck in a password manager. They're just really, really hard to clone, and that's a valid step up from "a password".

That's reductionist way past the point of being a useful model of authentication factors.

By that logic, even biometric factors are "something you know", as you can always (with a lot of effort) physically replicate a fingerprint/retina/genome you have a sufficiently high fidelity recording of.

"By that logic, even biometric factors are "something you know","

You clearly mean that as a reduction to absurdity, but, yes, I mean exactly that. Pretty much said so.

It is "reductionist" if you insist the only valid framework is "what have have/know/are", and you view what I'm saying as the intersection of what I'm actually saying and that model. I am claiming the have/know/are is reductionist, and to a large degree outright wrong, because it is focusing on the wrong thing. Look at it the way I'm looking at it and the authentication questions become richer and easier to understand.

Unfortunately, it also means that there's more things that are either hard or impossible than the have/know/are methodology promises, because two of the things that methodology promises effectively don't exist. (Unless you are controlling physical access, and willing to spend a lot of money on hardware and human verification of the correct use of the hardware.) But since I believe that is an accurate reflection of reality, blame reality, not the model.

I suppose then we have to agree to disagree.

While the "something you x" model has many limitations (and I practically disagree with some regulatory bodies on what does and does not constitute a "true" expression of one of these factors), I don't think that these limitations refute it in the abstract.

The way I see it, the main security benefit of TOTP is it's a very long, high-entropy password that is guaranteed to never be re-used.

Yes, if you don't control the hardware at the user's end, the only factor you can get is "something you know".

All the things around improving web authentication are just about people not having to memorize that something you know and protecting it against eavesdroppers.