When I log into my Amazon account with a passkey, it then asks me for a 2FA code. The 2FA code is stored on the same device as a passkey, that step literally does nothing. After I do the 2FA code, it then prompts me to create a passkey. No! I have one. I signed in with one.
Some devices give me the option to use a QR code. I like that option usually, I can easily use my phone to authenticate. But sometimes i can’t get the QR code to appear. Support varies by OS, browser, and set of installed extensions. And there’s no easy way to control which of those three handles the passkey when something decides wrongly.
I had to troubleshoot something on someone else’s computer, and saw that they logged in to windows with a passkey and QR code. I’ve looked, and I can’t seem to set that up on my windows computer. There isn’t an option to and I have no idea why.
I recently moved to a new computer and it's just an AUTHHELLSCAPE.
Mine is Bitwarden, and that's available on pretty much all platforms, natively where available (except on macOS currently), as a browser extension otherwise.
For the rare instance in which I need to authenticate using a passkey on a computer where I'm not logged into Bitwarden, there's the cross-device CaBLE flow where I can scan a QR code with my phone and use Bitwarden to authenticate. This works across OSes and browsers.
It doesn't work for me in Firefox on Linux. I'm very curious to know how it works for you.
I would have naively thought that there'd be a better and safer API for it, considering that all browsers already have the infrastructure in place to handle login autocomplete.
The problem is whether or not the benefit outweighs the additional risks introduced — losing account access when you lose a device, furthering device lock down, difficulty transferring the passkey between devices, UX degradation due to bad implementation. In my opinion the answer is no and I am sticking with my passwords.
Unfortunately, it’s exactly those websites that I think would be unlikely to support passkeys at all.
Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain
Yes of course. Just like you do for passkeys.
> Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain
No, not quite. It's written on there:
> "Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...)
That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.
Some still might, e.g. for corporate or high security contexts, but I don't think it'll become a mass-adopted thing if things don't somehow drastically change course.
I saw passkey boosters go very, very rapidly from "Passkeys are immune to phishing!" to "Passkeys are phishing resistant!" when lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around.
You can't copy them out on at least the iOS, Android, and (to my knowledge) Windows default implementations.
> lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around.
Millions of people use them without being able to move them around in the way you describe.
Pardon? The official support docs disagree with you [0][1][2]. They absolutely leave the device.
Other passkey managers let them leave the device in a way that you control, but even the default ones copy them off the system they were created on.
[0] <https://support.google.com/accounts/answer/6197437?hl=en&co=...>
[1] <https://support.apple.com/guide/iphone/passwords-devices-iph...>
[2] Examine the "Can I use passkeys across multiple devices?" Q and its A here: <https://support.microsoft.com/en-us/windows/passkeys-frequen...>
Both Apple and Google have pretty elaborate ceremonies for adding a new device to an existing account in a way that synchronizes over passkeys.
When passkeys were first introduced, they were 100% stuck to the device that they were created. There was absolutely no real way to copy them off. This is when proponents were -correctly- making the claim that they were immune to phishing.
When lots of users (who -notably- were not supported by whole-ass IT departments who set up and run systems that handle provisioning and enrolling new devices) started using passkeys, the correctness of the thing that many non-boosters were screaming ("You have to have a way to back these up and move them between devices!") became abundantly clear. Passkeys became something that could be copied off of devices, and proponents -correctly- switched to the claim "Passkeys are phishing resistant".
Once things switched around so that passkeys were no longer stuck on a single device, third-party managers got the ability to manage and copy passkeys. [0]
Hopefully it's now clear that the shift from "they never leave the device" to "they do leave the device" (and the consequences of this change) is what I'm talking about.
[0] At least, they will for the next five, ten years until the big players decide that it's okay to use attestation to lock them out to "enhance security".
1. "Hi, I'm your bank, log in just like you normally do." (Passkeys immune.)
2. "Hi, I'm your bank, do something strange I've never ever asked you to do before by uploading some special files or running this sketchy program." (Passkeys just resist.)
The problem with the expansive definition is it basically starts to encompass every kind of trick or social-engineering ever.
> 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.
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".
Could you explain better?
>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.
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?
In fact, it’s not even meaningfully more secure than passkey (as passkey is designed) - passkey is, however, more convenient.
So it’s more ‘one weak factor + (really times) one medium/strong factor’ vs ‘one medium/strong factor’.
Which yes, the first one is better in every way from a security perspective. At least in isolation.
The tricky part is that passkeys for most users are way more convenient, meaning they’ll actually get used more, which means if adopted they’ll likely result in more actual security on average.
Yubikeys work well if you’re paying attention, have a security mindset, don’t lose them, etc. which good luck for your average user.
I don't think that's a reasonable assumption for most people, and you're screwed in that situation even if you use yubikeys.
If your password manager is itself protected by two factors, I'd still call this two-factor authentication.
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.
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.
This is not an issue on iOS, I can’t tell how what you’re describing could happen.
Usually I open it in Chrome but for some reason I didn't realize it was a webview this time
The problem is not with passkey rather system such as iOS keeps a tight lid on how files are uploaded and retrieved from the device. There is a real disconnect between desktop and mobile file system now days.
If it’s not, that’s a Bitwarden issue. 1Password shows up in the system UI regardless of context on iOS.
I keep asking what advantages passkeys offer over TLS self-signed client certificates. I haven't got any answers so far. Perhaps increase the security by encrypting the private key with a password or an external token. This is safe, like SSH and unlike regular passwords, because no secrets are sent to the server. TLS certs and (encrypted) keys are more tangible and easier to manage.
Perhaps passkeys do offer some advantages over TLS certs. But can't those be added to TLS, rather than rollout an entirely new system? The infuriating part is that this facility exists in browsers. They just let it rot to an extend that it's practically unusable. Meanwhile, Gemini browsers are using it quite successfully (for those who use Gemini).
Their only difference is the automated provisioning.
So they took something that works well and created a bad UX around it, while ignoring the working, yet languishing UI/UX that was already around?
Despite all their faults, for the average user, Passkeys are still miles ahead of GnuPG card, PIV, PKCS#15 etc.
Gemini strives to finish an entire request in a single transaction. So TLS certs are really the only option for authentication. That's how I learned the elegance of TLS client authentication workflow and started asking why this is so neglected in web browsers.
Not everybody trusts whatever first hop terminates TLS to also do authentication, and it completely falls flat at non-repudiation for transaction approval.
Despite all their faults, for the average user, Passkeys are still leagues ahead of GnuPG card, PIV, PKCS#15 etc.
If you try to describe how you _want_ the TLS client certificate UI to work, you'll end up with passkeys.
It's funny, we used to have a html tag that would exactly that: <keygen />
Even revealing the fact that a given passkey exists on your device requires your active confirmation according to the spec, so unless you actually want to authenticate and click the corresponding button, the site learns nothing about you (other than that your browser theoretically supports WebAuthN, which most do these days, so that's significantly less than one bit of fingerprinting data on you).
In other words, you can't be fingerprinted by WebAuthN, unless there's a (pretty severe) bug in an implementation.