[vbarrielle]

The idea is interesting, but I don't think this qualifies as a second factor, as it can be reduced to a factor you have to remember, so equivalent to a password. The second factor should be derived either from something you own, or something that can be obtained from biometry.

[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!

[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