[ulrikrasmussen]

In that case nothing based on RFC 6838 would qualify as a second factor because nothing prevents you from just remembering the TOTP secret and compute the one-time code using a piece of JS. Or even putting it in your password manager.

I think it is too simple to reduce the definition of second factor to how it is stored. It is rather a question of what you need to log in. For TOTP the client has the freedom to choose any of (not exhaustive):

1. Remember password, put TOTP in an app on smartphone => Client has to remember password and be in possession of smartphone.

2. Put password and TOTP in password manager => Client has to remember the master password to the password manager and be in possession of the device on which it runs. Technically, you have to be in possession of just the encrypted bits making up the password database, but it is still a second factor separate from the master password.

[charcircuit]

For proper 2nd factors the secret is a hardware key that practically can not be extracted so it is impossible for someone to know it. They must obtain the piece of hardware to use the key.

[fc417fc802]

Can't say I agree with this take. Sure, something hardware bound is more secure under certain threat models. For others it's largely irrelevant. There are also drawbacks, such as not being able to back it up. That might or might not matter. "Just" get a second hardware token, register that as well, and store it somewhere safe won't always be a realistic (or perhaps desirable) option for everyone in every scenario. It certainly reduces your flexibility.

[charcircuit]

If a factor is "something you own", it is by design that if you lose and no longer own it then you can't pass that check.

[fc417fc802]

Not true. There is no requirement that the user be incapable of cloning or recreating the possession. That's an additional constraint that some parties choose to impose for various reasons (some understandable, some BS).

In the end it's all just hidden information. The question is the difficulty an attacker would face attempting to exfiltrate that information. Would he require physical access to the device? For how long? Etc.

If the threat model is a stranger on the other side of an ocean using a leaked password to log in to my bank account but I use TOTP with a password manager (or even, god forbid, SMS codes) then the attack will be thwarted. However both of those (TOTP and SMS) are vulnerable to a number of threat models that a hardware token isn't.

[crote]

That's like saying "There is no requirement that the user doesn't tell their password to other people - all that matters is that the user remembers it".

The "additional constraint" is the entire point. You can't get rid of it without seriously degrading your security.

For example, a TOTP secret stored in a password manager will be leaked at the same time as the password itself when the password manager is compromised - which once again allows for impersonation by an overseas attacker.

And when you're using a password manager a leak on the website side is not a real threat, as yours is unique per-website and contains enough randomness to not be guessable if its hash leaks.

If anything, TOTP is the weaker factor here, as the website needs access to the raw TOTP secret to verify your code - which means a compromised website is likely going to mean its stored TOTP secrets are leaked in plaintext!

[fc417fc802]

> That's like saying "There is no requirement that the user doesn't tell their password to other people - all that matters is that the user remembers it".

... yes? I wholeheartedly agree with that statement so I'm really not sure what your point is. I have shared passwords with family members in the past. It works when it works and it doesn't when it doesn't.

> The "additional constraint" is the entire point.

I believe I already refuted that. Every practical implementation will have weaknesses. Being vulnerable to a greater number of attack vectors does not disqualify the method. All that matters is that the method works as intended for the attack vectors of interest.

I can bypass the lock on my front door by breaking a window. That doesn't mean that the thing on my front door doesn't qualify as a physical lock. It just means that my security model is vulnerable to certain attack vectors. That might or might not be a problem.

> You can't get rid of it without seriously degrading your security.

Whether or not my security is degraded depends on the extent to which the attack vectors the "additional constraint" was defending against are relevant to me. Writing my password on a post-it note and sticking it to my monitor degrades my security if the attack vector is someone breaking and entering my home. However it does not degrade my security even slightly if the only attack vector I care about is a stranger on a different continent illicitly logging into the associated account.

In general your thinking on this topic seems overly rigid and dogmatic. Security practices exist only to serve real world usecases. The expected attack vectors matter. So does user inconvenience. Something that is less secure but more convenient can often be the "more correct" solution in the real world. This is no different than how businesses will often choose to implement processes with well known flaws coupled with a response plan or insurance policy. For example shipped software often has bugs that were already known prior to release.

> a TOTP secret stored in a password manager will be leaked at the same time as the password itself when the password manager is compromised

Agreed. I went out of my way earlier to acknowledge the vulnerability to additional threat models.

> when you're using a password manager a leak on the website side is not a real threat

Well sure, but how are you going to get the vast majority of your users to use a password manager? They can always choose not to and there's approximately nothing you can do to reliably detect that.

You could mandate switching to a key based solution but then you'll get lots of complaints and maybe even lose customers. Or you could augment passwords with something else. TOTP is reasonable. So are SMS or email codes. Despite not being as secure or foolproof as a hardware token those solutions are sufficient for many scenarios.

[ulrikrasmussen]

Yes, that is certainly a more secure second factor since there are fewer ways for an attacker to steal it, but I don't think that should be a necessary condition for it to be called a second factor at all.

[charcircuit]

I'm specifically talking about the "something you own" second factor. There are other factors which could be used as a second factor.

[fc417fc802]

> I think it is too simple to reduce the definition of second factor to how it is stored.

I think the defining characteristic is how it is used. I can use a password like a second factor, and I can use a TOTP code like a password. The service calls it a password or a second factor because that was the intention of the designer. But I can thwart those intentions if I so choose.

Recall the macabre observation that for some third factor implementations the "something you are" can quickly be turned into "something your attacker has".

[Perz1val]

I put them in my password manager