From a practical standpoint, i dont really think it matters.

The real threat 2fa auth solves is the fact people blame the site operator when they are hacked. 90% of the time it is due to reusing a password. The other 10% it is due to phishing. WebAuthn stops both. 2FA works not because it adds another factor, but because it removes choice from the user so they can't screw it up.

Interesting take on 2FA. The user not being able to screw up is of course important, but the second factor (something you have) works primarily because it is tied to something physical and therefore local to the user, which is not subject to remote attacks.

Here's the concept. Perhaps we have the order wrong. Maybe the physical factor should be the primary factor. The second factor should never be transmitted, but rather is used to unlock the physical factor.

Requiring a password for a hardware key doesn't add much to the key already being in your pocket or locked in your house/office. It helps against an attack that's specifically targeting you as a person but it's basically just a nuisance for you when considering generalized account attacks.

Not really part of what you said but this just caught my attention and I thought I'd ponder about it in public a bit.

We used to think that

> It helps against an attack that's specifically targeting you

would be sufficient, because, like who cares about little old me? But in the era of API intelligence, setting up a specific agent to target every person seems automatable.

If all that was missing before was a sufficiently-motivated attacker who would learn about you and your patterns, and that couldn't scale because we didn't have enough dedicated bad guys, that seems like it's a bout to change pretty quick.

Don’t most people that this this “correctly” use a password manager which stores passwords on the same device as stores the totp token and generates the one time code? Doesn’t this effectively turn your password into a device that you have, effectively turning the first factor (something you know) into something you have, while the second factor (something you have) is the same thing you have from the first factor (your phone)?

Even people that do this incorrectly and reuse passwords, probably also store their passwords in their browser, which is on the same device as their authenticator app. So I would guess by far majority of people are only using something they have twice.

That’s the trade off being made for convenience. It’s still somewhat multifactor though (I’ve seen people call it 1.5FA); authentication codes have the benefit of being resilient to replay. So, you’re not pwned even if someone steals your password somehow.

Even if someone steals your phone, you should have a passcode. If they know or guess your passcode, well… someone could steal your house/car keys too, and we still carry them around anyway :)

If we are assuming that the password manager is on the same device used to login, a replay attack is bordering on rediculous.

In this scenario, you are assuming that the client is not compromised (since otherwise they would just steal it before you use it) the server is not compromised (otherwise what is the point), you do not have an active mitm (otherwise they could use the token directly instead of replaying).

All that really leaves is you have someone capable of passively eavesdropping a TLS connection (usually much harder to do than active mitm). I suppose someone literally looking over your shoulder or recording you with a hidden camera - but even then they just have to out-race you hitting submit.

Anyways. Not a realistic threat in my mind.

Sorry, I meant replay really broadly because I could not come up with a better term in the moment. For example, a password can be leaked in many ways (guessed, by a breach if the website has poor password storage, etc) and be “replayed”, as in the attacker just enters the password themselves. A code does not have that problem because it is temporal.

Ah ok. Its confusing because one of the requirements for time based one time password 2fa is that if you use the same 2fa token twice,it is still supposed to reject the second one even if it is in the same time window.

On the server side usually a "key" is stored, which for TOTP based 2fa would allow the attacker to create future 2fa tokens if they got ahold of the key. So what really saves you is the website choses the key not the user, meaning every website has a different one. Not the temporal nature.

Anyways, usual term for what you are referring to with reusing passwords is "credential stuffing".

I'm not sure about "most people", but I for one never stored 2FA tokens on the same device as my passwords. My password manager is only on my desktop/laptop, and my 2FA tokens only live on my smartphone/Yubikey.

Storing both on one device sounds like a pretty stupid thing to do. Sure, it's convenient, but you are putting a looooot of trust into the assumption that your single device will never be compromised.

How do you enter a password on your phone than? Do you manually type them after you reveal them on your desktop machine?

The average user is not typically subject to remote attacks. There are exceptions of course. However we should design the default security experience for the threats the average user faces. Most users aren't being targeted by the NSA, etc.

Unless you mean the webserver they use being attacked, but that is just as vulnerable for 2fa. The only difference is the user cannot screw up and use the same credential on multiple websites with 2fa.

The average user isn't targeted personally, they are targeted en mass, the more people fall into the category, the more valuable target they become. A personal attack is needed only if the credential storage is not standardized.

Remote attacks (e.g. say having a zero day in the sms messenger app. Not talking about remote in the sense of phishing emails are sent remotely or when attackers target service providers instead of users) typically get noticed and fixed really fast if they are used en masse. In practise it is much more common for attackers to pick specific targets in order to preserve how long their vector lasts for.

Be careful to not lump all 2FA together: only FIDO2/webauthn second factor is immune to phishing.

evilginx will happily steal most other 2FA (TOTP, ...).

On Apple platforms, a biometric authentication is required to proceed with webauthn, so technically it is 2FA (something you have and something you are).

Which is awesome, but worthless, if others don‘t follow.

Well all the major browsers are on board—it’s really in the hands of the dev/product community now.

Ok, i thought that only Apple uses biometric ID. Then: it‘s just awesome.

WebAuthn to either a a hardware key protected by a pin, or to a passkey protected by a biometric. Both definitely qualify as 2FA

But there is no password, so we are back to 1FA, with Passkey being the single factor.

This is similar to using password manager, with the exception that malware cannot steal your keys ... however, if it's able to steal passwords from password manager, there is a good chance that malware can also access your browser's cookies.

It is still 2FA. Something you have (passkey on a device) and something you are (LIDAR map of your face and pulse).

Some people, who are not me, say that it's still two because they have to have the device but also have to be able to unlock the device.

That makes sense (as long as device asks for PIN every time you use webauthn). Bank card uses the same logic: you present both card and PIN code and it counts as two factors.

Devices get snatched out of hands all the time.

Even if they snatch it unlocked they still can’t login because there’s an extra biometrics check required for WebAuthn

In at least Apple's case, Device PIN is also a factor to unlock the secure enclave where the passkeys are kept - so, assuming there's no stronger enforcement that it must use FaceID/TouchID, shoulder surfing a PIN unlock of the device and then swiping it grants access to all accounts.

I have heard arguments that using a password locked ssh key is two factor authentication for the same reason, that is, what you have(the ssh key) and what you know(the password to unlock it)

However I am not convinced, I think it comes down to dependency of factors in the auth scheme, if one factor unlocks another factor there only really is one factor, all factors must independently lock.

The "something you have" shouldn't be easily replicated. If someone could capture your SSH key passphrase and copy the ssh private key then it's not an actual 2FA. a device like a Yubikey won't let you extract the stored keys, so the only way to gain access is to steal the physical key and that makes the attack much harder to do stealthily.

I currently authenticate with my fingerprint to 1Password, which then autofills a random password and an OTP code. That fulfils my security needs, and I'm unwilling to migrate to something harder to use.

Nearly everyone I know has less tolerance for annoying security than me, so I don't see how WebAuth can possibly succeed.