Passkeys for Infrastructure
goteleport.com
goteleport.com
* They effectively entrust the keys to your entire digital life to (right now) either Google or Apple. Account compromise, or a ToS-related suspension, becomes catastrophic.
* Domain changes happen (acquisitions, rebrands, etc.), and there is no way to share or migrate passkeys between domains. Right now the best you can do is a highly manual process involving the user authenticating on the old domain, registering a new credential on the new domain, and somehow linking them. This process itself could be highly vulnerable to interception, since every site would likely have to build a bespoke way of doing it.
* There's no way to migrate your passkeys between ecosystems. So if you're an iPhone user, and all your logins are iCloud Passkeys, it becomes really hard to switch to Android.
* Password-sharing is regrettably used a lot right now, but it's the simplest thing that works. For example, I and my husband have a shared 1Password vault for things like utility and streaming account logins. Right now none of the Passkey syncing providers support anything like that (and I feel like they won't, because it'd be a huge vector for scams).
I think the password is going to stick around until these issues are addressed.
Being tied to 1Password is better than being tied to iOS, but it's a far cry from real portability.
I don't see any indication that they are. If they don't plan to support exporting and importing into other ecosystems, then I would argue that their implementation is not portable. I would say that zacharyvoase's concern is still valid in that scenario:
> There's no way to migrate your passkeys between ecosystems
Within the Apple ecosystem Passkeys can be shared with contacts through AirDrop (no other methods are presently allowed). The Passkey is then copied directly from your Keychain to your contact’s Keychain.
The FIDO Alliance doesn't recommend that you migrate Passkeys, but instead, you have multiple passkeys across various platforms for the same "login".
See the following talk on this very thing: https://www.youtube.com/watch?v=SWocv4BhCNg
Backup is an orthogonal problem to migration, and it's really weird that the FIDO alliance keeps treating them like they're the same problem.
You're still looking at a scenario here where if you buy a new phone without any passkeys on it and it's in a different ecosystem, you have to manually migrate every single site you have an account with. That's a huge accessibility problem for ordinary people, that's absolutely going to hinder adoption.
I just checked mine, and it shows my Microsoft credentials and NVidia.
But I know for a fact that I also use it on Vanguard and BofA (which doesn't support keys on iOS in case you're wondering).
So I 1) cannot extract the masterkey from my YubiKey and move it to another one to make an exact duplicate 2) cannot discover the places where I registered my key
For SSH you can have a 'sk' key and a normal one [0]. I went with the normal one and moved it into the YubiKey, at least that way I have a backup sitting SOMEWHERE.
[0] https://cryptsus.com/blog/how-to-configure-openssh-with-yubi... (not affiliated at all)
Yeah this seems like a big one. Of course password managers will add support too but that isn't an actual solution since those often cost money and require extra effort on the user's part.
Part of me feels this needs to be legislation that requires tech companies to settle on a standard that works cross-browser cross-device. I imagine something like the EU's recent moves to force Apple to support USB-C could work well here.
What happens if someone invents a better interface than USB 3.0?
Or better, why would anyone bother when a better interface couldn't be used?
Meanwhile I'm sure a decade from now we'll all look back and say "Remember when we had to type _secret characters_ into a little box to log in to an app/site?"
Worst case scenario, you have multiple passkeys per service identity/web property, one in each sync ecosystem (if the relying party supports it). Still better than passwords! If your SSO provider does't support passwordless/passkeys, loudly complain to them :) Azure Active Directory supports it, I have worked with a team to implement it.
(great post btw to the Teleport folks, both content and visual appeal)
Agreed about a cryptographic national ID. One day! Login.gov is already prototyping using USPS for in person identity verification, we'll get there.
It's possible to approach the security of passkeys if you always use unique passwords per-site (with e.g. a password manager) but you're still then vulnerable to phishing unlike with passkeys.
Account recovery is still going to be a weak point here, and it's a kind of double-edged sword. If you're really strict about passkeys getting shared between devices or manually accessed, then users are going to lose access to accounts a lot, and recovery methods are going to get easier to accommodate those situations, which will in turn re-open phishing vulnerabilities.
On the other hand, if services don't implement those recovery options, then the first time a user gets burned with losing access to an account for a week, they're going to stop using passkeys, and broader adoption will be halted.
Yes and no. Passkeys are portable in the sense that Apple/Google have already compromised on the "keys should never leave your device" standard and have set up backup/restore options for if you lose your phone within their ecosystem. This is portability, but extremely limited portability. It's not portability in the sense of allowing you to migrate between ecosystems.
There is also some promise that passkeys will be portable between Google/Apple ecosystems in the future. The fact that the FIDO alliance refuses to build a client-independent way of moving between ecosystems and instead seems to be suggesting that migration should be handled with environment-dependent implementations severely limits how useful that portability will be.
Passkeys are also "portable" in the sense that you can register multiple keys with a single site. But this is not actual portability, it's just backup/replication. When you get a new device outside of the ecosystem, you can't port your passkeys anywhere. What you can do is register that device with every single site you have an account with.
This should obviously be seen as a barrier to the goal of replacing passwords entirely, but for some reason it's not seen that way. To understand the problem, we have to stop thinking of the current world where there are like 4 or 5 sites that have passkeys attached to them; you have to instead think of a world where passkeys won and a user has hundreds of sites with passkeys attached to them, many of which they might not have visited in nearly a decade.
And when they buy a new device, they have to migrate all of them. That's not portability, that is not something that a non-techie user wants to go through.
> you're still then vulnerable to phishing unlike with passkeys.
Extremely important to mention in these discussions, passkeys are phishing-resistant, not phishing-proof. We gave up on phishing-proof when Google and Apple started doing backup and restore within their own ecosystems. Your iCloud credentials can be phished, at which point your passkeys can also be phished by setting up a new iPhone.
Arguably, the Yubikey/dedicated-token approach was phishing-proof (for at least a somewhat narrow definition of phishing), but that's not the approach that mainstream platforms are going for. If you're using an iPhone, your passkeys already get backed up. That ship has sailed, the only fight remaining is whether or not you should be able to import them to something that's not an Apple device.
That said, Google/Apple/Microsoft aren't the only providers that can provide passkey support; the password managers are getting into the game too. 1Password already has a demo available, and Bitwarden has said they're working on it. I plan to use those when they're available rather than any of the big players, because they are cross platform (and Bitwarden is even FOSS).
> Extremely important to mention in these discussions, passkeys are phishing-resistant, not phishing-proof. We gave up on phishing-proof when Google and Apple started doing backup and restore within their own ecosystems. Your iCloud credentials can be phished, at which point your passkeys can also be phished by setting up a new iPhone.
Sure. You could get more specific and say the act of logging in with a passkey is phishing-proof, but access to the passkey "wallet" is not necessarily. That's still a substantial improvement though; to use 1Password as an example, I use it to log into things much more frequently than I set up 1Password on a new device (which involves a security key in addition to your master password). But the security of this is indeed dependent on the particular implementation.
It's a step in the right direction, but I worry that:
A) 1Password seems to be treating the problem as solved just because you can use 1Password on multiple devices. They haven't talked about migrating from 1Password to Bitwarden and back again.
B) As far as I can tell, this seems to be not a part of the spec at all. Correct me if I'm wrong, but it seems like the FIDO alliance is hoping that portability becomes more of a thing, but they're not willing to say "there should be a standardized API for this". And I think that's a huge mistake, saying that every platform will individually build support for every other platform (and that we'll hope platforms will provide these mechanisms in the first place) is a recipe for killing off smaller 3rd-party clients, because they just won't be supported.
---
> You could get more specific and say the act of logging in with a passkey is phishing-proof, but access to the passkey "wallet" is not necessarily.
That's a really good way of phrasing it; I think I agree there. And yeah, 100% agreed that it's a step in the right direction, I love the core idea behind Passkey, I think it's a massive step forward for security that's hindered by concerns around portability, attestation as DRM, etc, etc...
I think what I'm getting at mostly when I point out that passkeys are not universally phishing proof is that the massive increase in security and phishing-resistance does not go away if there's generic support for migration between services that any 3rd-party platform can hook into. Yes, it's a phishing risk, but it's a phishing risk we've already accepted. Having FIDO mandate portability between ecosystems as part of the standard itself wouldn't get rid of the security benefits you describe.
And I do get people telling me "there can't be APIs for this in the standard because it defeats the entire point, they're no longer phishing-proof"; but I don't think that accurately captures the situation at all, because we already compromised on transfer between devices, they're already not completely phishing-proof. So there could be transfer methods defined by the spec that providers who wanted to say that they're compliant would have to offer, and those transfer methods could have the same security requirements around them that Apple uses when restoring keys to a new iPhone. It doesn't need to be platform-dependent, there could be an open standard around this and it wouldn't ruin the security of the passkeys to have that open standard.
I suspect that even if FIDO doesn't spec out a portability standard, the smaller players might. There's no guarantee the big platforms will play ball, but even if they don't it'd still be useful to some people.
I'm not sure FIDO even could mandate portability if they wanted to, though. I suppose they could for certified implementations, but while I see Google on the list of companies with certified authenticators I don't see Apple or Microsoft... they're large enough that people will use whatever they implement regardless of whether it's certified. As far as I can tell it's not a requirement for implementation, and Microsoft and Apple have more name recognition than FIDO by far.
1Password is working on passkey support already (https://www.future.1password.com/passkeys/) and I imagine others will follow suit. Vendor lock-in isn’t part of the spec, it just happens that in these early days, the OS-level authenticators are the main ones implemented (as are other hardware authenticators).
In the mid to long term (e.g. by the time websites start supporting this), I don’t think vendor lock-in will be a problem. It’s no worse currently than chrome or iCloud Keychain being your password manager, which has been part of the landscape for a very long time. Like password managers, there will be other options. The benefit is that unlike passwords, there is a standard API for “autofill credentials” rather than using an extension to update the DOM.
I hope the FIDO alliance members come up with a solution that has both hardware backing and third-party vendors. I'd love to have 1Password syncing passkeys to Yubikeys or secure element that can be used independently of the 1Password app and subscription itself.
For what it's worth, it's not an inherent problem with hardware backed security, at least not in the context that I was talking about. If you were using pure software implementations of WebAuthn, you could also authenticate to that sync fabric only using WebAuthn and you'd have that exact same problem you're describing.
Still, they have a serious flaw: practically, you need a hardware device with you, and practically it will be a phone. I hate having to rely on having my phone handy to log into anything. What if I lose it? With a password I can log in from anywhere.
I feel like passkeys are a double-edged sword, like all of technology. On the one hand, they introduce new convenience and security, but on the other hand they make us even more tied to systems and devices. It's a lot of infrastructure that someone else has to maintain, and it's a single-point of failure in case you want to keep all your passkeys in iCloud, so you can migrate them to other iDevices.
We are crafting increasing complex systems with tighter and tighter integration into our lives and I think we need to be cautious of passkeys before accepting them so readily.
In short, there is no such thing as free convenience. There is always a cost, but we usually ignore that.
This isn't the case. Nothing about passkeys says you need your phone to login on a website with your laptop, for instance.
I would only ever use this if like my password manager the authenticator was software based (hardware independent), platform and vendor independent, open source, and offline.
Stackoverflow was cool enough that they could get away with trying something new, even if it made it much more difficult to get new users, but even they transitioned to the standard.
When you are trying to grow your company, don't make me think about the login, don't waste effort teaching me something pointless, let me focus using your product.
I think having an open sync fabric that is vendor agnostic will be important going forwards. Users have a multitude of devices, usually not from the same vendor, and hybrid transport is not enough to mitigate the fact that sync fabrics are not interoperable.
The risk is that password manager vendors will end up implementing virtual authenticators backed by software instead of a secure element like a Yubikey, Secure Enclave or TPM. I'd be interested in the the FIDO Alliance helping bring OS APIs to leverage secure elements to import and export key material that belongs to a particular third-party fabric. It's clearly a sensitive issue because establishing trust between devices, and thus a sync fabric, is a strong phishing target. I also speculate that password manager vendors (e.g. 1Password) and authenticator vendors (e.g. YubiCo) could mutually benefit from agreeing on some APIs to establish trust between authenticators and allow import/export, bypassing the OS vendors.
Let’s see how things unfold - passkeys in itself are an incredible improvement already.
Also please don't get me wrong, I don't want sync fabric establishment to be part of the WebAuthn or CTAP2 spec at all, but I do want a solution that both gives third-party sync fabric developers access to the hardware. It being a standard isn't strictly needed unless we're thinking of cross-fabric compatibility, which I think no one wants. It would certainly help with not messing up the implementation, though, but if that happens it should be something separate from WebAuthn.
Why are you saying that would be a risk? I want that to happen, so that I'd be able to back up my passkeys on my own terms.
But instead of exposing users that reuse their password across a handful of sites, you want to hand over the single master key to everyone’s digital life to the hackers??
I remain unconvinced that Regular Users will find passkeys as necessary/useful as the rest of the industry does, especially older users. Will be interesting to see how pervasive passkeys become.
This means that soon your logins will be tied to your ID.
Or did Apple manage to helpfully extend this standard into something requiring iWhatever accounts?
The only sites I don’t are the ones which don’t support more than 1 key.
I haven’t come across any websites that restrict it to just iOS. I’m not even sure it would be easy (without fingerprinting), because the browser usually handles verification (and gives options for security key and iOS).
I don't think the Passkey ecosystem is mature enough to be used as is, and I don't think it's good for us to naively accept that passkeys will get more portable in the future; there are multiple parts of the ecosystem that do not look like they're set up to move in that direction. Prove that they'll be portable, make them portable first. Make an implementation that works on my Linux devices and that won't immediately get blocked for failing attestation requests. Make a client that is Open Source where I can modify the code myself and use it in the real world without losing access to my keys. Then I'll pay attention.
The overall discussion and debate about passkeys also gives me a lot of doubt about them. There are comments in this comment section saying that FIDO keys and Passkeys are portable because you can use them with other devices. No, that's not what portable means. The fact that you can use your phone or hardware token to log into a website doesn't mean the credentials you have on that hardware token or phone are portable. You can't recompile the firmware on those devices and keep access to your passkeys. You can't move those passkeys between devices easily (you can one-by-one create new passkeys on other devices if they're supported, but come on, that is not real portability).
I don't have a lot of confidence about passkeys because I don't really see that passkey proponents understand the problems people have with them, and they're often extremely dismissive of those concerns. Yes, I understand that passkeys are on some level designed to be hard to port. Yubikeys don't have a backup/export option on purpose. But what I'm saying is that those design goals are incompatible with building a general replacement for passwords for ordinary people.
There's some really cool stuff with FIDO that I would love to love, but I just don't have confidence that the people involved in the standard understand what the criticisms are, and I don't see how it becomes a generally accessible standard when those concerns aren't addressed -- and in fact, when we start talking about stuff like hardware attestation, when we start getting into parts of the spec where migration between platforms is explicitly supposed to be platform-dependent -- those are actively harmful parts of the spec that should be rejected. They're not just "we haven't gotten to building it yet", they're bad decisions.
But I'm happy to change my mind. Give me a version of this that works on my Linux computers and give me a version of this that works on my Android phone running a custom De-Googled ROM. Give me a version where I can log into a computer that doesn't have bluetooth running, that doesn't require me to buy multiple 3rd-party hardware devices to handle log-in and backup, and that doesn't require me to manually update multiple keys for every single login. Show me that working on real sites and I'll happily change my mind about it. There's parts of FIDO that I do really like.
It's just that those good parts are not worth naively playing into a process that's going to end with making it practically impossible for people to exercise control over their own data and their own devices.
Tie everything to apple/whoever is pretty darn dystopian. And the "second factor" as described in this article doesn't exactly sound enticing.
https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration...
However Passkeys puts apple in a position of the Authenticator which is the riskiest part in terms of privacy.
A different authenticator is paramount but the question is how secure and private a self-hosted solution can be, with reasonable effort.
If you're more interested in WebAuthn privacy more generally, there's quite a bit of it in the WebAuthn specification itself, since it was an important goal of the design.
No, you can not. Because they are completely broken for a lot of use-cases, especially when you can only add one or two of them makes them worse than even passwords in many situations.