Big Tech passkey implementations are a trap | Hacker News Reader

Big Tech passkey implementations are a trap

proton.me

50 pointsmikece45 comments

I find the general idea in this quote hard for me to swallow: "And passkeys can’t suffer mass exposure like passwords because apps and websites only store the public key — the private key remains safely stored on your device. If everyone used passkeys, much of the harmful effects of data breaches would disappear."

If a service can sync your passkey between devices, then by definition it can be copied off. And if it can be copied off, then it can also be caught in a data breach. And as soon as your passkey can be part of a data breach, we seem largely back where we started?

What am I missing? Is it better than it was? Almost assuredly. But a large part of the annoyances brought up in this post are specifically to limit breach exposure. Apple wants to make sure any keys it has synced can only be lost by a breach at Apple. Same for Google. If this is opened up to allow syncing by other actors, each other actor in the chain is now a potential breach, no?

Passkey private keys are encrypted at rest, even on the user's device. You typically need a PIN, password, or biometric to unlock the private key for authentication. Getting your hands on a sync data breach won't do you much good because each user's encrypted blob (containing the private keys) has its own decryption key.

It's not 100% fool-proof, but it's a huge improvement over password-based authentication. Remember, security is a "better than" game.

Right, that part I largely get. At least, I think I do. Such that if I am saying something that is off in that, please correct me.

My question is basically, as soon as they are exportable across devices, then you are trusting the encryption of every actor involved, no? Such that, if there was a process to share from Google to any other company involved, then that means any company involved could be breached and the key compromised.

You could do time bound shares. But, that is ultimately going to fall back on access to Google being what secures you. Right? (And replace Google with Apple for the same general scenarios.)

Now, Yubikeys worked by never letting you get the private key off the device. As such, if you lose the device, you can no longer use those secrets to authenticate. Solution then, was to have multiple keys all configured such that you would have to lose all of them. If you needed to reestablish a brand new set of keys, you had to do that in another way. At companies, this was largely done by doing it in front of an IT person that should either know you, or validated some other identification. (A bank would similarly require you to be there in person with government ID.)

What is the article's proposed way of letting you share passkeys at will across devices and companies, that doesn't largely compromise the security?

Just to be clear, are you asking about syncing passkeys across devices (ostensibly within the same ecosystem)? Or exporting passkeys between different ecosystems?

The typical use case for passkeys is that you can register multiple passkeys on an account, representing each authorized device. Each device can have its own distinct passkey provider. Services like 1Password allow you to sync passkeys between different devices, but those all stay within the 1Password ecosystem. 1Password also lets you export passwords and passkeys to different credential managers, but that's a one-off operation, presumably because you're leaving that ecosystem for another.

The article was specifically upset with Google and Apple for not letting you export across ecosystems. So, I'm specifically asking how they think that could work.

Am I misreading the article on that?

Got it. I think import/export is a solved problem, assuming you're OK with (at least temporarily) having your secrets unencrypted. Password managers already do this.

It's not a technical issue that's preventing Apple or Google from making their passkeys importable/exportable.

This doesn't seem to address my question, though? That is, agreed it is not a technical issue, but it is a security one?

As you stated, if you are ok with your secrets being unencrypted, then sharing is totally possible. But this seems to walk headlong into having to trust everyone that you share the unencrypted secret with?

Hi there, it is up to individual websites whether they require passkeys or passkeys + 2FA etc..

It is also important to note that most attacks are phishing-based, and passkeys are phishing-resistant, and will only work on the originating website.

Proton Sentinel also helps to protect account takeovers, even when an attacker has stolen your password.

Passwords can be compromised on client side or server side and since users tend to reuse them, compromise on fun.com can compromise your bank.com account.

Passwords+OTP plus a whole bunch of heuristics based account lockdown mechanisms improve this quite a bit. But still OTP is vulnerable for sophisticated targeted attacks.

Passkeys improve on this while actually improving the usability as well.

Passkeys come in two flavors – independent-hardware-bound (example: yubikey) and platform-authenticator-bound (example: Passkeys by Apple).

The former is bound to a single hardware token but can be used on many devices (your phones, laptops etc) to login to your accounts.

The latter is primarily tied to your Apple ID account (where Apple is the platform provider, for example) and also to your Apple devices like iPhones and MacBooks where your Apple ID is already logged in and iCloud Keychain syncing is turned on. Apple automatically and securely syncs your passkeys to those devices.

Obviously hardware-bound is a bit more secure than platform-authenticator bound, because platform authenticator can have a SPOF within the platform (a compromise anywhere within that platform stack - client-side, server-side etc. large surface area) where such a compromise is also completely hidden from the user. In contrast, the hardware-bound has a much smaller surface area. Only possibility of compromise are the hardware, the client (browser or the app), and the particular app backend server-side. Like all software stack, it is very likely this stack also has bugs that can be exploited. But this stack is relatively lot simpler to audit and secure.

Right, I don't know how to be precise in simple paragraphs about the ideas here. Basically, though, if you can authenticate from two or more devices (or, in a real sense, even applications on the same device), then whatever compute or secret is doing the authentication has to be copied between them.

A brief dump of my understanding: (Edit to add, I put this dump here largely to see if I actually understand the general landscape. If there are holes/mistakes here, please call them out.)

This was historically done by trusting the user to manage a secret that they attest they will not let anyone else know. In this world, the "compute" was often common knowledge, but hinged on a hard to guess part. This is no different than a credit card, so far. You agree that you will not let unauthorized users have your credit card.

A not surprising hole in this security, was that you had no way of knowing if someone else had your secret. You could do audits, but in general access patterns had to checked by others. (Note, this works better than folks give credit.)

Security keys took the path of making it so that the secret never gets off of the token device. There would be a challenge protocol that you could only succeed if you knew the secret, which was offloaded to the token. If you lost your token, you could not just get a new one. As the secret was flat out gone.

Passkeys are taking a lot of the security lessons learned there, and trying to bring them to the general public. In doing so, though, they are looking to increase user friendliness by letting your secret be managed by their ecosystem. In the case of Apple and Google, they are basically taking the route that, as long as you are sticking to their programs and services, they will replicate a secret for you.

This article is upset that Apple and Google are limiting the replication. Calling it a trap of passkeys. But... what is the alternative that is being pushed?

Note that if the argument is that the increase in security is already enough with existing audits and non verbally communicated passwords, that is probably fine. I got the tone from the article that something sinister was at play from Apple/Google. Sounds like the sinister motivation is more of wanting high security, though?

It's not clear to me that "platform-authenticator-bound" passkeys are a real thing. I've actually talked to someone behind the upcoming portability standard, and their standard allows for arbitrary export (encrypted, but in a form where the user can control the keys).

I did not get the implication from them that passkeys are meant to be "platform-bound", I think that's a security standard that's mostly made up, the impression they gave me was that user control over export to arbitrary clients was a strongly supported use-case in the upcoming spec.

Even Apple keys are not platform-bound today in the way you suggest (ie, bound to your Apple ID) -- Apple keys can be shared to other users using Airdrop, they're not bound to a singular Apple ID.

In practice, while passkeys are a meaningful reduction in phishing risk, they can be compromised, leaked, or phished, even in their current state -- and certainly will be phishable once portability standards land. That doesn't make them useless! But it does mean that we should stop pretending that the current lack of export is a pure security measure. The entire promise of portability is the promise that companies like Apple are not trying to create platform-bound keys.

We're at least meant to believe that these companies want passkeys to be truly portable between platforms. If "platform-authenticator-bound" is a thing, I suspect you are not explaining it correctly? Or maybe I'm misunderstanding what you mean -- but passkeys are not (intended to be) restricted to individual platforms.

The reason why it can't be abused the same way is because of the nature of the paired-one-way-encryption system.

A normal password is one-way encrypted. The algorithm makes it easy to turn an input string into encrypted gibberish, but virtually impossible to take encrypted gibberish and turn it into a suitable input string. Your password is run through this "hash" algorithm and stored. To prove your authenticity, you provide the password and the system encrypts it the same way. If the gibberish matches, you must have known the original password. The problem is that this is subject to several attacks, notably a dictionary attack where you just have a big long list of known passwords. The attack encrypts each one and see if you find one that generates the same gibberish. So, let's take the user generated password out of the loop.

The trick is that symmetrical, public-pair encryption creates two keys, such that:

  * A key used to encrypt a string or sign a blob cannot be used to decrypt or verify it (one-way).
  * A key's pair is the only one that can decrypt or verify a signature (symmetrical).
  * A completely random initial value (aka password) starts the process, but after which is no longer relevant to use.

With this, we can create two keys: one we hold to ourselves (private) and one we hand out (public). When we want to authenticate, it goes something like:

  Server: Here is a blob of data I generated and encrypted with your public key, prove to me you know what I did.
  Client: Sure thing.  (Decrypts blob with private key, wraps it with a private key signature, hands it back).  Here ya' go!
  Server: OH.. Nice.  Only you could have decrypted it, and only you can sign the results that match the public key I have on file for you.  You must be you.

If the public key is stolen, it doesn't do the attacker any good. Anything it encrypts is only good for you, and anything that it signs can only be verified by you. In theory, the attacker could get you to authenticate with them and that would show you are you. But, your password manager generates a new key for every site and authenticates with the key it knows. Even if the attacker uses one of your keys, it doesn't work unless it is for the site in question, meaning a man-in-the-middle attack. But, this isn't about stopping that. That is what DNS certificates are for. Passkey prevents having anyone but you ever knowing what the password was.

Right, I think this is largely covered in sibling posts. I agree that what you are describing is more secure than only using a password. It is, at a basic level, standard asymmetric encryption, right?

My assertion is more that the more you copy the private secret around, the more you are at risk of exposure. That some companies try to increase usability by copying it in their ecosystem is to make life easier for their users. They are shying from letting you export the secret, but not necessarily out of nefarious motivations? Indeed, there seem to be solid security motivations to not do so. Right?

I can't even register more than 1 yubikey in almost any service that I use. We are faaar away from easy, secure and also robust authentication in the web. On top of that, I don't like big central services to control my authentication and collect data about me.

Thank you, but until we arrive there, I'm happy to stick to my password manager. This post just comfirms my impressions.

Oh and to expand on that. I like to be able to setup my own authentication without having having to rely on 3rd party software, just in case. Relying on cryptographic hashes (for password hashing) is already kind of bad, but at least there are open source libraries who are hopefully checked by professionals on regular basis.

Most places, I thought, finally allow multiple keys? Who is left not doing it?

All 3 of my (german) banks for example. One bank here (N26) even only allows a single(!) smartphone for 2FA. So if I lose my phone... well, screw me.

I was curious if it was going to be banks. I don't think any of my banks allow yubikeys, yet. Will have to look into that.

Banks are especially bad. I know one bank that has you memorize 7 digits access codes and for authentication asks 4 digits at random places each time.

I'm with you. Using a password manager is brain-dead simple nowadays. Gone are the days of syncing KeePass databases on cloud drives. Bitwarden is completely free and reliable, for example. Autofill works on all major browsers on both mobile and PC.

The real problem here is user ignorance and apathy. We can try to force things down users' throats but they literally do not care about robust account security practices. They'll just lose the dongle or key or whatever you give them anyway, which will force some kind of centralized approach that introduces its own drawbacks (e.g., being deplatformed or canceled).

I big part missing from this conversation is what happens when you lose a device, want to leave an auth platform, or are deplatformed.

I don't want my credentials to be locked into any vendor, be it Apple, Google, or Proton. I currently use email + passwords + yubikeys. My credentials aren't dependent on some passkey auth server working correctly, or device that I don't control or have copies of. If Google or Apple wanted to ban me without recourse, in theory it wouldn't affect my ability to use other services. This doesn't appear to be the case with passkeys.

I really like that I can use 1Password for this. My biggest gripe is that it doesn't quite work yet in my main use case (Kagi's Orion on iOS. Ideally it would use Apple's API, not the 1Password browser extension, to use the OS setting that is set to use passkeys from 1Password rather than the iCloud keychain. I'm not precisely sure where the process is broken; but it doesn't work that way nor with the browser extension.)

This pretty much has to be solved using a legal framework? Specifically because the questions get even harder when you ask the tough ones. What happens when you die and your estate needs to be closed out? If you don't have a process in place for that, then you are ultimately assuming any digitally controlled assets can be destroyed by lack of access. And if you have assumed that, then you are also presuming some time frame on access?

Thanks for the feedback! You can currently export and reimport passkeys in Proton Pass (for backups) and as soon as an industry standard is finalized, we'll support that format too.

So, IIUC, passkeys are a form of public key authentication. You register a public key with a service and then prove you have the private key. It sounds like this article is blaming "big tech" for not creating a universal, seamless, transparent private key sharing mechanism. That seems... silly?

As a user, sure, I'd like to share my private keys around, and maybe one day we'll get there. However, exporting keys manually—which is what it sounds like proton is doing—sounds pretty sucky as well from a user experience standpoint. Now instead of having a password, I have a bunch of private keys that I have to manage and do... something... with on different services.

This article would do well to acknowledge that this is a very hard problem rather than just ring the "big tech suxxorz" bell again.

Nope. Non-resident keys work differently. You register the public key with the service, then you encrypt the private key (via wrapping but that’s beyond the point here) with private key stored on your hardware token and send the encrypted blob to the service, too.

When you need to authenticate, service sends you the encrypted blob, you decrypt it using the key on hardware token and obtain the private key. Than you do (more or less traditional) public key authentication.

So, you don’t need to manage your private keys. Services do it for you.

The point is many players are trying to find ways for your private key to be portable, too? Yes, it is a basic public key share to the services you are authenticating with, but it is how to maintain convenience at the user's side that is posing difficulties.

Indeed, the first real criticism in the post is "For example, if you create a passkey on your iPhone, it easily syncs to Mac devices but is incredibly difficult to use on a Windows device." It is the private key that they are syncing to all of your devices. And they do that for you because they control all of the places that they sync.

I think you can make the case that they should not sync this off device for you, but then you are in the "what happens when my device is lost/broken/stolen?"

You could also argue that they should let you export the key. But then you are back into the "credentials are easily stolen."

Proton Pass allows you to export and reimport passkeys. An industry-wide standard for exports is not yet finalized, but as soon as it is, we'll support that too.

Regarding passkey implementation, it's up to individual websites whether they use passkey or passkey + 2FA, etc..

This is content marketing. Rule number one is to find some kind of angle that can generate viral engagement no matter how thin the actual content is. Outrage tends to be a good hook. Acknowledging something as a hard problem, not so much.

Passkeys on supported websites provide a simpler/streamlined experience vs passwords as they are automatically generated and strong/unique by default without requiring the user to manage the strength of each and every password that they create.

They are also phishing-resistant, which means if a user mistypes a website and lands on a phishing website, the passkey will not work, where a password would expose private credentials.

Passkeys are also exported/reimported in Proton Pass just like regular passwords without any additional work, and as soon as an industry standard for backups is finalized, we'll support that too. They can also be included in shared vaults.

Thanks for writing this, I've been complaining and trying to get attention on this problem for somewhere close to a year and I feel like with so much of the completely uncritical coverage of passkeys I was disconnected from reality or something.

Portability is a huge issue for passkeys and the lack of communication about it as well as the lack of prioritization is holding passkeys back.

----

A few weeks ago there was a virtual tech summit for the FIDO alliance which had a tech-talk on the state of portability: https://www.youtube.com/watch?v=Mje6J2IMRTY

It is from what I can tell the only resource going over plans for portability to this level of detail. I'm hugely grateful to the presenters who even went out of their way to answer a few of my questions when I emailed them -- seriously, thank you.

But it's frustrating to have questions about portability years after passkeys became a thing and to have a 30 minute video be the best resource online for learning more. Hopefully that will change in the future, my understanding is that a rough draft spec is coming soon. But the process up until this point has been frustratingly vague and impossible to follow from the outside, and I'm still left asking why portability wasn't considered a pre-condition to launching passkeys and advertising them to ordinary users for regular usage.

I'm hoping things get better once the draft spec is released, I want to be wrong about passkeys. I want them to be something I can support and advocate for. It's because passkeys have so much potential that it's frustrating seeing them fall over in this way, and it's frustrating to see trends that make me feel like the entire standard is being developed mostly by companies without the kind of serious input from user-advocates or transparency about spec process that is necessary for a full password replacement.

You can already export and reimportant passkeys in Proton Pass and as soon as an industry-wide export format is standardized, we'll support that too.

KeepassXC too, and I think Strongbox(?) is trying to support interop with 3rd-parties -- if anyone from Strongbox is around, you should add support for Proton Pass's format.

That's been the encouraging part in this -- 3rd-party passkey providers stepping up and saying that export/interop is important to them and that they're not going to launch without it regardless of where the standard currently is -- so again, thanks for taking that stance :)

On which note, Bitwarden supports these as well -- and works on all the mentioned platforms. Of course I don't think it gets the platform access needed to actually log in using passkeys on iphones, but I feel that should be Apple's problem, not mine.

Bitwarden doesn't support certain important things regarding passkeys. [0]

    Q: Will passkeys be included if you clone a vault item?
    A: Bitwarden will not copy a passkey when completing a clone action.

    Q: Are stored passkeys included in Bitwarden imports and exports?
    A: Passkeys imports and exports will be included in a future release.

    Q: Can I store passkeys in the mobile app?
    A: Passkeys support for mobile applications is planned for a future release.

The lack of support for exporting them is especially problematic. KeepassXC has that feature.

[0] https://bitwarden.com/help/storing-passkeys/#passkey-managem...

So, platform default implementations are too platform specific, and a cross-platform third-party option is cross-platform? Shocking.

1Password also does this well, but without the moral judgement.

Disclaimer: I am and have been a 1Password user for years.

I wish 1Password would include the moral judgement. Had they done that, they might have given me control over my passkeys, including the ability to export them.

1Password does not support platform export/import. It works on multiple OSes -- that's not what ProtonPass is talking about here. They're talking about moving passkeys between services -- ie moving passkeys from 1Password into a different password manager. 1Password does not have a way to do that.

I remember the passkey topic coming up a lot a couple of years ago, my problems with them were the same as detailed in the article. I said I wouldn't use them until I could have a cross platform open source free version. Luckily keepassxc now supports them. I'll adopt way further down the line though.

Thanks for the feedback! Passkeys also provide the benefit of being phishing resistant and will only work on the originating website.

Aren’t a bunch of these claims just factually false? Chrome on macOS doesn’t use iCloud keychains passkeys like this article says they’re forced to do.

Hi there, from: https://developers.google.com/identity/passkeys/supported-en...

"Chrome on macOS 13.5 and later can use iCloud Keychain to store passkeys. Passkeys in iCloud Keychain are synchronized across the user's Apple devices and can be used by other browsers and apps.

Chrome on macOS can also store passkeys in a local profile, which means they aren't synchronized to other devices. Storing passkeys in a local profile is available in earlier versions of macOS."

For our corp environment we initially embraced software-backed FIDO authenticators (aka passkeys), but now I am almost ready to start enforcing only hardware authenticators via attestation.

The worst offender is (of course!) Google. In Chrome they bend the interface as much as they could to lure people into using Android as a key holder (and to sync it later on) even when platform authentication is available. Apple was very unfriendly by making their WebAuthn API private, so Safari used Keychain, Chrome did not have access to it (and forced Android) and Firefox only could use Yubikeys.

And now password managers are jumping into this, so when a user tries to enroll the device in a browser with password manager extension (looking at you, Bitwarden) on a platform with software authenticators good luck finding the right combination of clicks to choose Yubikey.

Enshittification of FIDO auth happened unbelievably fast.

Is there any way in which a passkey is better than a U2F hardware key?

You don't need to carry around a U2F hardware key, and it's less likely to break. I've lost count of the number of yubikeys that have broken off in the USB port of my laptop(s).

Reply on news.ycombinator.com