Passkeys and Modern Authentication

The name of the issue reveals the actual problem: "should never be exported in clear text". If the export was encrypted with a passphrase in a standard format, then there would be no issue. It's specifically doing it in plain text that causes consternation. Of course, in practice it doesn't make much of a difference when users are incapable of choosing secure passwords, let alone passphrases. But requiring exports to be encrypted is the least one can do to maintain a degree of security while still allowing exports.

> For many years already, people lose access to their Google account every day and can never regain it. Google is well known for terminating accounts without stating any reasons. With that comes the loss of access to your data. In this case, you also lose your credentials for third-party websites.

In practice this is frequently already true. Many sites require an email to sign up. Whenever you attempt to log in on a new device, they require you to type in a code sent to your email. Without access to your email, you cannot sign in.

No exporting really is a feature. Otherwise people would be tricked into giving away passkeys much like they are with passwords today.

You can always register multiple passkeys with providers though. Already have a passkey with google but want another one via a different password/account manager? Just go into settings on google and add it! This is effectively how you’re meant to move passkeys around. Create a new and register that with the same services as the old one.

The real hassle right now is remembering all the services you attached your current passkey to so you can register a new passkey with them and it’d be nice if there was something similar to ninite installer for passkey registration. But still it's not a huge blocker. You can absolutely use multiple passkeys and login with any one of them.

I am sympathetic to the intent but the words of Patrick Henry come to mind too often in conversations like these. I love passkeys and appreciate secure defaults but I feel strongly that user freedom is a more fundamental requirement than preventing phishing attacks.

On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse. Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.

    But requiring exports to be encrypted is the least one can do to maintain a degree of security while still allowing exports.

Moreover, "just" password protecting a file isn't allowed by the draft CXP standard (https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html#...), you have to use a HPKE scheme where the key exchange is manually orchestrated by the user to export offline. I get it from a security perspective, but that's stupid.

Ditto

I guess a desirable trait of seniority is to balance the urge to play with new toys vs the feeling that sometimes we are running in circles, repeating the same mistakes with different tech.

[1]: https://blog.codinghorror.com/the-magpie-developer/

I can see how SSH could be used for authentication on the web. And I have no doubt that it would be sound out-of-the-box. But I am not sure what you mean by your last sentence. Do you mean that authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding?

Aside from the wonderful possibilities that are offered by using port forwarding of some kind, you could also simply use OpenSSH's ForceCommand to let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service).

I guess no one uses SSH for authentication in this way because it is non-standard and kind of shuts out non-technical people.

    Signing into my accounts on my children’s devices has turned from a straightforward process to an incredibly frustrating experience. I find myself juggling all kinds of different apps and flows.

My kids use prepaid numbers, once I changed one and forgot to tell Apple, when I realized that I needed the old number later, it took me a month at least to get it back.

I really like passwords, the security risks are well known and really easy to handle compared to 2FA and all that crap, specially when 99% of your accounts are not sensitive enough to merit anything fancy.

How do I sign in from multiple computers?

This argument was made in the context of moving out of the Apple ecosystem (are there other ecosystems one would want to leave where the only option is paying for something like 1password?). I don’t really buy it because I can’t work out a situation where one is switching from some expensive ecosystem but unable to pay a low fee for 1password. But maybe I’m missing an example.

Just now, at least in Europe, there is a huge push to force users to authenticate themselves with their actual identity, even for ordinary Internet services. This is happening simultaneously in many countries (including non-EU countries like Switzerland). It almost has to be a coordinated effort....driven by whom? Passkeys play into this.

Call me paranoid...

You can either have 1 key pair per service and sync them with something like 1password. Or you can have 1 key per service per device. Keys that never leave the device is usually considered more secure (and I agree for what I consider my threat model to be).

Important services like primary email, your bank, or cloud platform should probably do 1 key per device. Everything else benefits from the simplicity of 1 key per service with the keys synced.

Bitwardens free tier is also generous enough that a lot of people won't have to pay

This isn't such a big deal in the SSH ecosystem, but it would be a disaster on the Web where there is an enormous incentive to track users. Part of WebAuthn's complexity comes from addressing that.

(customer identity and access management is a component of my work at a fintech)

No, it's just how you authenticate with signing keys. Given that a secure channel has been set up with ephemeral keys, you can sign a commitment to the channel (like the hash of the shared secret key) to prove who you are to the other party.

> let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service)

This is exactly what I recommend. If everyone did this, then eventually then the browsers or 1password could support it.

Actually, a benefit of passkeys is the standardization of client-side cross-device authz operations via caBLE and similar; your secret keys never leave your primary device, but are usable from other devices over a variety of transports.

Yes, it's awful during the transition period while the tech matures, but there is a path towards a great future.

Everything else about managing which public keys are for what does not need to be decided in a standard. The users can choose whatever key management solution works best for them. What those links get at is a problem of key management. A single set of keys, where you send all of them to every server all the time, is a bad strategy.

Being in charge of the strength and security of your private key is something most people don't want to do, so we get multiple identities made "easy" by walled gardens getting popular in passkeys.

It also applies to SSH keys. I never said that passkeys couldn't do everything SSH keys can do. My criticism is that they are more complicated to do the same thing.

This is exactly what not valuing simplicity looks like.

Is this really a common attack vector vs. a company leaking their whole customer database and a bunch of password being revealed that way?

I have 50 terabytes of data breaches on a NAS with lots of plain text or badly encrypted passwords, and that's just a small subset of what's out there.

I'd rather have the possibility of being "tricked" than get locked into another walled garden. Maybe I'm wrong for feeling that way, but there are literally dozens of us.

Author here. Insert your favorite ecosystem in that people currently have. If you have a windows 11 computer you end up with Windows Hello passkeys for free. If you have a Chromebook then it will be something else.

Apple devices show up in low income households somewhat regularly where I live because of subsidized iPads for education.

IME as a customer/user, financial institutions are some of the worst culprits for doing appalling things in the name of security (theatre) anyway.

We already require TOTP-based 2FA, and have even implemented secure TOTP via our mobile apps. Customers still do not understand 2FA and probably never will; we regularly have customers request 2FA resets after using their 10 backup codes. SMS- or email-based 2FA is a no-go.

We don't require hardware attestation, as that is the recommendation of the FIDO alliance and Google/Apple/Microsoft. It doesn't make sense to cut out iCloud/Google-synced passkeys given the clear security benefits over passwords+2FA.

Keep in mind that for our service, we regularly see attackers set up copycat sites to phish user credentials, and pay for Google Search ads to appear before our site in search results. These phishing attempts are sophisticated and customers will send their 2FA codes through them. _This is impossible with passkeys._

What do you need to do to keep family from (a) not getting locked out and (b) not getting phished?

There is no such guarantee if credential-stealing malware can export your private key material in plaintext!

The complexity of X.509 belongs in the domain name system. If a bunch of large corporations want to come up with complicated formats so they can decide who gets to call themselves what on the internet, let them do that, but don't let them complicate basic security for the rest of us.

The experience to beat is swapping SSH keys. 95% of developers have setup access to a new machine using SSH. That should be the default experience for authenticating on the internet, and anything more complicated should be strictly opt-in.

The reality is that TOTP has been obsolete for awhile now. It's a net negative for ordinary users that is kept front-of-mind for everyone because nerds like us are attached to it.

Edit: or put another way, why should I have to load another library for PKA when I already have one that works just fine?

I don't know if that would work but it is an interesting idea to me. However, it also illustrates that authentication and protecting user identity on the web without sacrificing anonymity is a _political_ problem not a technical problem. I have always been told that when thinking about security you have to define what threat are you trying to protect yourself from. I see discussions on security and virtually all of them ignore that the govt or govt controlled corps (i.e. fascism) is a much bigger threat to individuals and freedom than so called "hackers" or "terrorists" and other boogie men, etc.

Ever tried to SSH with a security key... through FIDO2? Or would you say that having your private key as a file on your computer is strictly better than having it in a security key? :-)

Not being able to use the passkey manager at all is a bigger concern. For example Keepassxc works with some sites but not with others. It's super annoying and way worse than situation with passwords.

The last time I tried to use passkeys, the desktop was easy. What about mobile? There wasn't a local third-party password manager that could work with passkeys on Android.

I just use a simple shell script with dmenu/xclip/oathtool:

  #!/bin/zsh

  typeset -A opt=(
      Docker ABC
      GitHub DEF
      # ...
  )
  k=$(print -l ${(ko)opt} | dmenu -i)
  [[ $k != "" ]] && oathtool --totp --base32 $opt[$k] | xclip -rmlastnl

Everything else is a security theatre and an UX pain.

sounds like you found yourself a market opportunity…

For example https://shamir.securitytools.io/

The downside is of course that hardware keys are typically not cheap and you should also buy a backup key. Another unnecessary downside is that certain companies like Microsoft require the use of resident keys, which take up storage space on the hardware key. The better alternative is non-resident keys, of which you can have an infinite number on your key.

Same when I got my Yubikeys: I gradually moved the OTP seeds to them, wasn't that painful.

And WebAuthn is using FIDO2, it's not that different, it's just that WebAuthn adds some stuff like a relying party.

WebAuthn helps prevent just that.

Not sure if we can say it's solved if nobody wants to use it by choice (certificates are probably mostly used in enterprise setups, but in my experience it's not even that common there).

Nope, it's exactly that: tricking people into believing that they are exporting their passkey securely where actually they are sharing it with the attacker.

> I don't see how phishing would be applicable to passkey exports.

Phishing is applicable to everything humans can do: if you can ask a human to do it, you can phish a human to do it.

You can buy a security key (that does not have your name on it), have it generate a FIDO2 key and use it as a passkey. You can have 100 Yubikeys for 100 different websites if you want.

But you can't ever export the private key from the Yubikey, and that's a feature. That's the whole point of the Yubikey.

I feel like people mix up the protocols and the implementations. Because one can share their passkeys with a Google password manager does not mean that they have to. Passkeys are just WebAuthn, which works on its own.

Since I'm getting downvoted as well: I am using passkeys with Yubikeys, without depending on any TooBigTech.

They're technically weaker than password + hardware key but stronger than anything else, including password + totp. Google Advanced Protection still wants you to have a hardware key for your account.

WebAuthn just adds a few things like the relying party and a counter (that nobody seems to use). And the relying party helps preventing phishing, which SSH doesn't do really well in practice (most people don't use SSH certificates and don't check the server fingerprints).

So it's just not true that passkeys are more complicated to do the same thing.

So yeah, you can have whichever you want, nothing prevents it!

You lose your job.

But passkeys are just a way of democratising private keys instead of passwords.

Sure, there will be examples of walled gardens leveraging passkeys. But we have plenty of examples of walled gardens that don't need passkeys at all. It's a different problem.

With passkeys, the private key must be present and usable (at least with current implementations) at the time of enrolment.

This raises a major problem: with SSH keys you can keep an backup key in a secure location (bank vault, etc) and still be able to register it. With passkeys your backup key must be present and connected when registering it, so you can’t keep it in a secure location as you always need it when registering. This exposes both keys to risks such as hardware failure (let’s say faulty USB port that spikes anything plugged in with 12V… you connect your main key, it doesn’t work, now you connect your backup key and same thing happens… by the time you realize both your primary and backup keys are toast).

Tying authenticity to a global, remote set of authorities is a tradeoff we make for anonymous introductions to random web servers whenever we need them. SSH doesn't have that problem, so the tradeoff gets you... nothing?

If KeepassXC wanted to enforce that world view for the safety of their users, it’s their right, but this is essentially a threat of blacklisting an entire password manager for adding a feature demanded by their users (who likely predominantly used by technically savvy users at that).

[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

For anyone who is confused:

https://www.cloudflare.com/learning/access-management/phishi...

https://bitwarden.com/blog/bitwarden-passkeys-mobile/

https://vaultwarden.discourse.group/t/passkeys-in-bitwarden-...

git remote add ... git+ssh://user@github.com/... comes to mind as a counterexample, although I admit there aren't many of these examples and GitHub also supports authenticated https:// with git. GitHub don't publish SSHFP DNS records either it seems, but the feature is there in the client.

Passkeys mean that most people can just FaceID or their fingerprint everywhere and they are happy. They are happy to be locked in if it just works.

For those of us who don't want to be locked in, we still have the possibility to not be locked in because we understand how it works.

I don't think we can do better: try to explain to normies how they should enjoy using a CLI and see how they react.

I'm pretty sure a lot of this stuff are arbitrary decisions that sites make when they implement passkey support and you never know where it will work. Also some sites likely don't care about fixing it since they think they deliberately are "improving security" or they just don't care. So I'd say it's an ugly mess. I wish it would work though.

Even for phishing, doesn't it count for something that TOTP prevents asynchronous phishing (collect credentials on a fake site, try them in batches later)?

This of course breaks down with cattle fleets where ~most logins are to hosts you've never hit before, which is why cattle fleets tend to use SSH PKI.

Perhaps I'm reading things in a worse light than you but I believe the potential for abuse is so high and the value of user freedom is so high that these comments shouldn't be taken lightly. I say this a user and huge fan of Yubikeys (I use them precisely because of the feature of not being able to export the private key for security). But I think users have the right to build/use software that works how they see fit.

Yeah, because people are stupid.

Heading towards a future where you need to use government-approved devices which are tied to your real identity to access the internet is a recipe for disaster.

The seemingly non-transparent (or was there none?) way to backup to a cold storage (e.g., printed and locked in a physical safe) turns me off.

---

> lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations). [1]

There is a possibility websites will only allow approved password managers to create/interact with passkeys with attestation, something that is not a problem with the common TOTP + Password or other authentication methods.

Attestation (perhaps targeted for enterprise usage?) but should be a separate spec/extension or something.

[1]: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

yeah i will not be taking advice from the majority of people in Fintech on this topic. thank you.

passkey are designed in a ways that the attestation party is visible. Tomorrow the coordinated effort will say "too much fraud from providers other than google and apple, sorry" (or something about protecting kids).

When the time comes to support passkeys on my services, I think I might use attestation in the other direction, ie only offer passkeys to users if I detect they are using a cross-platform password manager like Bitwarden or 1Password. There are simply too many moving pieces (including ad-hoc Bluetooth connections!) to guarantee a good UX when trying to move between the big tech implementations.

ALL of account permissions, relations to other accounts, and authentication should be an exposed api that rolls up into a single dashboard. I should be able to go into one single control panel to control exactly what accounts are allowed to do what on what devices for all services for all family members. That includes lockouts, auth resets, push of auth to a device I dont have physical access to (kid is on a trip, I need to sign him into something).

I could go on and on and on about all the different ways this paradigm is so broken, it actually breaks our imagination of what it should look like in a functioning world. We are so used to doing it completely wrong, its hard to see right.

I won't do it anymore until I have some way to see them, otherwise I'm essentially locked in, no?

Try 1Password Family and store your passkeys in there?

[1]: https://developers.yubico.com/Developer_Program/WebAuthn_Sta...

Anyways, 1Password completely solves this problem for me with me & my wife.

If github can't make it right, nobody can.

That's unrelated to passkeys. When you use your credit card to pay online, it's tied to your real identity. Many countries offered to do a lot of official stuff online (like taxes) long before passkeys.

They have, I don't think anyone denies that. But the other side has the right to refuse working with them if they find them insecure.

I don't think it is limited to passkeys... I have always been forced to use the authentication chosen by the IT at work, it's not like I can come and say "You know what? Instead of your SSO coupled with your second factor app, I would like to use my own password manager with email and password".

I think passkeys resolve that, even though it's more of a human issue than a technical issue :-).

Are you talking about the relying party? I don't think it works the way you describe...

I don't think they could blacklist the entire password manager. They can't prevent it from giving you a username/password...

Refusing some passkeys is, to me, similar to refusing passwords that are too short. It may make sense to only accept passkeys backed by a secure element. Companies already force their employees to use a specific MFA app, because they don't want to trust any app out there.

Some passkey implementations can be exported (synced), some can't. By design. E.g. I don't want my Yubikeys to export the private keys, ever.

So, yes, username + password or more generally a secret known only to you is superior.

It also doesn’t begin to cover notifications. For some reason most services seem to think only one parent is in charge and both don’t need equal access and equal notice.

The reality is that many passkey implementations right now come with attestation and are closed off. That's simply not possible with passwords.

Passwords, as a concept, just can't be abused in that way. Because they're just strings of text. Passkeys, however, CAN be - and we're already seeing that happen.

It could reverse course, but then it would need to reverse course and stay reversed. Forever. Even though there's lots of money and control being left on the table.

That's a big problem.

Well, not with only the password, but with the mandatory 2FA app that comes with it, it's definitely possible. Source: my company does that.

And you can most definitely request the real ID before you let someone create an account, password or passkey.

I don't see a difference.

1. It forces the use of keys with a reasonable amount of entropy, and the use of a password manager to access them. 2. They will not make it easy to use a key with the wrong site (also true of a good password manager). 3. Uses public/private keypair so key itself is never sent over the wire (even encrypted).

The real question is whether these properties are worth all the costs (enumerated in this article).

Passkeys are absolutely fantastic. Pretty much every complaint you see in these threads is seen as a positive in an enterprise context.

> Attestation restricts passkey clients

GOOD. I need a way to prove passkeys live on hardware-backed crypto devices (see NIST SP 800-63B), attestation makes that possible.

> But auth lock-in

GOOD. All our corporate sign-in events should be through our single IDP using SSO. Of course we want lock-in.

> But I can't sign in to my children's devices

GOOD. An identity represents a entity, it should be impossible for you to pretend to be another entity, regardless of whether they're a child or dog or whatever. If you need "parental access" or similar to some accounts, contact your service provider and ask for that feature.

> It's hard to export my passkeys

GOOD. Encrypted or not, a core security tenet is "a private key should never leave the device it was generated on" (hence the existence of HSMs, TPMs, etc). It should absolutely be impossible to ship your private keys around. Further, the primary appeal of passkeys in our context is phishing resistance, and it should be technologically impossible for a user to get bamboozled into exporting and sending their passkey to an adversary.

> But I need my backups

Why? Just contact IT if you lose your credentials. If you're on the personal side and don't have an IT authority, you should just generate passkeys on multiple devices and add all of them to your accounts.

> But that's a pain

Security is almost always inversely proportional to convenience.

We're not surprised, but I think many of us are horrified. I think it's a culture clash, partly between Free Software and Enterprise communities, partly between developers and security professionals. Given that it's a culture clash, I don't actually see any resolution that will make everyone happy.

My workplace uses Duo Mobile for a second factor, which is functionally identical to TOTP, and probably uses TOTP internally (if your android phone is rooted, you can export Duo Mobile keys to your choice of TOTP app). But as long as I'm being a good corporate citizen, I can't use my choice of TOTP app. What actual security (non-theater) interest does that serve?

The standard provides the means for the relying party to choose what password managers it will accept, so you may very well have to use the Google password manager.

Duo is regularly audited by independent third-party assessors to attest SDCL, data protection in their datacenters, etc.[1] Audits aren't a guarantee but they provide a reasonable amount of assurance that their software products and infrastructure have at least basic data protection measures.

> if your android phone is rooted, you can export Duo Mobile keys

This is the exact reason why personally owned devices, in most organizations, require MDM enrollment and attestation before being granted access to corporate resources.

[1] https://duo.com/solutions/compliance

If services want to force you to use whatever authentication they want, they can. That's what already happens with any service that is serious about security. In big companies, you have to use their authenticator app, their mail client, their messaging system, etc. Often it's Microsoft software. Banks have their own systems, etc.

Now, if a service allows you to use a passkey instead of their own 2FA app, I'd say it's a win. I'm happier using a security key than a Microsoft authenticator. But if they give up on using their own app, they may well set conditions on the passkey you use. And that condition may be "it has to be backed by a trusted secure element".

You won't be able to use a passkey that's deemed unsecure just like right now, you already are not able to just use a weak password with some services.

Again, I'm not saying that being forced to depend on TooBigTech is not a problem: it very much is. But nothing says that services have to do it with passkeys: they could (and should) also accept secure passkeys that don't come from TooBigTech. But they still have a say in what they find secure or not, and that part is okay.

The fight should be "now that we have good third-party authentication thanks to passkey, you should allow us to use those that are secure enough". Not "we don't want that new technology that is superior in many situations because services could force us to use it the way they want, exactly like they already do without this technology".

"Now that I can login using my Yubikey, please don't force me to use your MFA apps because they are provably not superior to my Yubikey".

They already do select the security they want. And it does make sense when security matters to them!

Say you managed to put into the law that "it's illegal to discriminate passkeys, either you accept all implementations or none of them". What would happen then? Those services would just not use passkeys, because they already have a solution they control today (with their own authenticator apps).

What the standard provides is a way to have certified/audited passkeys. So that instead of using the authenticator app of my bank to log into my bank and the Microsoft authenticator to log into my company SSO, maybe (just maybe) I will someday be able to use a passkey. Not any passkey, that's very clear, and it actually does make sense in terms of security. But maybe instead of using Apple or Google, you will be able to use a security key like Yubikey.

And the fight should be to give a fair chance to those third-party systems for getting certified. Not to refuse the passkey technology because instead of being forced to use the Microsoft passkey, we really like it better when we are forced to use the Microsoft authenticator app.

Of course they can: that's precisely the meaning of MITM.

They don't get direct access to your private key (because they wouldn't need to stay in the middle anymore at that point), but they will ask you to sign the challenge sent by the legit server, which you will happily do if you don't realise that you are not talking to the legit server.

WebAuthn prevents that MitM part.

Sure, we are being abused by TooBigTech and surveillance capitalism. It doesn't mean that all security is bad. Security is a compromise. Yet many people go "this added security comes from a governement/TooBigTech so it proves that it is a lie". Which is wrong: it doesn't prove it. Sometimes there are good things coming from governments/TooBigTech.

The world is more nuanced than people seem to realise.

The discussion about what happens in big companies is completely unrelated to this discussion. In that case the company is the user. They can do/enforce whatever they want and nobody is having any freedoms infringed.

If we are simply talking about ssh users ignoring fingerprint warnings then I don't see how this is an ssh weakness. A fingerprint change warning is basically saying "you're connecting to a phishing site" as I see it.

It's not, in that they have plenty of technological solutions to address their security concerns. Passkeys don't make it easier.

> I don’t think we should create standards that make it easier for companies to erode user freedoms

We want some degree of security in many services (typically our bank). And we generally can't have it all. Security is a compromise.

I didn't say it was an SSH weakness. I said that it was not "solved" problem in that most users I have seen completely ignore those warnings from SSH. So the problem persists even though SSH does it right.

With WebAuthn, the problem disappears. So that's an improvement for the users.

Don't get me wrong: I love SSH. I just think it's wrong to say that WebAuthn doesn't bring any kind of security to users.

To spell out the quote I allude to above, "give me liberty, or give me death!" We could eliminate a lot of bad things in the world if we were willing to give up freedoms.

Well intentioned but naive security researchers are constructing the very tools that will be used to by governments and corporations to restrict the rights and freedoms of users and I don't think we should stand for it.