I was reading your other blog post about storing them in bitwarden I have to disagree with this point:
> Unless you were forced to by some organisational policy, there’s no point setting up 2FA only to reduce the effective security to 1FA because of convenience features.
2FA both stored in your password manager is less secure than storing than separately, but it still offers security compared to a single factor. The attack methods you mentioned (RAT, keylogger) require your device to be compromised, and if your device is not compromised 2fa will help you.
To slip into opinion mode, I consider my password manager being compromised to be mostly total compromise anyway.
Also I really like the style and font of your blog.
> To slip into opinion mode, I consider my password manager being compromised to be mostly total compromise anyway.
But how is that no the entire point? If your 2FA is a proper device, like a Yubikey, the attack surface is tinier than tiny and the device ensures that your secret never leaves the device.
We did see cases of passwords managers getting compromised. We haven't seen yet a secret being extracted from a Yubikey.
So where you say you consider that your software (password manager) getting compromised is total compromise, we're saying: "as long as the HSM on a Yubikey does its job, we have actual 2FA and there cannot be a total compromise".
You're right, I should have been more clear in that I meant a local compromise of the machine running the password manager client, not the server running the password manager itself. If my sessions and all of my data can be intercepted, the yubikey 2fa seems like it's only saving me from a token "nobody can login remotely to this one service" which at that point seems pretty moot
Yubikey offers a false sense of security in that regard, unfortunately, because if your device is thoroughly 0wned and you don't know it, the attacker "just" has to wait for the victim to do something that would trigger the yubikey, and then swap in their forged request instead. Eg if the victim uses the yubikey to log into bank1 and to crypto wallet, but bank1 accounts have no money, instead of waiting for the customer to log into their crypto wallet with the yubikey, the attack software waits for the victim to log into bank1, but swaps in a request to the crypto wallet instead.
This isn't a footgun, you just have absurd security requirements.
>It should be pretty obvious that using a passkey, which lives in the same password manager as your main sign-in password/passkey is not two factors. Setting it up like this would be pointless.
You simply do not need two factors with passkeys. Using passkeys is not pointless, they are vastly more secure than most combined password+2fa solutions.
There are extremely few contexts where an yubikey would be meaningfully safer than the secure element in your macbook.
To be clear. Proper 2FA, via something like a smartcard or any truly external device is still much more secure. You could have one of those factors be a passkey, that's fine, and may be a good idea.
But there are UX issues with passkeys as well, that aren't all well addressed. My biggest gripe is that there is often no way to migrate from one passkey provider to another, though apparently there may be a standard for this in the works?
if 2fa is "use the second factor that's on same device as first factor" (like when using phone apps in many cases, password + 2fa from email/sms/authenticator app on same device), I disagree.
> It should be pretty obvious that using a passkey, which lives in the same password manager as your main sign-in password/passkey is not two factors. Setting it up like this would be pointless.
If your password manager is itself protected by two factors, I'd still call this two-factor authentication.
Passkeys can absolutely constitute two factors. At least the iOS and Android default implementations back user verification (which the website/relying party can explicitly request) with biometric authentication, which together with device possession makes them two factor.
That's not what two-factor means. Forget about passkeys -- if you use a password manager, and that password manager has a biometric lock, your accounts don't thereby have a biometric lock as a second factor. The transitive property doesn't apply here.
Someone gotta tell all these SaaS about that if so, because currently everyone is treating Passkeys as an alternative to 2FA. Take a look at how GitHub handles it for example when you use TOTP, they'll ask you to replace TOTP with passkeys.
They are an alternative to 2FA. Which means they aren't 2FA. If they were 2FA, they wouldn't be an alternative to 2FA. They'd just be 2FA.
Anyway, passkeys and FIDO broadly aren't the same thing. You can read the definition of passkeys at https://fidoalliance.org/passkeys/ or look at any of the marketing, which invariably talks about how great it is that you don't have to futz with passwords anymore.
FIDO credentials in general can obviously also be used as second factors. This is baked into the name of the original standard: U2F, Universal 2nd Factor. The specific point of passkeys though is that they're the single factor.
Many do what you describe, probably because some manager somewhere needs to tick some checkbox.
But GitHub, specifically, allows you to sign in with a passkey. On the sign-in page, there's a "sign in with passkey" link. It activates my 1Password extension, asking if I want to use my passkey. I say yes, and I'm in, I don't type anything. This also works the same way with my YubiKey.
I was reading your other blog post about storing them in bitwarden I have to disagree with this point:
> Unless you were forced to by some organisational policy, there’s no point setting up 2FA only to reduce the effective security to 1FA because of convenience features.
2FA both stored in your password manager is less secure than storing than separately, but it still offers security compared to a single factor. The attack methods you mentioned (RAT, keylogger) require your device to be compromised, and if your device is not compromised 2fa will help you.
To slip into opinion mode, I consider my password manager being compromised to be mostly total compromise anyway.
Also I really like the style and font of your blog.
> To slip into opinion mode, I consider my password manager being compromised to be mostly total compromise anyway.
But how is that no the entire point? If your 2FA is a proper device, like a Yubikey, the attack surface is tinier than tiny and the device ensures that your secret never leaves the device.
We did see cases of passwords managers getting compromised. We haven't seen yet a secret being extracted from a Yubikey.
So where you say you consider that your software (password manager) getting compromised is total compromise, we're saying: "as long as the HSM on a Yubikey does its job, we have actual 2FA and there cannot be a total compromise".
You're right, I should have been more clear in that I meant a local compromise of the machine running the password manager client, not the server running the password manager itself. If my sessions and all of my data can be intercepted, the yubikey 2fa seems like it's only saving me from a token "nobody can login remotely to this one service" which at that point seems pretty moot
Yubikey offers a false sense of security in that regard, unfortunately, because if your device is thoroughly 0wned and you don't know it, the attacker "just" has to wait for the victim to do something that would trigger the yubikey, and then swap in their forged request instead. Eg if the victim uses the yubikey to log into bank1 and to crypto wallet, but bank1 accounts have no money, instead of waiting for the customer to log into their crypto wallet with the yubikey, the attack software waits for the victim to log into bank1, but swaps in a request to the crypto wallet instead.
1 reply →
This isn't a footgun, you just have absurd security requirements.
>It should be pretty obvious that using a passkey, which lives in the same password manager as your main sign-in password/passkey is not two factors. Setting it up like this would be pointless.
You simply do not need two factors with passkeys. Using passkeys is not pointless, they are vastly more secure than most combined password+2fa solutions.
There are extremely few contexts where an yubikey would be meaningfully safer than the secure element in your macbook.
2FA is more secure than 1FA even if that one has a high security level
To be clear. Proper 2FA, via something like a smartcard or any truly external device is still much more secure. You could have one of those factors be a passkey, that's fine, and may be a good idea.
But there are UX issues with passkeys as well, that aren't all well addressed. My biggest gripe is that there is often no way to migrate from one passkey provider to another, though apparently there may be a standard for this in the works?
Are you saying that two weak factors are more secure than one strong factor?
2 replies →
if 2fa is "use the second factor that's on same device as first factor" (like when using phone apps in many cases, password + 2fa from email/sms/authenticator app on same device), I disagree.
1 reply →
Nonsense, depends entirely on the value of the authentication factor.
How is it not 2FA? It's MacBook + Fingerprint.
It's not 2fa if you assume some catastrophic exploit chain that allows an attacker to dump your macbooks secure element.
I don't think that's a reasonable assumption for most people, and you're screwed in that situation even if you use yubikeys.
> It should be pretty obvious that using a passkey, which lives in the same password manager as your main sign-in password/passkey is not two factors. Setting it up like this would be pointless.
If your password manager is itself protected by two factors, I'd still call this two-factor authentication.
Passkeys are meant to replace passwords. Not being second factors is the point.
Passkeys can absolutely constitute two factors. At least the iOS and Android default implementations back user verification (which the website/relying party can explicitly request) with biometric authentication, which together with device possession makes them two factor.
That's not what two-factor means. Forget about passkeys -- if you use a password manager, and that password manager has a biometric lock, your accounts don't thereby have a biometric lock as a second factor. The transitive property doesn't apply here.
1 reply →
And even a passkey on a phone that doesn't require authentication is immune to remote phishing and cloning.
Someone gotta tell all these SaaS about that if so, because currently everyone is treating Passkeys as an alternative to 2FA. Take a look at how GitHub handles it for example when you use TOTP, they'll ask you to replace TOTP with passkeys.
They are an alternative to 2FA. Which means they aren't 2FA. If they were 2FA, they wouldn't be an alternative to 2FA. They'd just be 2FA.
Anyway, passkeys and FIDO broadly aren't the same thing. You can read the definition of passkeys at https://fidoalliance.org/passkeys/ or look at any of the marketing, which invariably talks about how great it is that you don't have to futz with passwords anymore.
FIDO credentials in general can obviously also be used as second factors. This is baked into the name of the original standard: U2F, Universal 2nd Factor. The specific point of passkeys though is that they're the single factor.
Many do what you describe, probably because some manager somewhere needs to tick some checkbox.
But GitHub, specifically, allows you to sign in with a passkey. On the sign-in page, there's a "sign in with passkey" link. It activates my 1Password extension, asking if I want to use my passkey. I say yes, and I'm in, I don't type anything. This also works the same way with my YubiKey.