Ask HN: What would it take for you to switch to passkeys? | Hacker News Reader

Ask HN: What would it take for you to switch to passkeys?

16 pointscmdli37 comments

For those who are unaware, passkeys are a new authentication mechanism that allows users to log in using public keys instead of passwords. Right now passkeys are just starting to be adopted (Apple and Google have added support for them on their hardware) but aren't used widely.

Personally, I'm pretty excited about passkeys in general because passwords tend to be insecure, phishable, and relatively easy to crack and leak. However, I do see some hesitance in the idea of passkeys. I do see some problems with them, namely that it seems like passkeys are locked to the iPhone/Android device and are hard to sync. I would only switch to them if I could be assured that I could transfer them whereever I please.

What would you need to switch to passkeys? Do you see value in them? Are they just a passing fad?

View on HN

An entirely FOSS way to use them and back them up, with no attestation that I'm using a stack that's been officially blessed by one of the megacorps.

I want to manage passkeys myself. I don't want to use iCloud Keychain sync, and I don't want to use 1Password. This is a non-negotiable requirement for me. Other than that, I'm fine with the idea.

To add to this, I also want the ability to move "ecosystem" - passkeys are "platform-backed", meaning Chrome on iOS is "iOS" as far as passkeys are concerned, and you are stuck in the iOS keychain.

I want to see proper migration paths between iOS, Android, Linux, Windows, Mac, BSD etc - so that there is no platform lock-in or inertia that prevents you leaving one platform for another, and quickly (in under 30 seconds) moving everything across.

At a time when competition authorities are clamping down hard on platform dominance, self-preferencing and lock-in, passkeys risks becoming a pain point if there isn't proper, genuine, portability.

I'm also not keen on the lack of self-sovereignty of passkeys as you suggest - this feels like a "by the back door" way to force everyone into using "Sign in with X" type federated login. When your cloud account is locked out by Google AI, you want to be able to sign in to your other services! People have already started to discover the risks of Oauth type login when their bigtech company locks them out.

This is actually already built in the much maligned 'web3' that everyone loves to hate ( even if it deserves it sometimes)

Signing into something with your ethereum wallet works well, you get to pick how you store your keys and sign (brain, paper, encrypted file, hardware wallet) and if you use something like argent you can even have social password recovery if you want it for low impact applications. It's so awesome and it just works. I wish more things used it.

It's also built-in to GPG, which has been around since the mid-90s. The Blockchain is a completely unnecessary component for this sort of cryptosystem.

Alas, the blockchain people are the ones who made it popular. I would love to sign into things with GPG keys, but I have never seen a single thing that supports it.

Is it popular, though? Even now, the number of Metamask-enabled applications feels tiny relative to the provenience of GPG signing in the world of software.

No, while it's popular in certain spheres it's decidedly unpopular in general. It is, however, orders of magnitude more popular than GPG for website sign-in.

Right. If we're talking about practical usage though, GPG sees more widespread adoption than blockchain auth. Part of it is because it's older, but also because it's simpler and more redundant.

To clarify here, this is just public key cryptography using ECDSA signing keys to verify an identity.

Whilst it is blockchain-adjacent it does not use a blockchain for identity verification, it just checks the owner has access to a particular private key.

I would not want to use any service with keys that you can't copy and back up, no matter what, unless there was no alternative.

If it were built into BitWarden and synced with the vault, and as easy to use as passwords as in "This site wants to create a passkey using your passkey provider" I'd be all for it.

It'd be great to have a standard to share passkeys, and we'd be more than happy to include a reference implementation in solokeys firmware.

Passkeys is "just" the new (and much better!) name for FIDO resident keys. They are available in most (all?) security keys, though they're usually not extractable from hardware devices.

From a purely technical pov, I don't see any major complexity in exporting keys from one device to another (maintaining the required level of security), but of course if we want to do it across vendor we need a standard.

To the best of my knowledge both Google and Apple have their own proprietary way to share passkeys claiming better end-user security. It'd be nice to get to a standard that everybody can implement, and not just a way to share passkeys safari/iOS <> chrome/android.

I'd agree - technically speaking, there's no real barrier to a secure way to export from a FIDO key. HSMs have support for it - authenticate to the HSM, provide an encryption key (or public key), and receive an encrypted dump.

I do fear resistance from the big tech "overlords", trying to protect non-technical end users from an "endgame" type phish attack, where their device is compromised and they unwittingly export a backup encrypted to an attacker-controlled key.

From what I've seen so far (you may have a better idea than me), Apple and Google are giving "dip your toe into the swimming pool" type ways of sharing passkeys, but which actually revolve around scanning a QR code (proximity) shown on the (unpaired) screen/device using your (trusted) phone, which then uses BLE and similar short-range comms to let you sign in.

I am not aware of any proper "migration" that takes you off one platform and onto the other platform - the above is fine as long as you never break your phone (or can afford to instantly replace it with one from the same ecosystem), but makes no provision for someone wanting to move from iOS to Android, or to get rid of their phone and move to an authenticator in their browser on Linux. In the real world, people smash and break phones, and drop them in the ocean - there need to be recovery modes from this. A good Webauthn key will likely outlast at least 2 generations of current shiny gadgets.

Finally, all of this assumes users have unlimited resident key storage - most dedicated hardware keys are limited on this front, and I do hope we see options for people who want to stuck with UN + PW + FIDO2 (non-resident, as MFA). Even though I have confidence in the crypto, I like to separate concerns. A dedicated bit of hardware that can be unplugged from the USB port can resist attacks that on-platform TPM/secure elements can't, and is also inherently portable. And FIDO2/Webauthn today with non-resident keys is hugely portable (and even more portable if there was a way to pair friendly backup keys at time of initial registration).

Totally agree on the steps Apple & Google are taking, and a secure export/import should -I think- implement similar protections.

By setting a PIN/fingerprint (that should already be mandatory for passkeys), using usb or NFC for proximity, and of course pub key encryption à la HSM, I think more or less you should have all the ingredients. I personally like 1) to stay away from BLE, and 2) to stay away from using a server in the middle. On a phone, of course, you have more features but you also need to make the experience incredibly smooth even in edge cases (hence BLE, hence the server).

While on the topic, I found this podcast episode very very interesting [1].

As for the storage I'm not particularly concerned, if people start to use passkeys, we'll allocate more storage in hardware devices.

(and I'm also personally much happier with non-resident keys, however the market seems to be moving towards passkeys, so I guess we have to embrace it.)

[1] https://securitycryptographywhatever.buzzsprout.com/1822302/...

I really don't understand how exporting keys could be secure since I currently trust that if I still have a token and it still works, no one else has cloned it while I was asleep, etc. It also doesn't have a dedicated keypad..

Personally, I'm fine with having multiple devices I re-register together.

I think the lack of encryption/decryption and the generally poor support/guidance/etc for relying party design has been its biggest hindrances. Looking at something like keybase, I don't think there was a proper way to implement zero trust services with 2FA in a way that anyone could discuss clearly. Every pkcs11 device could do that naturally if they didn't hit other barriers to adoption.

I don't want to try to provide a specification here, just high level.

1. Get public key from the destination device (where you want to import)

2. Require PIN to export a key, i.e. only the owner can export (your key won't be exported while you sleep).

3. Encrypt the passkey, such that only the destination device can decrypt it. Here, you could add more checks, for example you could enforce that the encryption key is "certified" to come from a device you trust (FIDO devices all have attestation keys).

Note that the UX can be much simpler. For the end user, it could be like "plug in source key", "now plug in dst key", "enter source key PIN", and maybe it can backup all your passkeys at once like iCloud does.

With this said, as long as -as you said- there's no way to clone a key without your permission, an advanced user can very much use independent devices. The issue I see is mostly how do we make it easy (and in particular possible) for the end users.

I definitely prefer an open standard, (preferably where it can be attested that it is disabled) over possible proprietary implementations being setup with vendor generated pins before purchase, etc..

Based on simcards and similar, I don't think the pin situation is actually that nice for a user. You can choose from re-entering it often on the possibly keylogged device you didn't want to trust, forgetting it, having it on a piece of paper next to the token. Then you need a way for malicious code or user error to DOS it so that it can be short, then people start to ask why there is no escrow of a management puk. I'm exaggerating the limitations a bit, but the foot guns of having a plan that works seem to add up.

As with enterprise HSMs I think there is always a conflict of adding features and ways to recover from every possible mistake that erode the few clear security USPs that one can put together to just make and take an understandable risk trade off.

Wouldn't these fall under the "something you know" factor? (It's something you gave during registration, versus something they gave to you, right?) If so, isn't a public key just a really long password? Why not just let people use really long randomly-generated passwords stored in a password manager?

Something you know is long gone, even passwords right now are something you have: your password manager.

Unlike passwords, passkeys use public key cryptography. The server (e.g. Github) only stores your public key. You have the private key (e.g. in your phone). If the server leaks data, there's no way for an attacker to reconstruct the private key. Moreover, kind of by design, you're going to have a different passkey per site.

These two properties are very similar to using strong and unique passwords across sites that you can really trust. Note that with passwords you have to trust the site (to handle your password securely), with passkeys you get that for free.

The real new property is phishing resistance. When you log in with a passkey, the hostname of the website that you're visiting is signed as part of the auth data that's sent to the server. If you're on github.com, your auth data will contain a signature on github.com; if you're on a phishing site fake-github.com, the data will contain fake-github.com -- the phisher/attacker will get this second data. If the phisher/attacker tries to reuse your auth data on the real github.com, the verification will fail (it's probably easier to picture than to explain...). With passwords, you get phished.

Something you know is often a pin to unlock your local stuff. Some hardware tokens (via webauthn) require a pin to work.

In the current design of most security tokens, a PIN is not really a "something you know" factor per-se - it instead unlocks a "something you have" factor.

That sounds counter-intuitive, but few (if any) security tokens actually include your user PIN in the cryptography. The same is generally (as far as I know) true in the smartcard space. You rely on hardware attacks being expensive, costly, detectable through physical damage, and not very likely to succeed, in order to protect the physical token.

That physical token then (likely) holds the plaintext PIN, or a simple hash of it (which would likely be instantly crackable for numeric PINs).

Therefore the PIN is really an access control mechanism for the "something you have" - an asymmetric signature from a hardware token, where access to generate the signature is controlled by the PIN, arguably doesn't actually incorporate the knowledge element in verification, since a compromised hardware token can still generate the signature without the PIN.

(FWIW the user you replied to developed the software for a Webauthn key, so may be able to correct/elaborate on the above).

The pin might be stored in plaintext but should be stored in some sort of secure location on a chip that can't be accessed physically or through brute force. One strategy to prevent brute force the chip may only allow X tries before wiping itself.

So the "something you have" is only something you have if you also have the pin. There are already 2 factors baked in.

I agree. I meant to say that you can no longer just have "something you know", you also need "something you have".

Wether this is already or not 2FA it's a bit debatable. Apple says yes and I tend to agree. From the server's perspective, however, it can only verify 1 factor and it has to trust the client to implement the 2nd factor securely (whether it's a pin, fingerprint, face id, etc.)

There's 2 main reasons they differ from "something you know":

1) A passkey isn't phishable, as it's a digital signature that wraps the origin domain that is requesting the passkey. That means a phishing site can't "request" a valid passkey for another site, and replay it to gain access. This helps "normal users" who could be tricked into entering the MS/Google login on a credible-looking SSO portal, and approving the MFA request - a passkey will stop this.

2) You authenticate via a non-replayable signature. If the site's backend database is dumped, nothing is learned - nobody gets even a hash of a password. The stored data is guaranteed to be unique to that site (different public key for every account you make, even on the same site). You can't use it against other sites. If the site checks logs and can be confident the database wasn't tampered with, then after a compromise, they can continue to rely on webauthn logins - just because you saw someone's public key and encrypted offloaded private key doesn't help you log in as them. In contrast, with stored password hashes, users with weak or re-used passwords are at particular risk in this case, and you likely want to force them in through the reset password route, rather than let the attacker used a brute-forced or otherwise leaked password.

> However, I do see some hesitance in the idea of passkeys.

Interesting, my impression is that everyone is ready for passwords to die.

> I do see some problems with them, namely that it seems like passkeys are locked to the iPhone/Android device and are hard to sync.

This will apparently be solved with password managers, which will handle sync across devices/platforms. (One source: https://www.future.1password.com/passkeys/)

> What would you need to switch to passkeys?

Password manager support with cross-device/platform sync.

The resistance in my view is about migration and support. Just the practical things for moving to a new auth type.

I might be in the minority, but I am worried about privacy laws and phone unlock/biometic data. A password is something literally only I know and has been effectively protected while unlock/biometric data is being actively tragetted.

"In considering a specific rule to adopt, Chief Justice Rush asked Seo’s attorney what level of particularity the state should be required to show to balance the state’s need with a defendant’s Fifth Amendment right. Seo’s counsel responded that the foregone conclusion exception, a limited exception to the general Fifth Amendment protection against self-incrimination, should never apply to compel decryption because:

compelled decryption is pure testimony, decryption of digital devices is totally unlike the act of producing documents, and even if decryption were an act of production, the state failed to describe the phone’s contents with particularity as required for the foregone conclusion exception to apply. But the state argues that (1) providing a passcode or biometric feature is not testimonial and (2) even if such information has testimonial aspects, compelling Seo to unlock her phone doesn’t violate the Fifth Amendment because her knowledge of the password (not the phone’s contents) and her control of the phone were a foregone conclusion.

...

Justice Mark S. Massa, however, summarized the State’s argument, saying “protection from government overreach will lie in the Fourth Amendment, and not in the Fifth” (notably, Seo hasn’t yet raised any Fourth Amendment arguments)."

https://news.bloomberglaw.com/privacy-and-data-security/insi...

https://www.governing.com/security/search-warrants-can-requi...

The only thing I want is GPG-style interop. If I can sync a cryptographic login keyfile between my devices with something like Syncthing or SFTP, that would make it trivial to integrate it into my workflow.

Multiple passkeys support by default. Many websites only support one hardware token and hardware is not infallible.

Too many services only support a single MFA enrollment.

I have a pair of yubikey but don't use them most of the time because most services won't let me register both concurrently, and I'd rather not be permanently locked out if one of the yubis gets lost / contact pins wear out / etc.

That said, you're lucky if they support one FIDO2 auth method at all instead of just SMS.

I need to know that I can use them on all my platforms, right down to my Raspberry Pi Zero with practically no memory not processing power

A completely open standard, at least partially human-readable /-parsable, with an open source reference implementation.

Any risk of proprietary lock-in, whether to Google, Apple, or Agile Bits, is unacceptable.

I’m ready to switch as soon as sites support them and provide a transition mechanism from password to passkey.

(Apple ecosystem user)

Couldn't passkey fingerprints be used to identify you, regardless of login?

Not generally, although precisely how this works in a passkey world remains to be seen.

In the underlying webauthn technology, a non-resident key is uniquely generated for every account you have. In theory your use of the same token for multiple accounts on a platform isn't detectable by the provider (assuming you have good opsec around use of IPs and session isolation). There is one super targeted attack a rogue site could do - it could serve up another account's challenge, which it suspects to be you, and see if your device returns a valid webauthn response for it.

Passkeys should be slightly better than this in theory - as they let you select a stored identity to authenticate as.

The crux will be how Google and Apple implement this - and whether this holds true or not in their ecosystems. There's no reason it shouldn't.

in terms of value, i assume the push for passkeys is to make sure you have a device tracking your location with you at all times. so, obviously there is great value.

I will not use them unless there's stronger laws about biometric data and privacy. I realized that the whole point of passkeys is to replace passwords. It won't be immediate, but it is clearly the long term goal. I don't want my secrets/password secured to a ecosystem login. If I don't control my secrets, they aren't my secrets. It's a single hardware point of failure.

If passkeys are made mandatory, I want TOTP/HOTP to be primary and mandatory for every login as well.

In a hypothetical scenario where a government is looking to unlock your data, using a passkey would guarantee them acess to your data since a warrant will let them take the physical key or force you to unlock your device.

"A man must use his fingerprints to attempt to unlock his phone, an Illinois federal district court ordered in signing a search warrant, finding that the request does not violate the Fourth or Fifth Amendment." [1]

The marketing from some companies that it will replace both password and TOTP codes with just passkeys make me wonder the motivation behind this push.

I took time to understand passkeys, and they are essentially a new implementation of the idea behind YubiKey locked behind major corporations like Google. "Your" phone device is a YubiKey that you can add to websites. And just like YubiKeys, they don't allow exporting keys. Worse they are tied to a megacorp login. The attestation requirement is already satisfied in current YubiKeys.

Until an open source "weak" hardware or software implementation of passkeys exists and is clearly allowed by websites, I will not believe that attestation will not block this. Exporting secrets, while possible to code in an implementation, breaks one of the core ideas behind using something like a YubiKey where the assumption is one device per private key. Why would a website willing allow a "weakened" implementation? That would compromise the security model.

I felt like a conspiracy theorist considering how the US government is becoming more of an"authoritarian government" but I realized I was giving the benefit of the doubt to an entity that doesn't deserve it. The US government is becoming agressive in dismantaling people's constitutional rights with technology.

"Once a warrant is secured, the type of passcode becomes the next deciding factor in whether law enforcement can gain access to a phone's contents. Cell phones are typically protected by a passcode that is either numerical or alphabetical, or by biometrics, such as a fingerprint or faceprint.

A Virginia circuit court ruled that police can require someone to give them access to a cell phone as long as the passcode is biometric, such as a fingerprint. That's because a fingerprint is considered something you have — physical evidence — and thus not self-incriminating. Stanford's Pfefferkorn said this can also extend to facial recognition.

But numeric or alphabetical passwords, on the other hand, are often considered something you know. This is where courts are divided." [2]

1. https://news.bloomberglaw.com/privacy-and-data-security/forc...

2. https://www.tampabay.com/business/when-can-police-compel-you...

https://www.governing.com/security/search-warrants-can-requi...

https://psmag.com/social-justice/can-the-government-force-yo...

Reply on news.ycombinator.com