Ask HN: What would it take for you to switch to passkeys?
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?
38 comments
[ 3.2 ms ] story [ 78.5 ms ] threadUnlike 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.
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).
So the "something you have" is only something you have if you also have the pin. There are already 2 factors baked in.
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.)
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.
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.
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.
"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...
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 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).
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/...
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.
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.
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.
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.
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.
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.
Any risk of proprietary lock-in, whether to Google, Apple, or Agile Bits, is unacceptable.
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-g...
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.
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.
(Apple ecosystem user)