Let’s say I have a passkey in Chrome and no password. How do I add a passkey to iOS so that I can login via both mechanisms?
Is my understanding correct that if I only used Passkeys that I’d be permanently locking my account to a third party service to the vendor I used to login with in the first place?
Sure. But am I still locking my ability to access that account permanently to Google? Can I login via Chrome on an Apple/Windows platform and add a passkey there?
I’m also a bit worried that this permanently entrenches these as the platform vendors because no one is going to port to a new platform unless you’re already a major tech company (maybe).
That’s interesting and I think potentially addresses the concern. I don’t think I’ve seen Apple have a QR scanning code option for passcodes but it’s possible that’s just integrated into normal QR in-camera. Apple doesn’t have a QR export does it?
What would be nicer if there’s a way to do this in Chrome on mobile. I’m not always near a computer although I’m reality that’s probably when I’d be adding the passkey via chrome.
In my case I created (1) one passkey for the Apple ecosystem, and (2) a second passkey for Chrome. I had to add the Chrome-specific passkey because Google isn't using native OS passkey support via Keychain.
I don't know if this will be universally true among sites that support passkeys, but Google allows you to create multiple passkeys per account.
Google actually outlines that very scenario near the bottom of their announcement:
> Using passkeys does not mean that you have to use your phone every time you sign in. If you use multiple devices, e.g. a laptop, a PC or a tablet, you can create a passkey for each one. In addition, some platforms securely back your passkeys up and sync them to other devices you own. For example, if you create a passkey on your iPhone, that passkey will also be available on your other Apple devices if they are signed in to the same iCloud account. This protects you from being locked out of your account in case you lose your devices, and makes it easier for you to upgrade from one device to another.
> If you want to sign in on a new device for the first time, or temporarily use someone else's device, you can use a passkey stored on your phone to do so. On the new device, you’d just select the option to "use a passkey from another device" and follow the prompts. This does not automatically transfer the passkey to the new device, it only uses your phone's screen lock and proximity to approve a one-time sign-in. If the new device supports storing its own passkeys, we will ask separately if you want to create one there.
> For example, if you create a passkey on your iPhone, that passkey will also be available on your other Apple devices if they are signed in to the same iCloud account.
In addition to this, you can AirDrop a passkey from one device to another, even if they don't belong to the same iCloud account.
All of that just locks you into Apple’s platform and now I have a problem copying that passkey to chrome.
However, a sibling commenter mentioned QR code export/import. That would alleviate the concern and be even more elegant, especially if it automatically created a new passkey registration instead of just copying it around.
AFAIK QR code export is not a thing, just speculation for how passkey exports could work (which I doubt since QR codes get hard to scan the more data you pack into them; maybe you could ask the user to hold the camera to the screen for a minute while the target machine cycles through each passkey, or cycles through qr code data itself to facilitate error correction and 100% data transfers)
That commenter is mistaken. The QR code is for authenticating on your computer via your phone over Bluetooth. It does not export the token to be used by another authenticator, you have to have the device with the Passkey anytime you use this QR code method.
> If you want to sign in on a new device for the first time, or temporarily use someone else's device, you can use a passkey stored on your phone to do so.
No lock-in; you have two phone OS vendors to choose from!
> that passkey will also be available on your other Apple devices if they are signed in to the same iCloud account
I am not sure I like this. Unless the passkeys are only transferred directly device-to-device, each OS vendor's user cloud storage now becomes the keys-to-every-kingdom uber-target.
If that is a concern of yours, there is an option on Apple devices to disable iCloud syncing for passwords/credentials. This would limit passkeys to strictly device-only.
> Passkeys on iPhone require that you use iCloud Keychain. If you don’t have iCloud Keychain turned on when you try to save a passkey, you’ll be asked to turn it on.
You are confusing the location where passkeys are stored (your Android, your iPhone, your Yubikey) and where they can be used (to access your Gmail account).
I don't think they are; they're effectively asking whether accounts will support multiple passkeys. This is a reasonable question IMO: if the protocol is not well-designed different services (account providers) may have different rules about how many passkeys can be attached to your account in their system. (E.g. "2 passkeys ought to be enough for anybody!") And for how they can be managed: removed and updated, particularly.
The attempt to get rid of passwords has been the biggest assault on the free internet in recent history, and people are asleep at the wheel as it's happening.
They want to tie you to an external service, so they can tie you to your phone, which they also manage with another external service.
All of these schemes are braindead with obtuse, user-unfriendly backup/transfer/restore options. They fail at even making things "simple" for regular users.
To avoid being a propagandized lemming you have to have a basic understanding of what is happening...
passkeys aren't tied to Google or to any other specific provider. Note that this announcement is just about Google supporting logging to with passkeys to their platform. But you don't have to have anything to do with Google to use passkeys with other sites/apps that support them.
Disguising a proprietary development under an industry standard umbrella is a typical move from Corporate Utopia playbook. That's why it is so easy to spot when somebody tries to manipulate public opinion using social media accounts.
It would be a totally different situation if customers were actually interested in a particular solution. Otherwise, it's all astroturfing and nothing can really change that.
Also it's always a good tone to put a disclaimer, e.g. "Googler".
> Disguising a proprietary development under an industry standard umbrella is a typical move from Corporate Utopia playbook.
OK, but is that what's going on here?
There's the suggestion in this part of the thread that somehow this all inhibits user freedom. But these objections appear to come out of complete ignorance of what is actually happening. I'm pointing it out because it's the people who are most concerned about corporate manipulation that need to understand what's happening to have any idea on how to guard against it.
> Also it's always a good tone to put a disclaimer, e.g. "Googler".
I guess you're suggesting I'm a Google shill? Well, (1) you're wrong (in fact, I got rid of all the Google things I used to use personally); (2) did I even say anything helpful to Google?
I suggest to take off the tin-foil hat of paranoia. It's not going to protect you from anything and, in fact, will make you more vulnerable if you let it cause you to focus on the wrong things.
It's not a proprietary development. The intention to use private keys for authentication goes all the way back to the KEYGEN tag in HTML. WebAuthn started from FIDO, not Google, and FIDO Alliance was started in 2012 by PayPal, Lenovo, and others, not Google, Apple, etc. Google joined in 2013, and they were mostly interested in 2FA at that point. And prior to that, when I worked at IBM TJ Watson in the 90s on some of the first TPMs, we were developing passkey equivalents using public key crypto for login and digital signatures on ThinkPads and RS/6000 workstations.
This work, desire to use public key crypto for authentication, goes back A LONG time practically before the internet was taken over by corporations.
This is a good thing for the public. Passwords suck. The number of people who have been pwn3d and phished due to passwords is insane, they're user hostile in so many ways "It would be a totally different situation if customers were actually interested in a particular solution", are customers actually interested in constantly logging in with password and SMS codes -- the default today. Does anyone love using authenticators, or Apple 2FA popups, security keys?
Nothing about this is tied to phones or external services. You could just use a hardware authenticator (like a YubiKey) as a device-bound passkey if that is what you prefer.
Okay, but the alternative is users managing a separate password for every service, which is impossible to do securely without using a password-manager, and the password-manager is basically a weaker version of an external service like Google's.
Weaker? The UX for signing in on a new device seems better. Maybe that's the same thing as weaker. I'm not seeing any reason in all of this to switch from a password manager though.
Passwords are terrible for a world where people have hundreds of them and are lazy. And password managers are a bandaid solution.
Arguing effectively that passwords were fine for computing in 1970 isn't an answer. So if you don't like passkeys it's reasonable to ask for your alternative.
The first point seems correct, the second seems incorrect. Remembering a single password for access to a secure well-designed password manager seems a bit more secure than a physical passkey, what am I missing?
But you still need a password to use a passkey right? So passwords aren’t going away, they’re just being used to a more secure way.
My mom can’t tell if a website is fake if it’s made to look exactly like Facebook, for example. So in a sense passwords are actually awful for users because they’re required to remember dozens of passwords and verify that a website is legit. If they just reuse the same password everywhere then they are vulnerable to another kind of attack because some website somewhere will mishandle it, forcing her to change every password on every site afterward.
Instead, she can have the best of both worlds by remembering one master password, that basically opens a magic app that will check that the website is legit and create/retrieve a unique passkey for each login.
How is this more secure? They say "with a fingerprint, a face scan or a screen lock PIN", but basically all phones let you fall back to PINs if you dont want to do face or fingerprints. Pins are flat out not secure - typically just 4 digits.
Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.
>with a fingerprint, a face scan or a screen lock PIN
I agree - not secure.
And just a daily reminder that biometrics are usernames, they are not passwords. You can change a password, a lock, a key, you cannot change biometrics, and thus they should not be used for guarding sensitive info.
The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance.
> The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance.
Please provide evidence that biometric data has ever been extracted from a major platform (IE Apple/enclave). Absence of evidence != evidence of absence, I know, but you’re selling it as the only use case so surely you have proof.
> Please provide evidence that biometric data has ever been extracted from a major platform
Why extract it from a platform when it can be extracted easily from the person? Imagine your password was written on every surface you touched (fingerprint) or is prominently displayed on your social media accounts (face).
And then extrapolate to how those biometric factors could be changed outside of your control -- car accident requires facial reconstruction. Or a fire burns your fingerprints.
I cut myself on a cheese slicer once and had to use PIN for unlocking my phone for a week or two while the cut healed. Annoying, but that's what the fallback PIN was for I guess.
I don’t understand how this could work actually. From a couple of photos on the social media you can likely recover the 3d geometry of the face. From that, if the signing algorithm is known, you should be able to replicate these passkeys.
If the algorithm is not known, it’s only a matter of time it’d be leaked or reverse engineered. And then suddenly there’d be a massive, difficult to fix security breach. Just like the breaches that we have now, with voice based authentication.
The biometrics like your face or fingerprints aren't used directly with the site you're trying to log into and would never leave your device. It's just used to unlock your phone/tablet/computer/whatever's stored secrets to sign a message verifying it's you. If you don't trust the biometric systems on your device or are worried about someone stealing them and trying to fool your device's hardware, you can always just not use them and just use a passcode/password to protect your device instead.
The problem is not that biometrics are leaking from my device. The problem is that faces are already on the social media. And that the biometrics of the face can be reconstructed extremely easily and at scale.
But if this is used only to unlock the trust zone/secrets, I guess that works. It seem to be extremely dependent on the device not getting locked up accidentally, lost or damaged. If a damage would lock you out from all of the accounts, this seems rather drastic.
> biometrics are usernames, they are not passwords
While I see where you're coming from, they really aren't just usernames. It's not like I can log into your e-mail account by typing VoodooJuJu and pressing Enter.
> And just a daily reminder that biometrics are usernames, they are not passwords.
I think you should stop giving out this daily reminder. This meme has outlived its usefulness.
Using face id to unlock a local key store to enable my device to sign a signed challenge from a site I want to log into with the private key stored on my device is not a 'username' in any meaningful sense.
The problem is, the metaphor about passwords and usernames is not a good, structure-preserving simplification of the actual problem of authentication.
The biometric data and/or pin code are not being used to prove that you are you to Gmail, it's being used to unlock the set of private keys you have on your device. This doesn't fit into the metaphor at all.
If my non-technical parents said they were migrating all their accounts to passkeys, I would be very pleased. I wouldn't be worried about their inability to change their biometrics and that causing a problem following some sort of breach in the future. I am highly worried about their extreme susceptibility to phishing, especially in their inability to distinguish phishing sites from real sites, or real account maintence contacts via email and SMS from phishing contacts, their reuse of very simple passwords that are probably circulating in combolists already, and their general inability to retain username/password pairs. I have a lot of sympathy for them when I try to talk them through something like logging in to an Apple device with their apple id, when their appleid username is their email, which ends with @gmail.com. "But...why would i log in to apple with my gmail?" nevermind how confused they are about 'log in with google', 'log in with facebook', etc.
Moving to a model where their devices store webauthn credentials and guard them with a pin or faceid-style biometric shortcut is a _massive_ improvement in practical resistance to account takeover for my parents, and I don't think continuing to say 'biometrics are usernames in authn' is accurate or helpful.
> If my non-technical parents said they were migrating all their accounts to passkeys, I would be very pleased. I wouldn't be worried about their inability to change their biometrics
My 76 yr old dad can't do it. His phone is some shitty android trash that when he's setting up his biometrics, he shakes a bit, and it never stores the finger data correctly. I have to hold his finger and his phone at the same time to even scan it. Then, unlocking is also super unreliable because of the shaking. He refuses to get a better phone cause this one "works well enough."
This is so true - most older people I've worked with have major problems with touch devices. No one has come up with a satisfactory solution. This is not a new problem - I remember working with my grandfather in his 80's on a 286 equipped with a mouse - his arthritis prevented him from accurately positioning the mouse. Today's touch interfaces are far worse. And fingerprint scans are very difficult to get right and use with older people. Maybe face scans are fine but I've never trusted them. Regardless of security logins, there are a host of other issues - complex navigation, complex and confusing layouts (especially desktop), and hard to manipulate controls. One example, a simple zoom or skype call - why hasn't anyone ever developed a simple device to allow for same without having to use intricate controls. I've always imagined something similar to the video enabled nest or alexa devices but with physical knobs and push buttons. There's a very large market being ignored for some reason.
> There's a very large market being ignored for some reason.
It's no surprise that the tech industry, which largely employs urban, educated 20-somethings and 30-somethings, tends to produce products aimed at urban, educated 20-somethings and 30-somethings.
> No one has come up with a satisfactory solution.
Stick your finger inside of a dynamically sizing aperture, or clip a finger reader onto your finger? If both the finger and the reader shake the same there shouldn't be a problem.
That doesn't solve the general touch issue, but it solves this particular case.
It might not be that the android is crappy. Some people's fingerprints stop being readable as they age, and there are various injuries and diseases that have that result.
Essentially every biometric has a population they won't function well with.
It's 100% accurate. And I get why it may not seem helpful, but I think this is simply due to this industry trying too hard to cater to people who want things to be 6-year-old level easy.
Security is HARD. There's no getting around that. Your data is valuable and protecting it is not an easy task. At some level, security and convenience is a zero-sum game.
As for old people, my dad writes down his passwords on a text file in his laptop and has a printed backup in the house.
And, yes, he does have to bug me sometimes to re-login or change a password, but we've never had a security problem, which is way more than can be said for a lot of people who tried the INHERENTLY unsafe "3rd party manager" thing.
The security triad is "something you are", "something you
know", and "something you have". Fingerprints are something you are. Usernames are something you claim to be.
The username is the "claim" you are this person. The password is the "proof" you are.
If I'm fingerprinted by any federal agency today (and my fingerprints have been on file with the government since the 90's for a security clearance), then my fingerprints can serve as absolute proof of my identity. This is helpful to me should my identity ever be stolen and I need to show absolute proof of who I am.
Those are all factors in multi-factor authentication. If a service does not require the "something you are" there's still good security if they require the other two factors. If the only required factor is "something you are" that's bad security.
Good point, you're right. And with e.g. federal agencies, this fine.
But given the relatively high level of laziness, capriciousness, and general failure all around that is "IT security by means of companies who are rarely held accountable," it's good to point out that this is what makes biometrics worse than usernames and should probably mostly be avoided, or at least optional.
Your points are taken, but I do believe that the "something you are" is better than the "something you know" and "something you have" pieces -- as the knowledge or the thing you have can be stolen.
Sure fingerprints, face scans, and iris scans can be stolen as well. But certain things are really hard to fake, including potentially, scans of faces and an iris scan at the same time -- unless you can somehow graft a new iris and grow a new face.
Put it like this: a dead victim is found naked along the side of the road. Which leg(s) of the security triad can the police use to prove the identity of the victim?
If convenience plus precision are your only goals, sure. But this requires probably too much trust in the systems. I'm fine with the FBI having that power and information.
Google, who I don't pay and doesn't owe me much, not so much.
i rowed on a crew team for many years. The pads of my fingers were all worn down. I was rejected three times for "bad fingerprints" when applying for US citizenship.
It's not as rare as people think for fingerprints to be messed up either permanently or temporarily. Which amazes me, actually, because I'll be willing to be pretty near 100% of adults have, at least once in their lives, burned or otherwise injured their fingers in a way that alters their prints.
Relying on fingerprints to gain access to things on a regular basis never seemed like a great idea to me.
Password + password manager can be trivially phished. PIN can’t, because even if you somehow phished a user you can’t use it.
I don’t know what “proper 2FA” means but the gold standard today is U2F, and it has failed to be mass adopted due to requirement to purchase and maintain another device.
This is more secure, passwords can't be stolen from the site. Sure, let's go with the assumption that your phone can be stolen. It would be only your phone. If a site has 100 million users, an attacker could steal 100 million passwords. With this approach, the attacker would have to steal 100 million phones. No matter what password manager you use, with a password length of 100 characters. The entire password list (encrypted) can be stolen.
This keeps you from ever sending the password to the site (similar to e.g. SRP).
Most sites already don't store the password. If you have a sufficiently strong password (i.e. very long, randomly generated, stored in a password manager), it is likely not computationally easier to recover the password from a hash than it is from a public-key. The only improvement here is that you don't have to trust that the site is following best-practices for storing passwords, as you never send them the password.
[edit]
It also prevents phishing attacks for those using some form of entering a password other than autofill from the password-manager.
A PIN entered onto a physical device like a smartphone can be rate limited (see iPhone progressively increasing PIN timeouts). If you try to rate limit password entry to an online service, you make it trivially easy for an attacker to lock out a real user.
Thus, even short PINs can provide strong security since the attacker gets, e.g., at most 10 tries to guess it out of 100k possibilities for a 6-digit PIN.
This has been bothering me, a lot. Google talks [1] about how Passkey replication is e2e encrypted between devices, but AFAICT they're just using a pin + key derivation. A six digit pin is like 20 bits of entropy before a KDF. [2]
Has anyone seen any docs that might help characterize how much entropy the keys have for e2e encryption (Android/iOS)?
I must be missing something, because I can't see how Google would call something e2e encrypted if the keys only have like 30-35 bits of "effective" entropy after a KDF. But that seems like it's the case??
[1] "From the user's point of view, this means that when using
a passkey for the first time on the new device, they will
be asked for an existing device's screen lock in order to
restore the end-to-end encryption keys"
Talking about Apple here because it's what I'm more familiar with, and their security whitepapers are more widely available.
The PIN and key derivation wraps the actual encryption key that's stored locally in the device or secure enclave, not the actual secrets that are stored in the provider's cloud. The actual wrapping keys are random 256 bit AES-GCM keys. This approach works because the secure enclave provides measures against bruteforcing and tampering.
There is some controversy that I can't find an explanation for in any whitepaper, specifically here: https://support.apple.com/en-us/HT202303 where it reads "(...) this data remains secure even in the case of a data breach in the cloud. If you lose access to your account, only you can recover this data, using your device passcode or password, recovery contact, or recovery key." because that implies off-device use of the PIN, so those measures are lost. There's no further explanation that I could find about that. Some previous discussion about that particular point here: https://news.ycombinator.com/item?id=33897793&p=2#33900540
Uses SRP to let the device prove to iCloud HSMs that the user entered the correct pin, without ever sending it over the wire. The HSMs have similar protections for brute forcing, etc.
From the docs I have a fairly high confidence entropy is 256 bits for iCloud Keychain. I have much less confidence on Android, but I'm still researching... :)
Sure, but if that key derivation function is protected by a "you get 10 attempts then we wipe the keys" safeguard, the effective entropy is much higher. The question shouldn't really surround the effective entropy of the PIN, but rather the systems in-place to protect bypassing safeguards in the key derivation function which render the actual entropy of the PIN irrelevant. There probably isn't no way around that safeguard, but as more of this gets moved into trusted compute silicon the level of sophistication required to breach it goes up; and is one hardware revision or operating system update away from being made moot again.
This thread really smells like https://xkcd.com/538/. Three things you have to remember, that are far more important than any of the concerns you have:
1) The effective entropy of the current system (passwords) is "shrugs shoulders fuck it not our problem". Services can enforce password entropy requirements. They cannot effectually require users to use a unique password. They also cannot forbid users from writing the password they use in a .txt file on their desktop or post-it note or throwing it in Apple Notes (EVERYONE does this outside of our bubble. Apple Notes and Excel are the #1 and #2 password managers on the planet). A six digit pin + hardware TPM key derivation is, at best, the same thing that was guarding how most people store their passwords anyway, and in many cases far better than the current state (if a user's device has no E2EE, or if they're syncing their passwords.xlsx file with Dropbox, etc).
2) Passkeys do not and are not designed to protect against nation-state level attackers. Passwords weren't either. They also don't protect well against the "grab a hammer and beat it out of him" threat vector; you're going to give up your password, and tomorrow they'll probably have your iPhone and your passkeys will be disclosed as well. Passkeys are designed to protect against unsophisticated (and even moderately sophisticated) attackers; phishing, data breaches, etc.
3) If you want higher tiers of entropy guarding your passkeys, you can do that. 1Password, as an example, already has this [1]. They store passkeys, and encrypt those passkeys with their two-level account & master password keys. Done! If you don't like 1Password, you can roll your own, and I'm sure OSS password managers like gopass/keepass/etc will eventually add this. Passkeys/WebAuthn don't prescribe to anyone how you store the private keys; Apple will do their thing, Google will do their thing, you don't have to use them, many people will, and they'll be better off (see point 1).
> Sure, but if that key derivation function is protected by a "you get 10 attempts then we wipe the keys" safeguard, the effective entropy is much higher.
Thank you. 100% agree.
> Passkeys do not and are not designed to protect against nation-state level attackers
I've been mulling over some use-cases where this is important, hence the deep consideration over entropy. 100% not a huge deal for the passkeys case for many 9's of people.
You're forgetting Oyler's Law of Passwords: Humanity will be forced to try each wrong approach to passwords, one at a time and trial-and-error, for all eternity.
Slightly off-topic: If a website will not let me register and complains that my password is too long, they're still storing that in the underlying database as a properly-salted (modern algo) hash, right?
Tied to a phone (as opposed to some security-specific device like a Yubikey) is a terrible idea.
It ties your authentication to something that is often lost or damages, but more importantly, something that is controlled by a third party (apple or google) and requires an expensive monthly subscription to yet another third party (your cellphone company).
TOTP is not tied to a device which is why it's a beautiful solution. You can store it where you wish under the controls you wish and back it up as you wish. You are fully in control, dependent on nobody.
> it seems strictly worse than a password + password manager
Your password manager is likely the exact same thing. The underlying implementation of this is typically a system or third party password manager which added a public key-based credential type for sites. For an Android phone, this is Google Password Manager by default. For iOS, it is iCloud Keychain. Third parties like Dashlane and 1Password have indicated support for passkeys.
I would have thought your interpretation would be that this was strictly better. Even if the credential database leaks for a site, the attacker can't do anything with it - all they have is a public key, specific to that one site.
> Or at least just having proper 2FA.
If I use my android phone to log into a website, I have done 2FA. I have physical possession of my phone, and have used a gesture, PIN or biometric to confirm who I am.
The difference is in the password case, the website has no idea that I did that - all they saw is the password. With a passkey, it is possible that a site would recognize that I did a stronger, multi-factor authentication.
This may have varying strengths as a physical factor - say, provisioned database of credentials onto a device using MFA vs a FIPS-certified security key fob, but I would still argue it is "proper" 2FA.
It looks like a good change for the average user, a secret stored on the device is likely a whole lot safer than just having a password. Having it as the only factor seems less secure than password + good extra factor like TOTP on device though.
I also wonder how a lost/broken/replaced device is dealth with, especially given Google's less-than-stellar account lockout history.
edit: I guess this is still MFA since you need both the physical device and a fingerprint and phone unlock code
You're not. You're storing a private key on a device, and using something like a fingerprint or pin to unlock it and use it to authenticate. The fingerprint data is also only stored on the local device.
Passkeys should still be on your local device. Account recovery should fall back to e-mail magic link or government credential proofing (depending on data sensitivity and threat model).
And when that last device dies in an accident or force major, what's next? Proofing won't work because if the solution is really as secure as it should be then neither party can have access in an unencrypted form.
Indeed I wouldn’t trust Google or Apple to be the only place my passkeys are stored. I’m currently a 1Password user and their upcoming support looks like it could address this issue (I’m not in any way affiliated with them)
Sure but this currently means a virtual authenticator that puts unwrapped passkeys in the same memory as other applications, leaving only the OS and no other physical measures to protect a direct-memory read. That might be acceptable for your threat model, but no other currently adopted WebAuthn authenticators work this way other than password managers that don't want to be left out.
Hopefully in the future OSs will have better APIs to allow third-party tools like 1Password to leverage hardware components like TPMs and Secure Enclaves to build a sync fabric that's not tied to the hardware vendor, but this does not currently exist and is not trivial to implement without significant consideration about phishing.
I think YubiCo and password managers have a tremendous opportunity here to partner up to build sync fabrics bypassing OS vendors that might not be as incentivized to provide these APIs now, but I don't believe it's moving, currently.
Additionally, when you say you wouldn't trust Google or Apple to be the _only_ place your passkeys are stored, it's likely that even if we can have third-party sync fabrics, that these will never be interoperable. I don't believe you'll be able to "export" a Passkey from your iCloud ecosystem and import it into the 1Password ecosystem as you can do today with passwords. Doing so would break assumptions about the strength of the authenticator as far as WebAuthn is concerned, and would weaken Apple's security posture as well. Instead you'd probably have to maintain _both_ sync fabrics independently with every service you sign up for.
Google has actually had this rolled out for some time. I've been using a Passkey on my account for the better part of a year. For whatever reason, they're just now announcing it.
What are the privacy implications for this? Are companies that see my passkey going to be able to link it to all my other accounts, or will each passkey be completely anonymous?
Passkeys are unique per Relying Party, in this case, google.com can only access passkeys for google.com. They can't even enumerate them, all they can do is pop up a dialog and wait for the user to select one.
The linked security blog post[1] has a lot more of the technical details and can clear up some of the questions/confusion that people have added in the comments.
Those guys should not work in identity and access areas. Period. Only one reason says everything: they provide no support. Customers will be left in the cold, minus all their belongings.
But they may separate into several companies to avoid conflict of interests, if they prefer, this time with proper support and everything. Or they can be forced to do so, if they are too stubborn and will continue running their dystopian playbooks.
So, the situation is not strictly technical, it's much deeper than that. A blog post won't make a dent.
I really wish these “password killers” would acknowledge that we will never eliminate passwords. Ever. There’s too many under-funded applications deployed out there that have no resources to add passkey support. Password managers are an excellent place to progressively enhance the user authentication story and could support more advanced schemes like passkeys while remaining compatible with the registry of deeds site from 1999. Instead, it’s always presented as some other thing (usually conveniently tied to Chrome) that you have in lieu of your password manager.
Actually I'd see a future where some of those password killers might replace passwords, even for some of the under-funded, under-manned applications out there.
What is necessary is a robust, simple-to-integrate standard for authentication, authorization and sessions built into HTTP. Such that all the "hard work" is integrated into common HTTP server software or load balancers, transparently. From an application perspective it should just look like your request getting HTTP_USER=someone HTTP_PERMISSIONS="stuff,foo,bar" HTTP_SESSION="0xdeadbeef", similar to what you get from HTTP basic or negotiate auth, but with a few more necessary features such as session, login/out and a permission model. Browsers would have to provide some proper UI for that, not utter crap like they currently do for HTTP basic or negotiate auth.
Then your centralized auth application can just talk to any old application in a very simple way, no need to deal with huge integration headaches like OAuth or stuff. And the centralized auth application can do all the fancy password killer, 2FA, magic or whatever special auth you need.
Yeah, none of big tech wants that, they don't want to make it easy for 3rd party.
Ideally there would just be standarized interface between "credential manager" and applications + some OS-enforced security (so password manager knows which PID sent the question about password or other type of credential).
Then we could have say pub/privkey or cert based authentication implemented there, app just asks for a credential for a site and cred manager asks user whether to allow it once or forever, and which credential to give.
The app then could garnish that with extra metadata so say firefox container feature, or different firefox profile could attach metadata about from which container or profile the request comes from, and credential manager could hand out different credentials based on from where it came.
The advantages are very poorly explained in the article.
Last time I read about this, you could use your phone or a FIDO key to authenticate. Like if the phone was close to the computer you could aithenticate the same way you can unlock your computer with your watch.
So either this new technology is so advanced lesser minds don’t understand it or it jus adds a more cumbersome authentication method instead of passwords and its adoption rate will be in single digits.
My takeaway is that this is infinitly more secure for those do not care about security - the "password1234" crowd, actually their account may even be secure from them logging in from now on -, for the rest it is about the same, but different.
Just a heads-up if you're planning to use passkeys with iOS/macOS: Might be fixed already, but last time I tried it out it seemed like iOS only stored a single passkey per domain. If you first store a passkey for a@domain and then later on store a passkey for a different user b@domain the a@domain passkey is overwritten without any warning. Or at least this seemed to be the case a couple of months ago when I tried it out.
For me at least it works. I have multiple accounts for the same domain and iOS/macOS prompt me to choose from the last one used, or I can choose to pick from a collection.
All the way back in iOS 15, when getting passkeys meant building an xcode app to access the developer menu and enable passkeys, I had no trouble storing multiple per domain when adding passkeys to GitHub. Maybe the site you were trying to use sent the same `user.id` for both requests? /shrug
That would only happen if the site isn't properly giving the passkeys identifiers. Having single passkey/username combo is working as intended, but it shouldn't be overwriting different usernames.
I'm still salty about this. Called it passkey too. http://www.multipasskey.com/susdemo/. Built this 5-6yrs ago and applied to YC. Crickets. Hope to see this take off, with my approach I made it where you don't even need to "register", you can go to a site and just have an account. I did the fingerprint, face scan, PIN approach for more security, but my favorite was NFC ring. Basically you have an NFC ring you wear on your finger. That way if someone steals your phone or takes it, you are protected. The entire thing uses a unique pub/pri keys for each site. Keys are backed up by shamir secret sharing distributed across your friends or providers you select. 100% of your keys are encrypted so I the provider can't see it, recover it or be forced to reveal it. Since each site has a key, one could do interesting things. E2E encryption for apps where they can't be forced to reveal a key. If you are using an App and want to send someone a message, the app can fetch the person's pub key, then an inbuilt editor outside of the App in our app will be used to compose the message and encrypt it. That way the App provider can't be forced to reveal the message, and they don't have keys either. Pretty much control in the hands of the user. The same approach can be used for a storage pod where you have a pod that stores your data that you encrypt and control. This is a good start, hopefully we can see the good ideas of this, AT protocol (account portability), keybase, etc all start to bear fruit.
What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
i say this every time this is mentioned... all these thing are mostly to help advertisers and fight spam and reduce cost on their servers.
theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor.
instead of vetting clients and giving them CAs, they just run your credit card for some hardware or subscription, and validate your login.
> theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor.
Identity systems aren't too technically difficult, the challenge is properly rolling them out and getting mass adoption. Which means getting vendors/users on board. It's a problem solved by power and politics, not technological innovation.
I recall Mozilla tried something similar around a decade ago, which was a good solution but didn't get any adoption. There's also been approaches like OpenID which were once popular, where you can have a single login, but they have the problem of third-parties aggregating the sites you visit. Who uses OpenID today? It's all been replaced by facebook or google login.
Part of the difficulty of using secure credentials is sharing them between devices. It's easier to involve a third-party like Google who can do this for you. The big-tech doesn't actually want to solve the problem entirely because they want some form of control: Either locking you into their service, or aggregating the sites you log into, or both.
They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
> They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
The user giving authority to access their information.
Biometrics are not it. Anyone can forcefully grab your finger and place it onto your phone screen. They can hold the phone up to your face.
Secure keys or passwords (actual authority) are only vulnerable to rubber-hose cryptanalysis, but you can use plausibly deniable measures to reduce the risk.
But don't mix them up. The mind is more secure than the body because information cannot be forcefully extracted from the mind. Yet.
I think a better solution for authentication is a combination of a cryptographic key or seed and a passphrase held in the mind. Keys could be provided by an NFC ring or smartwatch, which should be more difficult to lose or have stolen than a phone.
Bitcoin has a nice solution for cryptographic keys with BIP-32/BIP-39. You use a single master key to deterministically generate all others via a HKDF. The single master key is produced from a 12/24-word phrase plus an optional passphrase.
A good opsec for bitcoin is to have several copies of a phrase (which can be etched into stainless steel), so there is no single point of failure if lost/stolen, and you can use several passphrases for different wallets, which you don't write down anywhere.
You can use a word phrase with no passphrase in a "decoy" wallet and monitor on-chain if any bitcoin are spent in it. This would alert you that your seed phrase has been compromised but would not compromise your passphrased wallets.
To replicate this kind of decoy with passwords, you could store a login for some service which emails you if anybody logs in.
The decoy method also provides plausible deniability. There is no way to prove that there exists any other keyrings with other passphrases, and there is also no way to prove that you have provided every possible passphrase, even if you have provided all of the ones you do use.
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform.
This is the concern, but exporting passkeys to other ecosystems seems like it'll come with time, even if via third-party tools or like how browsers will prompt you to "import your <passwords|passkeys>" upon setup.
Call me a cynic but I'm convinced that won't be happening anytime before critical mass adoption of these companies' own solutions, and either defeated acceptance of this new norm or abject incomprehension by whomever remains.
I think they are referring to the EU's aggressive data surveillance and zero expectation of privacy to government organizations. While the EU has been very pro customer to business privacy they are vehemently against anything that lets anyone hid anything them the government.
I’m a cynic too, but I’ll also be optimistic about published statements. Goggle said they’re committed to supporting 3rd party passkeys when they announced android support. Apple, not so much though. I am hoping Google just does the right thing and makes this table stakes.
> use this to tether and lock you in to their platform.
You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true.
Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome instance via QR/Bluetooth.
There's absolutely nothing stopping you from providing your own implementation as long as it complies with the "hybrid transports" part of FIDO CTAP 2.2.
You're suggesting that using a tunnel service is the recommended way to be a platform agnostic backend. But that doesn't cover the scenario where your password manager is running on the same device as the one where the user is performing the login, and all the UX/UI refers to using a phone to scan the QR code. I guess you could snag the QR code using platform accessibility features, but that's a real silly hack. Just let me advertise some mDNS service record for "authenticator" and require me to advertise a pubkey and let the user select/allow me once and remember the decision until the pubkey changes so that I'm trusted backend without the QR scanning rigamarole.
Yes, I'm waiting patiently in the wings. Sadly when I asked Apple's Passkey team about supporting this, they said it wasn't on the roadmap (though they carefully didn't say never, it still doesn't instill much hope). Once this missing piece becomes a required part of the standard, I'll stop holding my breath and get super excited about passkeys.
The article says "Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN."
Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on iphones and macs?
As a user, that's sounding a lot like platform lock-in to me.
And as a developer, if I want a way for users to log in without a password, and I don't mind that login mechanism being reliant on the user's account with apple / google / microsoft - wouldn't I just add a 'log in with apple / google / microsoft' button to my login page?
No passkeys are just normal private keys. You can store those private keys in a particular platform's secure key store which on phones can be decrypted/made usable when you unlock the device. But there is nothing stopping you from transferring these keys to a different device if you wish.
True, Passkeys are private keys at heart, but relying parties can verify whether they are stored in software or hardware by requesting/requiring authenticator attestation when they are created.
And certain hardware from certain platform vendors doesn't allow exfiltration of private key material. Though I don't think this can be specified by the relying party so that's how Apple stores all keys in keychai. I sincerely hope it remains best practice for relying parties to not require/use the platform attestation feature to lock users onto "trusted" platforms.
Device binding can be required by relying parties! They can just refuse to accept credentials without attestation statements signed by a trusted party.
My government e-signature service does that: I can’t even use a Yubikey, ironically, because that’s not "FIDO level 2 certified". I had to buy a more or less completely unknown brand instead (of which a government affiliate is apparently the exclusive reseller in my country…)
That's more like vendor binding. Apple’s credentials aren’t device bound so “pinning” to Apple as a vendor by requiring attestation doesn't ensure a credential is device-bound. Not that you don’t have a point, generally.
So if I transfer a passkey to my Yubikey, which has a single button and no pin, thus achieving 1-factor authentication - is that undetectable to the website?
Because sources like [1] say that "A passkey can replace a password and a second factor in a single step" and "a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern" - isn't there something in the standard that ensures the second factor is maintained?
You wouldn't transfer a passkey to your YubiKey. You would enroll it as another device that can be used to login. Like right now on my Google account I have an iCloud passkey and a Windows Hello passkey since iCloud can't sync a passkey to Windows (yet).
Hypothetical political journalist just lost both his Yubikeys when his office and home were both targeted. He still has an off-site backup of his passkey. How would you envision this working?
I'm unfamiliar with the particulars of passkeys, but with hardware tokens I've used before, you'd log in ASAP and unenroll the keys you've lost custody of.
If the site insists on UV (User Verification) rather than UP (User Presence) a device which has no way to verify the user should reject that.
If your site insists on the device providing a broad identifying signature (the specification says devices classes identified this way ought to consist of 10k+ devices, and in most cases a manufacturer will just identify particular models, like OK, this the model we made in 2019-2021, now we're re-tooling to make the newer model lets give it a new identifier) and the user agrees (I always refuse if asked, the documentation advises you just don't bother asking) to provide this, then you can see OK, it's a Yubikey Model 6J, I think that's (delete as appropriate) fine / not fine. This is obviously a large piece of extra maintenance work, hence it's advised you should not do it.
> But there is nothing stopping you from transferring these keys to a different device if you wish.
Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone.
There's also nothing in the spec that forces any provider to allow transfer, so I don't expect that to change any time soon. And even if you can transfer your keys (which you can't) there's also nothing in the spec other than "please don't do this" language that stops a site from using attestation to restrict sign-in from other devices that you've transferred your keys to.
> Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone
The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. They are on all devices.
In addition, the 'share password' option on Apple devices works with passkeys. To deter social engineering, the person needs to be in your contacts, and in proximity to receive an airdrop.
There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
> The google password manager and Apple devices will sync private keys as part of the password manager sync fabric.
This is really misleading -- you can not move a passkey "vault" from an Apple device to an Android device without doing a per-password operation. There are no Open implementations of a passkey authenticator and there is no standard format defined in the spec for how to do mass movement.
There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?
I mean, you bring up Airdrop. I feel like I need to check, is something changed and that now works on Android devices? I'd love to be wrong about this, but Apple's documentation doesn't mention airdropping a passkey to an Android device: https://support.apple.com/guide/iphone/share-passkeys-passwo...
That kind of platform lock-in seems like it would be an important caveat to mention when talking about backup. But I never see stuff like this mentioned.
I don't see how anyone could genuinely claim that passkey portability is exactly the same as an SSH key or password. That's just not true. Authenticating a second device per-site is not the same thing as a cross-platform backup.
> They are on all devices.
They're not on a Linux desktop. If you want to use passkey on a Linux desktop, your options are to authenticate through a secondary proprietary device or to use a Yubikey -- for all practical purposes a locked down device which can not be backed up (no, buying a second Yubikey and manually adding it site-by-site is not the same as backup).
> There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
And again, nothing in the spec requires it. This is asking for vendor lock-in. If it's not a big deal and everyone's going to support syncing across ecosystems, then it shouldn't be a big deal to add a standardized API and sync format to the requirements for being a certified provider.
> There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?
I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
> And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
There also hasn't been anyone yet who has tried to define what that interchange format should be.
> And again, nothing in the spec requires it. This is asking for vendor lock-in.
There are a broad range of passkey providers, from open source hardware to FIPS certified solutions to solve government compliance requirements. Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
But those government agencies are specifically investing in that hardware because it _doesn't_ lock them into one vendor. Any other vendor who can meet their security requirements can sell into that space.
> I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
Do you really not see the difference here? Passwords are inherently resistant to vendor lock-in in a way that passkeys aren't. And honestly, not to call you out but we're back on this again:
> of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
This is not representative of what the ecosystem actually looks like.
Apple and Google have announced zero plans beyond "we're looking into it" to allow open interchange with arbitrary 3rd-party clients. Chrome on Linux doesn't even support native passkeys at all. The most hopeful development I've seen in this space is Bitwarden. 1Password was billed as the solution, but I don't see any plans from 1Password to support porting to other password managers.
And any of these platforms blocking 3rd-party syncing is a big deal. If even just iOS decides "no, we won't allow that", that alone is a huge vendor lock-in that needs to be acknowledged.
So what plans can you point me towards where Google/Apple is announcing that they're going to build a generic API for exporting passkeys from the phone? Do they have a timeline up? And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
> Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
My worry is that most of them won't, and that hardware attestation will get rid of the rest. Let's say there is a client that supports moving passkeys around. That still doesn't change the lock-in potential for all of the clients that don't, it doesn't mean users will be able to migrate to that client once they've been locked in. It doesn't mean that services won't block authentication using that client. A good standard should block this all off at the source; it should (to borrow from the Chromium dev team) encourage developers to fall into a "pit of success."
We already ran into this problem with 2FA codes on mobile devices. How long did it take Google Authenticator to support backup? That has impacts on the ecosystem beyond just "is it possible for someone who knows about the issue in advance to choose a client that's more open?"
> There also hasn't been anyone yet who has tried to define what that interchange format should be.
Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
I mean, they're the ones that want me to get rid of passwords. If they want me to adopt their solution, they need to have an interchange format. It's kind of their problem more than it's mine.
> Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
Again, going back to this philosophy of the "pit of success" it should be harder to lock a customer out of backup than it is support portability. Portability should be the default, and it should be work to make that g...
> So what plans can you point me towards where Google/Apple is announcing that they're going to build a generic API for exporting passkeys from the phone? Do they have a timeline up?
I'm not privy to their priorities or timelines, no.
> And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
But other companies with a history of being open here also do not have the feature yet. I am equally non-privy to their priorities or timelines.
If you want to say "passkey implementations do not have a bulk export/import feature, which makes it time consuming to switch between implementations", that is 100% factual.
I would not qualify this as a "lock-in", any more a phone that needs to get its software reinstalled is "bricked". And I wouldn't take current state to imply some inherent permanent ecosystem-wide rejection of user backups and data portability, when many vendors have implementations that are still in beta.
> My worry is that most of them won't, and that hardware attestation will get rid of the rest.
There is a great deal of worry about hardware attestation even by the vendors you are likely most concerned about. Apple for example not only removed their attestation, but now anonymizes the authenticator via a zeroed AAGUID.
No matter the vendor, their users (and the overall ecosystem) will suffer if relying parties build allow lists of acceptable authenticators, and deny all others.
That said, I do suspect the ultimate goal is to have sites be able to tell if an authenticator can allow them to shortcut additional authentication checks or not. It could be those websites give a more complicated authentication process to passkeys which do not meet their physical factor requirement.
>> There also hasn't been anyone yet who has tried to define what that interchange format should be.
> Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
Putting aside that I can't speak as to whether there is or is not an effort underway there -
It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
If passkey providers hypothetically want an interoperable interchange format or protocol, they can try to standardize it in a number of places including under FIDO Alliance. Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.
> Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
I don't think this fixes your overall concern. There's no technical measure to prevent implementations from limiting backup/restore even if you make all authenticators anonymous.
Likewise, I don't believe websites would choose "friendly" credentials over "strong" ones. They would let the system survive or fail based on the user feedback/complaints of "strong" mode.
> At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.
> > Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.
How would they? None of the software involved here is Open Source, I can't open a pull request for any of this. And the backup/restore isn't going to work with any of the major players.
It's kind of striking that there literally isn't an Open Source provider supported on any of the major platforms. Let's say you build an Open Source one for Linux. Is it usable with Chrome? No, Google has no plans to support that. Does Mozilla have a working implementation? Also no.
Is that the FIDO Alliance's problem? Sort of? I mean, they want me to believe this is an Open standard. How many "Open" standards have zero officially sanctioned Open implementations of the standard?
> It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
The FIDO Alliance has more than two members. Microsoft/Apple/Google are already in talks about how to build out passkeys. And they're the players that really matter here. Whatever standard they come up with (or decide not to come up with) is going to dictate how the rest of the ecosystem moves.
But again, they're the companies trying to tell me this is an Open replacement for passwords. I feel like it's kind of on them and their alliance to prove it.
I'm with you, Dan. It is grossly irresponsible for the industry to be pushing passkeys while fundamental problems like transferring from one ecosystem to another aren't solved yet.
We need to hold their feet to the fire and actively push people away from using passkeys until this problem is solved.
> actively push people away from using passkeys until this problem is solved.
I guess this is where I'm arriving, too. Passkeys are a nice idea in theory, but the whole thing is too early in development to use or recommend to others at this point.
> I'm personally hopeful that there will be a solution here eventually to streamline switching platforms and passkey managers, once someone prioritizes it.
This is hopelessly naive.
We need to be actively making a lot of noise and sabotaging industry efforts to use passkeys until the respective vendors solve data portability.
This is incorrect. Passkeys on iOS and Android are locked to Apple and Google account ecosystem. They cannot leave their ecosystem. Also, only the OS platform can use the BLE transport for CTAP2 protocol on iOS and Android devices. That is, a 3rdparty app (like 1password) cannot implement a FIDO2 BLE or NFC authenticator on iOS and Android – which is a huge handicap.
Ever site I've accessed with a passkey lets you tie it to an existing account with a username/password, Google login, Apple login, iPhone, YubiKey, etc. I've not used a passkey where that was the _only_ auth I could create on an account.
The title of the article though is "the beginning of the end of the password." Google seems to be making it clear here that they eventually want to get rid of other login methods, they just don't think it's mature enough yet for them to do so.
I don't see any indication that Google is looking at Passkeys as just a faster way to log in without a password. They want to eventually replace passwords entirely.
But they’re not the only one using passkeys. If you could have multiple passkey logins to an account, it’s not earthshattering if one of them becomes unavailable.
That's the intention yes, and it's a whole 'nother conversation about how many passkey-eligible devices people actually do have in reality, and how often they travel with all of those devices on their person at the same time and how often they're going to actually go through the extra steps of logging in on their secondary devices and adding a new passkey.
My parents are a good example of this, they have recovery options set up so that we can get into their accounts if they die. None of those recovery options are compatible with current passkey implementations, and their phones might be the only computers they have that are capable of storing passkeys right now. I myself have exactly one device that's capable of acting as a passkey authenticator right now (my phone) and I suspect that'll stop working if I De-Google it and then I'll have zero usable authenticators. I'm not sure how I would add redundancy to a passkey login without buying additional hardware. It's not like my password vault where I can sync it to basically any computer or flash drive.
But that's a separate conversation. Regardless, the goal is the elimination of the password, a lot of coverage and advertising has centered around that. Passkey isn't in the long run designed to be supplemental to traditional log-in methods, it's intended to replace them.
What it does imply is that if you store your passkeys on Apple's keychain, migrating to Android becomes that much harder. (I assume that Google will provide an implementation of passkeys on iOS when that becomes available as an API, but it will be a cold day in hell before Apple provides access to its keychain on Android.)
The solution is to not use Apple's keychain for passkeys (and really not use Apple's proprietary services for anything at all), but we can't depend on people to have that foresight.
> Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on iphones and macs?
The authenticator is given a lot of leeway in how it does authentication. In the Apple platform case, it is "the user authentication on the device which is on the iCloud account and has set up iCloud Keychain".
So on my Mac I can use TouchID. On my phone I use FaceID. Both allow me to fall back to the device password (such as when I have the lid on my Mac closed).
Not now, but soon. Bitwarden's public statements over the past year, and their acquisition of passwordless.dev, would seem to indicate that they're working very hard on adding passkey support.
What you describe sounds awesome. Is it still something people could use? If the WebAuthn protocol gains broader support because Google/Apple are pushing passkeys then anything that speaks WebAuthn should be a viable option, right?
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform.
This is not what they want. They want to a) ensure passwords/accounts aren't being shared to ensure a single account is tied to a single user. They want this for all apps so they can recognize revenue for every user. b) They want more information on you as a user (as opposed to your family member on the same account). The wet dream is per-device, per-user profiles. Possibly even different [additional] costs for each attached device.
That is their goal. Big Tech all want this. That it increase friction to migrate is a side benefit (honestly not so much more than with passwords now). That it happens to benefit users is the lure to draw you in.
You don’t need to share them because you can enroll more than one for a given account. So for example if 3 people are sharing an account, you can enroll 3 passkeys for that account and they each have their own access.
I don’t see any way that passkeys kill account sharing.
It's not fear mongering to have and express concerns about a technology. Especially a technology that many people want to force everyone to use whether they want to or not.
In fact, it's important that people do this so that the invalid concerns can be put to rest and (hopefully) the valid concerns can be mitigated.
What the other user says is that maybe those companies will only let 1 device per account to be registered. So you can’t have 2 devices to login. Harder to share.
In this case, Google, that isn't true and just they're mostly treated as special Security Keys ("yubikeys" etc).
To limit it to just one defeats the purpose of all this work. You really will only see that where there is a technical limitation (like... why does AWS only allow a single hardware key per user? If you setup SSO then you can have any number of keys)
I think it's simpler than that. Expenditure is linked to trust. Companies and platforms that erode trust, make less money in the long run - they have to continually exert energy to attract customers. Companies / platforms that focus on building and retaining your trust have to work less hard to have you part with your money.
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
The value of many of these schemes is authenticating under your google/FB identity (email, phone number, org affiliations). It makes a lot of sense for centralized identity providers to do this because they already know who you are and how to authenticate you.
There is a growing untapped market for the authentication and secure use of of pseudonyms. For instance people that want to run a blog and interact in social media under a name that is not connected to their true name. Or some Senator wants to play video games but might be worried that it looks frivolous. This is a setting where something like MPK really shines. I believe over the next five years we will see an ecosystem around a pseudonymous web. MPK might have just been too early as that ecosystem isn't quite here yet.
You patent your things, then disseminate. Your ideas will be burglarized, stolen, reintroduced and shown as an invention of someone else (who is a lapdog of given entity).
Yes, I understand how phishing with 2fa works. But to me, passkeys sound like 2fa with your fingerprint/smartphone PIN? What's actually different there?
The difference is in step 4. With SMS or one-time code 2FA (or passwords) you're just entering text into a website, and nothing verifies you're interacting with the right website. With passkeys or FIDO tokens, though, there's a cryptographic protocol that considers the domain: your fingerprint/PIN isn't sent to the website.
So, evil.example tries to log in and triggers the passkey thing on my smartphone. My smartphone asks "Do you want to log in to good.example?" Because I'm currently being phished and didn't pay attention to the URL "evil.example" anyway, I will confirm this on my smartphone and evil.example is granted access to my account. I don't see how this is more phishing resistant than current 2fa. How can my smartphone know whether I'm interacting with the correct website on my laptop?
This is maybe an oversimplification, but the token that your phone gives your laptop includes "only valid for good.example". Your browser on your laptop then knows not to send it to evil.example.
> How can my smartphone know whether I'm interacting with the correct website on my laptop?
Because when evil.example requests the passkey it has to do so through browser APIs [1], and it can't lie about its domain name. Your browser is what reaches out to your phone, which is how your phone learns what domain you are actually on.
Not if the Passkey was synced (ex: you used iCloud keychain). If the passkey was not synced, then I would have to assume it would be the same if you lost a physical hardware key.
Not yet, but Google wants them to become ubiquitous. So in that (far) future, backing your passkeys up in a cloud (that is also protected by passkeys) doesn't help
i’ve got passkeys enabled on github, cloudflare, google, twitter etc via apple’s passkey implementation (https://support.apple.com/en-gb/guide/iphone/iphf538ea8d0/io...). they all implemented passkeys as an alternative to sms OTP. very easy to use, and should be better than sms, but still haven’t seen full on login using passkeys. if anyone knows of such a site i’m curios how they implemented it.
Those passkeys are either insecure or unreliable. Let me explain:
Those passkeys are asymmetric cryptographic keypairs where the private key is securely stored on a device, unlockable (for use, not reading) only by convincing your devices security processor to do so by pin/fingerprint/pattern. Which in itself can be secure, given you do trust that magic security processor (which you shouldn't, see yesterday's news for example). However, if that key cannot be read, you cannot make a backup of it, so it will be unrealiable and easy to loose. The recovery process will either be insecure and prone to social engineering, or unreliable because proving your identity will be nigh impossible without that passkey. Now one could allow backups of a passkey, but then that passkey would be as insecure as a password. One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances.
The point of passkeys isn’t to be perfect — the point is to replace passwords, which are already far more imperfect than passkeys. The bonus points with a password is that every site that uses them has to secure them properly and theft of passwords, in plain-text, hashed, etc form is common.
Imagine for a moment that instead of all the time wasted on this, we just implemented a protocol amongst the browser makers which allowed a secure password prompt to be requested, and required strong-hashing before sending anything over the wire?
If you hash before sending anything over the wire then the hash of your password is now your password, meaning that if it leaks it amounts to basically the same as your password leaking. Granted, applications may choose different hashing algorithms, provide their own clientside salts, etc. which would be really nice. To be fair, I believe more systems should be doing this nowadays, it's really weird to have to send your actual password to the website if a hash would suffice. Then the website could store the salted hash of the salted hash of your password in their database.
Programs such as Bitwarden already do this, where you send the hash of your password to the server instead of the password itself, because from the password you derive the decryption key and you never want that reaching the server. You then use that hashed password as the authorization password, but the client uses the actual password to decrypt the delivered password vault.
If a common browser protocol required the password to be salted with an application supplied value and then rehashed with the domain name it's served on, there'd be no way to phish a password.
The value the user's browser sends back can't be reversed, so any website prompting from the wrong domain would only ever see an incorrect hash, rather then the cleartext as it does now.
I find this to be a regression in terms of usability and security as well.
On top of what you mentioned, it also fails really hard when someone has access to you and your trusted device (which will be the smartphone in most cases). It's already an issue allowing easy access to smartphone content, it will extend it to any account using that method of authentication.
As an administrator, I hear you, but we have to adapt. Passwords are awful. On the whole, the effort and energy spent training people on passwords, battling phishing, dealing with password managers, cleaning up from breaches, and more… passwords can't die soon enough.
FWIW, asymmetric PKI is technically mature and relatively easy to implement in most applications (without "vendor lock-in", I might add to comments upthread), and there are ways to address most of your concerns about key loss and recovery beyond what you describe, as by the ring of trust scheme Apple uses, for example.
The only way through this is forward. I'm confident it really will get better once passwords become a smelly indicator of bad security practice.
I'm looking forward to such glory days. Right now, however, none of the solutions available are ones that I could live with if I had to use them for everything. For one or two very sensitive things, sure, but for everything? It's less of a pain to use long, random passwords.
This is just like using a long random password, except that it's cryptographically verifiable without ever leaving your device.
If passwords are like playing poker with your cards facing out, Passkeys are like playing with your cards facing in. Your secrets remain under your full control at all times. Nothing sensitive is sent over the wire.
Yes, for everything. Those who've implemented it so far have done a great job at making it /easier/ than handling passwords.
If you've ever used ssh with keys instead of passwords, it's the same thing, and it's so much easier while being more secure. A rare convergence.
The way this typically works is that the keys are stored in an encrypted file, which can be backed up securely as-is. It can also be copied around and sync'd to other devices.
Of course, this means the authenticator app/service that needs to use the private keys to respond to challenges has to be able to decrypt that file, which means logging in to it. Authenticators balance convenience with security in terms of how often you need to fully log in to it. They are also often configured to require a light-weight authentication on each use (fingerprint, face, pin).
With authenticator apps handling the private keys, secure backups should be easy and automatic. Things should improve since the people using passwords now who don't have a secure automatic backup mechanism for them and switch to passkeys will probably end up with an authenticator that does it automatically.
(Recovery processes will still exist and can still be an issue.)
That's literally part of what makes a passkey a passkey (v.s. just a WebAuthn credential), so that's a given.
> as insecure as a password
No. Passkeys can't be phished, passwords can. Passkeys can't be cracked after a data breach. Passwords can. Passkeys can't be set to something easily guessable. Passwords can. Passkeys can't be written on a post-it note and taped to your monitor. Passwords can. Passkeys can't be reused across multiple sites. Passwords can.
There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".
> One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances.
What? Malware stealing your password is "more secure" than malware registering it's own malicious key to each individual site it wants access to?
> No. Passkeys can't be phished, passwords can. Passkeys can't be cracked after a data breach. Passwords can. Passkeys can't be set to something easily guessable. Passwords can. Passkeys can't be written on a post-it note and taped to your monitor. Passwords can. Passkeys can't be reused across multiple sites. Passwords can.
Passkeys don't need to be cracked after a data breach of your backup provider, they are just usable, right there.
> There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".
Passkeys are accessible permanently on some devices unencrypted or decryptable in the filesystem, if part of e.g. a backup. Whereas passwords are usually only accessible temporarily. That makes the attack surface top copy over some passkey far larger than for sniffing a password.
You seem to be under the false impression that passkey databases are stored completely unencrypted and unprotected on disk or in the cloud. Obviously those details are implementation-dependent, but I don't know of any passkey implementation that works that way.
Let's take Apple's implementation as an example (since that was the one I could most easily find information on). Their implementation stores passkeys in the iCloud keychain[1], which is end-to-end encrypted[2].
> Passkeys are accessible permanently on some devices unencrypted or decryptable in the filesystem, if part of e.g. a backup. Whereas passwords are usually only accessible temporarily.
I think you're mixing up server-side and client/sync-backend-side compromises here.
For the former (i.e. a compromise of hashed passwords and their corresponding salts), you'll need to rotate all passwords since the hashes can be brute-forced. For passkeys, all an attacker gets when compromising a service's database are public keys that can't be brute-forced and key handles that don't give an attacker anything without the corresponding authenticators.
For the latter, the situation is exactly the same for passkeys and passwords in a password manager, i.e. both are as secure as their on-device storage and encryption in transit and rest at a synchronization provider (if any).
Maybe for browsers on Windows it'll default to storing the key purely on-device, but especially with iCloud Keychain the key is not encrypted by the on-device processor.
This does not make it as "insecure as a password". It does mean you can use root/OS access to exfiltrate keys, but it closes the following security holes that affect passwords:
- keyboard sound-based exfiltration[0]
- visual exfiltration (someone recording you enter your password, or looking over your shoulder and memorizing it)
- credential stuffing, where people who reuse passwords get pwned when the same leaked password is used on other websites
The idea seems to be that you will either trust a provider like Apple or Google to keep you private key safe and let them sync it around, or you will create a passkey for each device that you use. If you lose the device, deauthorize the passkey. If you somehow lose the passkey itself, create another one, either by using an older form of authentication, or by creating using a different device to authenticate. There is no need for passkey recovery or backup.
It would be a bad and dangerous idea, if what you said was true; but it isn't.
Passkeys are just asymmetric key-pairs. There will be a variety of client-side implementations. Some may make export and backup difficult or impossible. Others, such as 1Password's already extant implementation advertise backup and synchronization as a feature! There is nothing about the passkey standard which prescribes the reality you fear.
> Now one could allow backups of a passkey, but then that passkey would be as insecure as a password.
Wrong, absolutely and entirely. Its still more secure, because its an asymmetric keypair, and you're forgetting about the far more common attack vector against password disclosure: service breaches. That's how attackers learn about passwords by-and-large. And this is not just some nice-to-have side-benefit of passkeys: its a core motivation of this standard. With passwords, a service breach compromises not only the accounts of every user on that service, but potentially every other account every user has, globally, because of password sharing. With passkeys, all of that is resolved.
Even if we end up with a system that is the same level of effective client-side security, which is also extremely wrong, the net security of the system will be vastly improved because service providers aren't storing the private key used to authenticate user accounts.
But the client-side security is also substantially improved, because passkeys have much higher phishing resistance.
Disclaimer: I work for Google but nothing I say here is Google's opinion or relies on any Google internal information.
I'm not surprised that Workspace accounts weren't included in the initial rollout. Workspace setups have interesting requirements that aren't necessarily there for personal accounts. For example, under some circumstances, if an employee gets hit by a bus, and there is critical business data which is stored in the employee's account, an appropriately authorized Workspace admin is supposed to be able to gain access to the employee's account. But what is the right thing to do for passkey access? Especially if the user uses passkey to authenticate to some non-:Google resource like, say, Slack which has been set up for corporate use? Should the workspace admin be able to impersonate the corporate employee in order to gain access to non-Google resources via passkey? What about if the employee (accidentally) uses their corporate account to set up a passkey to a personal account, such as for example E*Trade? Maybe the Workspace admin should have a setting where passkey creation is disabled except for an allowlist of domains that are allowed for corporate workflows? It's complicated, and if I were the product manager, I'd want to take my time, understand all of the different customer requirements (where customer === the Workspace administrator who is paying the bills) before rolling out support for Workspace accounts.
How do you handle delegation in this case? Let's say I want to delegate access to my account to a partner/friend/employee on a service that doesn't support multiple users per account, charges extra for it or outright doesn't want me to delegate access to someone else (so it's not always possible to rely on the website's cooperation).
Currently I can just message them the password or even write it down on a post-it note and they'll have everything they need to complete the task as me. How does it work with passkeys? Does the spec allow my passkey HSM to securely share the secret by encrypting it against the recipient's passkey HSM? Can it use the concept of leaf certificates to sign a short-lived certificate allowing access to that credential without sharing the credential's secret itself?
I can't advocate for passkeys until the concerns above are resolved. The push for passkeys seems like yet another attempt to remove control from the user.
You can create a passkey for your account on their device, e.g. by selecting "Use another device" when creating it, and scanning the QR with their phone (their phone does not need to be signed in to your account).
This is what I love about passwords. They are tangable and understandable. I would have loved if we could move towards a solution that has the benefits of passkeys (prevents phishing, strong secret, doesn't seen the secret to the server) without ditching the underlying secret being a somewhat human-readable password. It seems that in-browser password-managers get us 99% of the way there. I would have loved to do something like adding a PAKE system to regular passwords rather than a new system built on top of non-human readable keys.
I'm sure we will gain the ability to dump the key to a file or write down onto paper at some point but it seems that we are starting from the wrong end.
Also tangible and understandable is a registry of users who have access to your accounts, that allows you to grant and revoke access (at possibly different levels), without having to reset all your own credentials.
I've got to quit commenting, but humans are undeniably the weakest link in security. While I understand the perceptions and even share some of the concerns expressed in this thread about the loss of control, reverting to a human-readable string as a key would only regress the whole scheme to something that is, once again, as easily compromised as a system protected only by any other human readable string.
We just have to cultivate new habits. Enroll multiple keys or devices. Print the backup codes and put them in the fire safe with your birth certificate. Give trusted friends and family access to recover your account in the event you lose the credentials or get hit by a bus. It's a few extra steps up front, but once it's working, it's so much easier.
Honestly, there are so many people who never have any idea what their password is, so they end up resetting it all the time... passkeys is a net-positive. Now they don't even have to remember anything.
> It's a few extra steps up front, but once it's working, it's so much easier.
It's a few extra steps per site. Every time you get a new device you need to go back to every site you've ever visited and update the credentials. It is maybe feasible for a few important accounts but it doesn't scale.
Whatever solution we have needs to be syncable and able to be exported to a safe once and continue to be usable by new sites and devices into the future. People aren't going to print out their credential list every month to update the fire safe.
The now-unfortunately-named "Password managers" help with this by providing various mechanisms to sync keys with multiple devices, so that every time you get a new device, you simply need to authenticate and transfer the key store to the new device.
The device's hardware security facilities are there to protect the keystore. They aren't /the/ keystore.
Find a key manager. iCloud Keychain, Microsoft Authenticator, Bitwarden, something. Use that. Concerns about migrating devices dissolve away.
The accounts and services I use that support passkeys also support some form of account delegation, recovery contacts, legacy contacts, or family sharing. This includes Apple, Google, Microsoft, and self-hosted services through Authentik, Authelia, and Keycloak.
My experience is not necessarily representative, but I am not sure how big the issue you describe would be, in practice, for the majority of users, who will be, by and large, using one of these services.
What is clearly a major issue for the majority of users is unauthorized account access and resource theft through the use of easily-phished account credentials protected by nothing more than a character string being passed around in text messages and sticky notes.
> What is clearly a major issue for the majority of users is unauthorized account access and resource theft through the use of easily-phished account credentials protected by nothing more than a character string
Is this a major issue though? I think it’s pretty minor, not being able to share or backup my passwords is a pretty huge issue in my books.
1,109 comments
[ 3.2 ms ] story [ 382 ms ] threadIs my understanding correct that if I only used Passkeys that I’d be permanently locking my account to a third party service to the vendor I used to login with in the first place?
I’m also a bit worried that this permanently entrenches these as the platform vendors because no one is going to port to a new platform unless you’re already a major tech company (maybe).
If your desktop/laptop has TPM, TrustZone or other similar devices, it can register Passkey too.
[1] https://9to5google.com/2022/10/12/android-chrome-passkey-sup...
What would be nicer if there’s a way to do this in Chrome on mobile. I’m not always near a computer although I’m reality that’s probably when I’d be adding the passkey via chrome.
Exactly — I just did this, and it's that simple.
I don't know if this will be universally true among sites that support passkeys, but Google allows you to create multiple passkeys per account.
> Using passkeys does not mean that you have to use your phone every time you sign in. If you use multiple devices, e.g. a laptop, a PC or a tablet, you can create a passkey for each one. In addition, some platforms securely back your passkeys up and sync them to other devices you own. For example, if you create a passkey on your iPhone, that passkey will also be available on your other Apple devices if they are signed in to the same iCloud account. This protects you from being locked out of your account in case you lose your devices, and makes it easier for you to upgrade from one device to another.
> If you want to sign in on a new device for the first time, or temporarily use someone else's device, you can use a passkey stored on your phone to do so. On the new device, you’d just select the option to "use a passkey from another device" and follow the prompts. This does not automatically transfer the passkey to the new device, it only uses your phone's screen lock and proximity to approve a one-time sign-in. If the new device supports storing its own passkeys, we will ask separately if you want to create one there.
In addition to this, you can AirDrop a passkey from one device to another, even if they don't belong to the same iCloud account.
However, a sibling commenter mentioned QR code export/import. That would alleviate the concern and be even more elegant, especially if it automatically created a new passkey registration instead of just copying it around.
https://news.ycombinator.com/threads?id=vlovich123#35802511
No lock-in; you have two phone OS vendors to choose from!
I am not sure I like this. Unless the passkeys are only transferred directly device-to-device, each OS vendor's user cloud storage now becomes the keys-to-every-kingdom uber-target.
> Passkeys on iPhone require that you use iCloud Keychain. If you don’t have iCloud Keychain turned on when you try to save a passkey, you’ll be asked to turn it on.
[1] https://support.apple.com/guide/iphone/sign-in-with-passkeys...
The attempt to get rid of passwords has been the biggest assault on the free internet in recent history, and people are asleep at the wheel as it's happening.
They want to tie you to an external service, so they can tie you to your phone, which they also manage with another external service.
All of these schemes are braindead with obtuse, user-unfriendly backup/transfer/restore options. They fail at even making things "simple" for regular users.
If this Passkey sounds like a good idea, you've been propagandized to be yet another stupid lemming.
passkeys aren't tied to Google or to any other specific provider. Note that this announcement is just about Google supporting logging to with passkeys to their platform. But you don't have to have anything to do with Google to use passkeys with other sites/apps that support them.
It would be a totally different situation if customers were actually interested in a particular solution. Otherwise, it's all astroturfing and nothing can really change that.
Also it's always a good tone to put a disclaimer, e.g. "Googler".
OK, but is that what's going on here?
There's the suggestion in this part of the thread that somehow this all inhibits user freedom. But these objections appear to come out of complete ignorance of what is actually happening. I'm pointing it out because it's the people who are most concerned about corporate manipulation that need to understand what's happening to have any idea on how to guard against it.
> Also it's always a good tone to put a disclaimer, e.g. "Googler".
I guess you're suggesting I'm a Google shill? Well, (1) you're wrong (in fact, I got rid of all the Google things I used to use personally); (2) did I even say anything helpful to Google?
I suggest to take off the tin-foil hat of paranoia. It's not going to protect you from anything and, in fact, will make you more vulnerable if you let it cause you to focus on the wrong things.
It's not a proprietary development. The intention to use private keys for authentication goes all the way back to the KEYGEN tag in HTML. WebAuthn started from FIDO, not Google, and FIDO Alliance was started in 2012 by PayPal, Lenovo, and others, not Google, Apple, etc. Google joined in 2013, and they were mostly interested in 2FA at that point. And prior to that, when I worked at IBM TJ Watson in the 90s on some of the first TPMs, we were developing passkey equivalents using public key crypto for login and digital signatures on ThinkPads and RS/6000 workstations.
This work, desire to use public key crypto for authentication, goes back A LONG time practically before the internet was taken over by corporations.
This is a good thing for the public. Passwords suck. The number of people who have been pwn3d and phished due to passwords is insane, they're user hostile in so many ways "It would be a totally different situation if customers were actually interested in a particular solution", are customers actually interested in constantly logging in with password and SMS codes -- the default today. Does anyone love using authenticators, or Apple 2FA popups, security keys?
For example: https://github.com/StrongKey/fido2
Arguing effectively that passwords were fine for computing in 1970 isn't an answer. So if you don't like passkeys it's reasonable to ask for your alternative.
My mom can’t tell if a website is fake if it’s made to look exactly like Facebook, for example. So in a sense passwords are actually awful for users because they’re required to remember dozens of passwords and verify that a website is legit. If they just reuse the same password everywhere then they are vulnerable to another kind of attack because some website somewhere will mishandle it, forcing her to change every password on every site afterward.
Instead, she can have the best of both worlds by remembering one master password, that basically opens a magic app that will check that the website is legit and create/retrieve a unique passkey for each login.
Or use a password manager to solve both of these issues
Except you're not tied to a magic phone
Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.
You enter a pin, the web server sees a public key that only your side has the private key to.
I agree - not secure.
And just a daily reminder that biometrics are usernames, they are not passwords. You can change a password, a lock, a key, you cannot change biometrics, and thus they should not be used for guarding sensitive info.
The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance.
Please provide evidence that biometric data has ever been extracted from a major platform (IE Apple/enclave). Absence of evidence != evidence of absence, I know, but you’re selling it as the only use case so surely you have proof.
Why extract it from a platform when it can be extracted easily from the person? Imagine your password was written on every surface you touched (fingerprint) or is prominently displayed on your social media accounts (face).
The biometric doesn't exist until you enter your PIN on restart, which is what unlocks the filesystem (including the biometric profile).
You'll also see that you can change your biometric with just your PIN, but you cannot use your biometric to change your PIN.
If the algorithm is not known, it’s only a matter of time it’d be leaked or reverse engineered. And then suddenly there’d be a massive, difficult to fix security breach. Just like the breaches that we have now, with voice based authentication.
Can someone explain, how this can be mitigated?
Your face geometry is used to allow access to a secure processor (trustzone/Secure Enclave/etc) which then signs the web token.
Which is why the phone is the “something you have” piece of the puzzle here.
But if this is used only to unlock the trust zone/secrets, I guess that works. It seem to be extremely dependent on the device not getting locked up accidentally, lost or damaged. If a damage would lock you out from all of the accounts, this seems rather drastic.
Everything you’ve described can be done whether or not I use biometric to sign into a device, or even own a device?
While I see where you're coming from, they really aren't just usernames. It's not like I can log into your e-mail account by typing VoodooJuJu and pressing Enter.
I think you should stop giving out this daily reminder. This meme has outlived its usefulness.
Using face id to unlock a local key store to enable my device to sign a signed challenge from a site I want to log into with the private key stored on my device is not a 'username' in any meaningful sense.
The problem is, the metaphor about passwords and usernames is not a good, structure-preserving simplification of the actual problem of authentication.
The biometric data and/or pin code are not being used to prove that you are you to Gmail, it's being used to unlock the set of private keys you have on your device. This doesn't fit into the metaphor at all.
If my non-technical parents said they were migrating all their accounts to passkeys, I would be very pleased. I wouldn't be worried about their inability to change their biometrics and that causing a problem following some sort of breach in the future. I am highly worried about their extreme susceptibility to phishing, especially in their inability to distinguish phishing sites from real sites, or real account maintence contacts via email and SMS from phishing contacts, their reuse of very simple passwords that are probably circulating in combolists already, and their general inability to retain username/password pairs. I have a lot of sympathy for them when I try to talk them through something like logging in to an Apple device with their apple id, when their appleid username is their email, which ends with @gmail.com. "But...why would i log in to apple with my gmail?" nevermind how confused they are about 'log in with google', 'log in with facebook', etc.
Moving to a model where their devices store webauthn credentials and guard them with a pin or faceid-style biometric shortcut is a _massive_ improvement in practical resistance to account takeover for my parents, and I don't think continuing to say 'biometrics are usernames in authn' is accurate or helpful.
My 76 yr old dad can't do it. His phone is some shitty android trash that when he's setting up his biometrics, he shakes a bit, and it never stores the finger data correctly. I have to hold his finger and his phone at the same time to even scan it. Then, unlocking is also super unreliable because of the shaking. He refuses to get a better phone cause this one "works well enough."
It's no surprise that the tech industry, which largely employs urban, educated 20-somethings and 30-somethings, tends to produce products aimed at urban, educated 20-somethings and 30-somethings.
Stick your finger inside of a dynamically sizing aperture, or clip a finger reader onto your finger? If both the finger and the reader shake the same there shouldn't be a problem.
That doesn't solve the general touch issue, but it solves this particular case.
But sure, I agree (https://news.ycombinator.com/item?id=35790638 ). I'm just trying to come up with some workable solution. Not trying to make the best of all possible worlds.
Essentially every biometric has a population they won't function well with.
Security is HARD. There's no getting around that. Your data is valuable and protecting it is not an easy task. At some level, security and convenience is a zero-sum game.
As for old people, my dad writes down his passwords on a text file in his laptop and has a printed backup in the house.
And, yes, he does have to bug me sometimes to re-login or change a password, but we've never had a security problem, which is way more than can be said for a lot of people who tried the INHERENTLY unsafe "3rd party manager" thing.
No it's not.
The security triad is "something you are", "something you know", and "something you have". Fingerprints are something you are. Usernames are something you claim to be.
The username is the "claim" you are this person. The password is the "proof" you are.
If I'm fingerprinted by any federal agency today (and my fingerprints have been on file with the government since the 90's for a security clearance), then my fingerprints can serve as absolute proof of my identity. This is helpful to me should my identity ever be stolen and I need to show absolute proof of who I am.
But given the relatively high level of laziness, capriciousness, and general failure all around that is "IT security by means of companies who are rarely held accountable," it's good to point out that this is what makes biometrics worse than usernames and should probably mostly be avoided, or at least optional.
Sure fingerprints, face scans, and iris scans can be stolen as well. But certain things are really hard to fake, including potentially, scans of faces and an iris scan at the same time -- unless you can somehow graft a new iris and grow a new face.
Put it like this: a dead victim is found naked along the side of the road. Which leg(s) of the security triad can the police use to prove the identity of the victim?
Google, who I don't pay and doesn't owe me much, not so much.
My apple touchID never works because I rock climb and I guess that abrades the skin too much
Relying on fingerprints to gain access to things on a regular basis never seemed like a great idea to me.
Bodies are not invulnerable to damage. You can absolutely change your "biometrics", you just probably wouldn't _want_ to.
The three factors of authentication are:
1. Something you have
2. Something you know
3. Something you are
Passkeys are typically 1+2 or 1+3 — you'd need to have physical access to the device either way.
I don’t know what “proper 2FA” means but the gold standard today is U2F, and it has failed to be mass adopted due to requirement to purchase and maintain another device.
Most sites already don't store the password. If you have a sufficiently strong password (i.e. very long, randomly generated, stored in a password manager), it is likely not computationally easier to recover the password from a hash than it is from a public-key. The only improvement here is that you don't have to trust that the site is following best-practices for storing passwords, as you never send them the password.
[edit]
It also prevents phishing attacks for those using some form of entering a password other than autofill from the password-manager.
Thus, even short PINs can provide strong security since the attacker gets, e.g., at most 10 tries to guess it out of 100k possibilities for a 6-digit PIN.
Has anyone seen any docs that might help characterize how much entropy the keys have for e2e encryption (Android/iOS)?
I must be missing something, because I can't see how Google would call something e2e encrypted if the keys only have like 30-35 bits of "effective" entropy after a KDF. But that seems like it's the case??
[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...[2] https://www.omnicalculator.com/other/password-entropy?c=SGD&...
The PIN and key derivation wraps the actual encryption key that's stored locally in the device or secure enclave, not the actual secrets that are stored in the provider's cloud. The actual wrapping keys are random 256 bit AES-GCM keys. This approach works because the secure enclave provides measures against bruteforcing and tampering.
There is some controversy that I can't find an explanation for in any whitepaper, specifically here: https://support.apple.com/en-us/HT202303 where it reads "(...) this data remains secure even in the case of a data breach in the cloud. If you lose access to your account, only you can recover this data, using your device passcode or password, recovery contact, or recovery key." because that implies off-device use of the PIN, so those measures are lost. There's no further explanation that I could find about that. Some previous discussion about that particular point here: https://news.ycombinator.com/item?id=33897793&p=2#33900540
> This approach works because the secure enclave provides measures against bruteforcing and tampering.
That's interesting!
> because that implies off-device use of the PIN, so those measures are lost
This link from your previous thread is interesting: https://support.apple.com/en-sg/guide/security/sec3e341e75d/...
Uses SRP to let the device prove to iCloud HSMs that the user entered the correct pin, without ever sending it over the wire. The HSMs have similar protections for brute forcing, etc.
From the docs I have a fairly high confidence entropy is 256 bits for iCloud Keychain. I have much less confidence on Android, but I'm still researching... :)
This thread really smells like https://xkcd.com/538/. Three things you have to remember, that are far more important than any of the concerns you have:
1) The effective entropy of the current system (passwords) is "shrugs shoulders fuck it not our problem". Services can enforce password entropy requirements. They cannot effectually require users to use a unique password. They also cannot forbid users from writing the password they use in a .txt file on their desktop or post-it note or throwing it in Apple Notes (EVERYONE does this outside of our bubble. Apple Notes and Excel are the #1 and #2 password managers on the planet). A six digit pin + hardware TPM key derivation is, at best, the same thing that was guarding how most people store their passwords anyway, and in many cases far better than the current state (if a user's device has no E2EE, or if they're syncing their passwords.xlsx file with Dropbox, etc).
2) Passkeys do not and are not designed to protect against nation-state level attackers. Passwords weren't either. They also don't protect well against the "grab a hammer and beat it out of him" threat vector; you're going to give up your password, and tomorrow they'll probably have your iPhone and your passkeys will be disclosed as well. Passkeys are designed to protect against unsophisticated (and even moderately sophisticated) attackers; phishing, data breaches, etc.
3) If you want higher tiers of entropy guarding your passkeys, you can do that. 1Password, as an example, already has this [1]. They store passkeys, and encrypt those passkeys with their two-level account & master password keys. Done! If you don't like 1Password, you can roll your own, and I'm sure OSS password managers like gopass/keepass/etc will eventually add this. Passkeys/WebAuthn don't prescribe to anyone how you store the private keys; Apple will do their thing, Google will do their thing, you don't have to use them, many people will, and they'll be better off (see point 1).
[1] https://future.1password.com
Thank you. 100% agree.
> Passkeys do not and are not designed to protect against nation-state level attackers
I've been mulling over some use-cases where this is important, hence the deep consideration over entropy. 100% not a huge deal for the passkeys case for many 9's of people.
Slightly off-topic: If a website will not let me register and complains that my password is too long, they're still storing that in the underlying database as a properly-salted (modern algo) hash, right?
2FA via SMS is still vulnerable. 2FA with an app like Google Authenticator or VIPAccess is more secure because it is tied to a device.
Tied to a phone (as opposed to some security-specific device like a Yubikey) is a terrible idea.
It ties your authentication to something that is often lost or damages, but more importantly, something that is controlled by a third party (apple or google) and requires an expensive monthly subscription to yet another third party (your cellphone company).
TOTP is not tied to a device which is why it's a beautiful solution. You can store it where you wish under the controls you wish and back it up as you wish. You are fully in control, dependent on nobody.
Your password manager is likely the exact same thing. The underlying implementation of this is typically a system or third party password manager which added a public key-based credential type for sites. For an Android phone, this is Google Password Manager by default. For iOS, it is iCloud Keychain. Third parties like Dashlane and 1Password have indicated support for passkeys.
I would have thought your interpretation would be that this was strictly better. Even if the credential database leaks for a site, the attacker can't do anything with it - all they have is a public key, specific to that one site.
> Or at least just having proper 2FA.
If I use my android phone to log into a website, I have done 2FA. I have physical possession of my phone, and have used a gesture, PIN or biometric to confirm who I am.
The difference is in the password case, the website has no idea that I did that - all they saw is the password. With a passkey, it is possible that a site would recognize that I did a stronger, multi-factor authentication.
This may have varying strengths as a physical factor - say, provisioned database of credentials onto a device using MFA vs a FIPS-certified security key fob, but I would still argue it is "proper" 2FA.
I also wonder how a lost/broken/replaced device is dealth with, especially given Google's less-than-stellar account lockout history.
edit: I guess this is still MFA since you need both the physical device and a fingerprint and phone unlock code
Or if you really wanted to, you could flip it. You can allow the Passkey to be the "password" and an actual password the second-factor for the user.
(manages customer IAM for a FinTech)
https://www.future.1password.com/passkeys/
Hopefully in the future OSs will have better APIs to allow third-party tools like 1Password to leverage hardware components like TPMs and Secure Enclaves to build a sync fabric that's not tied to the hardware vendor, but this does not currently exist and is not trivial to implement without significant consideration about phishing.
I think YubiCo and password managers have a tremendous opportunity here to partner up to build sync fabrics bypassing OS vendors that might not be as incentivized to provide these APIs now, but I don't believe it's moving, currently.
Additionally, when you say you wouldn't trust Google or Apple to be the _only_ place your passkeys are stored, it's likely that even if we can have third-party sync fabrics, that these will never be interoperable. I don't believe you'll be able to "export" a Passkey from your iCloud ecosystem and import it into the 1Password ecosystem as you can do today with passwords. Doing so would break assumptions about the strength of the authenticator as far as WebAuthn is concerned, and would weaken Apple's security posture as well. Instead you'd probably have to maintain _both_ sync fabrics independently with every service you sign up for.
BTW, passkey is the name for a password that is made using word keys.
[1]https://security.googleblog.com/2023/05/so-long-passwords-th...
But they may separate into several companies to avoid conflict of interests, if they prefer, this time with proper support and everything. Or they can be forced to do so, if they are too stubborn and will continue running their dystopian playbooks.
So, the situation is not strictly technical, it's much deeper than that. A blog post won't make a dent.
What is necessary is a robust, simple-to-integrate standard for authentication, authorization and sessions built into HTTP. Such that all the "hard work" is integrated into common HTTP server software or load balancers, transparently. From an application perspective it should just look like your request getting HTTP_USER=someone HTTP_PERMISSIONS="stuff,foo,bar" HTTP_SESSION="0xdeadbeef", similar to what you get from HTTP basic or negotiate auth, but with a few more necessary features such as session, login/out and a permission model. Browsers would have to provide some proper UI for that, not utter crap like they currently do for HTTP basic or negotiate auth.
Then your centralized auth application can just talk to any old application in a very simple way, no need to deal with huge integration headaches like OAuth or stuff. And the centralized auth application can do all the fancy password killer, 2FA, magic or whatever special auth you need.
Ideally there would just be standarized interface between "credential manager" and applications + some OS-enforced security (so password manager knows which PID sent the question about password or other type of credential).
Then we could have say pub/privkey or cert based authentication implemented there, app just asks for a credential for a site and cred manager asks user whether to allow it once or forever, and which credential to give.
The app then could garnish that with extra metadata so say firefox container feature, or different firefox profile could attach metadata about from which container or profile the request comes from, and credential manager could hand out different credentials based on from where it came.
iOS has an API for password managers and HOTP/TOTP authenticators. Android is planning to introduce one for passkeys.
Last time I read about this, you could use your phone or a FIDO key to authenticate. Like if the phone was close to the computer you could aithenticate the same way you can unlock your computer with your watch.
So either this new technology is so advanced lesser minds don’t understand it or it jus adds a more cumbersome authentication method instead of passwords and its adoption rate will be in single digits.
What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor.
instead of vetting clients and giving them CAs, they just run your credit card for some hardware or subscription, and validate your login.
Identity systems aren't too technically difficult, the challenge is properly rolling them out and getting mass adoption. Which means getting vendors/users on board. It's a problem solved by power and politics, not technological innovation.
Part of the difficulty of using secure credentials is sharing them between devices. It's easier to involve a third-party like Google who can do this for you. The big-tech doesn't actually want to solve the problem entirely because they want some form of control: Either locking you into their service, or aggregating the sites you log into, or both.
They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
What does "authority" mean here?
Biometrics are not it. Anyone can forcefully grab your finger and place it onto your phone screen. They can hold the phone up to your face.
Secure keys or passwords (actual authority) are only vulnerable to rubber-hose cryptanalysis, but you can use plausibly deniable measures to reduce the risk.
Both are bits of data stored in the body (including mind and pockets) that suggest the owner is giving consent.
They both have flaws, but what are the alternatives?
The mind provides authority.
Use both!
But don't mix them up. The mind is more secure than the body because information cannot be forcefully extracted from the mind. Yet.
I think a better solution for authentication is a combination of a cryptographic key or seed and a passphrase held in the mind. Keys could be provided by an NFC ring or smartwatch, which should be more difficult to lose or have stolen than a phone.
Bitcoin has a nice solution for cryptographic keys with BIP-32/BIP-39. You use a single master key to deterministically generate all others via a HKDF. The single master key is produced from a 12/24-word phrase plus an optional passphrase.
A good opsec for bitcoin is to have several copies of a phrase (which can be etched into stainless steel), so there is no single point of failure if lost/stolen, and you can use several passphrases for different wallets, which you don't write down anywhere.
You can use a word phrase with no passphrase in a "decoy" wallet and monitor on-chain if any bitcoin are spent in it. This would alert you that your seed phrase has been compromised but would not compromise your passphrased wallets.
To replicate this kind of decoy with passwords, you could store a login for some service which emails you if anybody logs in.
The decoy method also provides plausible deniability. There is no way to prove that there exists any other keyrings with other passphrases, and there is also no way to prove that you have provided every possible passphrase, even if you have provided all of the ones you do use.
How so? I just created two passkeys for my Google account — one for Chrome, and one for my Apple Keychain.
This is the concern, but exporting passkeys to other ecosystems seems like it'll come with time, even if via third-party tools or like how browsers will prompt you to "import your <passwords|passkeys>" upon setup.
"All your base are belong to us"
We have a lot to talk about and exchange information.
greg at the domain qbix.com
I regret to inform you that someone has carelessly or maliciously leaked your deobfuscated email address, on the site
https://qbix.com/resume.html
You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true.
Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome instance via QR/Bluetooth.
There's absolutely nothing stopping you from providing your own implementation as long as it complies with the "hybrid transports" part of FIDO CTAP 2.2.
[1] https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-cl...
Android will provide an API for that scenario (i.e. on-device third-party authenticators) in the near future [1].
Hopefully, iOS will do the same.
[1] https://developers.google.com/identity/passkeys/supported-en...
Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on iphones and macs?
As a user, that's sounding a lot like platform lock-in to me.
And as a developer, if I want a way for users to log in without a password, and I don't mind that login mechanism being reliant on the user's account with apple / google / microsoft - wouldn't I just add a 'log in with apple / google / microsoft' button to my login page?
My government e-signature service does that: I can’t even use a Yubikey, ironically, because that’s not "FIDO level 2 certified". I had to buy a more or less completely unknown brand instead (of which a government affiliate is apparently the exclusive reseller in my country…)
Because sources like [1] say that "A passkey can replace a password and a second factor in a single step" and "a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern" - isn't there something in the standard that ensures the second factor is maintained?
[1] https://developers.google.com/identity/passkeys
edit: spelling
If your site insists on the device providing a broad identifying signature (the specification says devices classes identified this way ought to consist of 10k+ devices, and in most cases a manufacturer will just identify particular models, like OK, this the model we made in 2019-2021, now we're re-tooling to make the newer model lets give it a new identifier) and the user agrees (I always refuse if asked, the documentation advises you just don't bother asking) to provide this, then you can see OK, it's a Yubikey Model 6J, I think that's (delete as appropriate) fine / not fine. This is obviously a large piece of extra maintenance work, hence it's advised you should not do it.
Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone.
There's also nothing in the spec that forces any provider to allow transfer, so I don't expect that to change any time soon. And even if you can transfer your keys (which you can't) there's also nothing in the spec other than "please don't do this" language that stops a site from using attestation to restrict sign-in from other devices that you've transferred your keys to.
It is very locked down right now.
The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. They are on all devices.
In addition, the 'share password' option on Apple devices works with passkeys. To deter social engineering, the person needs to be in your contacts, and in proximity to receive an airdrop.
There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
This is really misleading -- you can not move a passkey "vault" from an Apple device to an Android device without doing a per-password operation. There are no Open implementations of a passkey authenticator and there is no standard format defined in the spec for how to do mass movement.
There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?
I mean, you bring up Airdrop. I feel like I need to check, is something changed and that now works on Android devices? I'd love to be wrong about this, but Apple's documentation doesn't mention airdropping a passkey to an Android device: https://support.apple.com/guide/iphone/share-passkeys-passwo...
That kind of platform lock-in seems like it would be an important caveat to mention when talking about backup. But I never see stuff like this mentioned.
I don't see how anyone could genuinely claim that passkey portability is exactly the same as an SSH key or password. That's just not true. Authenticating a second device per-site is not the same thing as a cross-platform backup.
> They are on all devices.
They're not on a Linux desktop. If you want to use passkey on a Linux desktop, your options are to authenticate through a secondary proprietary device or to use a Yubikey -- for all practical purposes a locked down device which can not be backed up (no, buying a second Yubikey and manually adding it site-by-site is not the same as backup).
> There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
And again, nothing in the spec requires it. This is asking for vendor lock-in. If it's not a big deal and everyone's going to support syncing across ecosystems, then it shouldn't be a big deal to add a standardized API and sync format to the requirements for being a certified provider.
I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
> And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
There also hasn't been anyone yet who has tried to define what that interchange format should be.
> And again, nothing in the spec requires it. This is asking for vendor lock-in.
There are a broad range of passkey providers, from open source hardware to FIPS certified solutions to solve government compliance requirements. Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
But those government agencies are specifically investing in that hardware because it _doesn't_ lock them into one vendor. Any other vendor who can meet their security requirements can sell into that space.
Do you really not see the difference here? Passwords are inherently resistant to vendor lock-in in a way that passkeys aren't. And honestly, not to call you out but we're back on this again:
> of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
This is not representative of what the ecosystem actually looks like.
Apple and Google have announced zero plans beyond "we're looking into it" to allow open interchange with arbitrary 3rd-party clients. Chrome on Linux doesn't even support native passkeys at all. The most hopeful development I've seen in this space is Bitwarden. 1Password was billed as the solution, but I don't see any plans from 1Password to support porting to other password managers.
And any of these platforms blocking 3rd-party syncing is a big deal. If even just iOS decides "no, we won't allow that", that alone is a huge vendor lock-in that needs to be acknowledged.
So what plans can you point me towards where Google/Apple is announcing that they're going to build a generic API for exporting passkeys from the phone? Do they have a timeline up? And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
> Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
My worry is that most of them won't, and that hardware attestation will get rid of the rest. Let's say there is a client that supports moving passkeys around. That still doesn't change the lock-in potential for all of the clients that don't, it doesn't mean users will be able to migrate to that client once they've been locked in. It doesn't mean that services won't block authentication using that client. A good standard should block this all off at the source; it should (to borrow from the Chromium dev team) encourage developers to fall into a "pit of success."
We already ran into this problem with 2FA codes on mobile devices. How long did it take Google Authenticator to support backup? That has impacts on the ecosystem beyond just "is it possible for someone who knows about the issue in advance to choose a client that's more open?"
> There also hasn't been anyone yet who has tried to define what that interchange format should be.
Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
I mean, they're the ones that want me to get rid of passwords. If they want me to adopt their solution, they need to have an interchange format. It's kind of their problem more than it's mine.
> Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
Again, going back to this philosophy of the "pit of success" it should be harder to lock a customer out of backup than it is support portability. Portability should be the default, and it should be work to make that g...
I'm not privy to their priorities or timelines, no.
> And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
But other companies with a history of being open here also do not have the feature yet. I am equally non-privy to their priorities or timelines.
If you want to say "passkey implementations do not have a bulk export/import feature, which makes it time consuming to switch between implementations", that is 100% factual.
I would not qualify this as a "lock-in", any more a phone that needs to get its software reinstalled is "bricked". And I wouldn't take current state to imply some inherent permanent ecosystem-wide rejection of user backups and data portability, when many vendors have implementations that are still in beta.
> My worry is that most of them won't, and that hardware attestation will get rid of the rest.
There is a great deal of worry about hardware attestation even by the vendors you are likely most concerned about. Apple for example not only removed their attestation, but now anonymizes the authenticator via a zeroed AAGUID.
No matter the vendor, their users (and the overall ecosystem) will suffer if relying parties build allow lists of acceptable authenticators, and deny all others.
That said, I do suspect the ultimate goal is to have sites be able to tell if an authenticator can allow them to shortcut additional authentication checks or not. It could be those websites give a more complicated authentication process to passkeys which do not meet their physical factor requirement.
>> There also hasn't been anyone yet who has tried to define what that interchange format should be.
> Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
Putting aside that I can't speak as to whether there is or is not an effort underway there -
It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
If passkey providers hypothetically want an interoperable interchange format or protocol, they can try to standardize it in a number of places including under FIDO Alliance. Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.
> Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
I don't think this fixes your overall concern. There's no technical measure to prevent implementations from limiting backup/restore even if you make all authenticators anonymous.
Likewise, I don't believe websites would choose "friendly" credentials over "strong" ones. They would let the system survive or fail based on the user feedback/complaints of "strong" mode.
> At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.
Yes, the process is automated within the sa...
How would they? None of the software involved here is Open Source, I can't open a pull request for any of this. And the backup/restore isn't going to work with any of the major players.
It's kind of striking that there literally isn't an Open Source provider supported on any of the major platforms. Let's say you build an Open Source one for Linux. Is it usable with Chrome? No, Google has no plans to support that. Does Mozilla have a working implementation? Also no.
Is that the FIDO Alliance's problem? Sort of? I mean, they want me to believe this is an Open standard. How many "Open" standards have zero officially sanctioned Open implementations of the standard?
> It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
The FIDO Alliance has more than two members. Microsoft/Apple/Google are already in talks about how to build out passkeys. And they're the players that really matter here. Whatever standard they come up with (or decide not to come up with) is going to dictate how the rest of the ecosystem moves.
But again, they're the companies trying to tell me this is an Open replacement for passwords. I feel like it's kind of on them and their alliance to prove it.
We need to hold their feet to the fire and actively push people away from using passkeys until this problem is solved.
I guess this is where I'm arriving, too. Passkeys are a nice idea in theory, but the whole thing is too early in development to use or recommend to others at this point.
This is hopelessly naive.
We need to be actively making a lot of noise and sabotaging industry efforts to use passkeys until the respective vendors solve data portability.
I don't see any indication that Google is looking at Passkeys as just a faster way to log in without a password. They want to eventually replace passwords entirely.
My parents are a good example of this, they have recovery options set up so that we can get into their accounts if they die. None of those recovery options are compatible with current passkey implementations, and their phones might be the only computers they have that are capable of storing passkeys right now. I myself have exactly one device that's capable of acting as a passkey authenticator right now (my phone) and I suspect that'll stop working if I De-Google it and then I'll have zero usable authenticators. I'm not sure how I would add redundancy to a passkey login without buying additional hardware. It's not like my password vault where I can sync it to basically any computer or flash drive.
But that's a separate conversation. Regardless, the goal is the elimination of the password, a lot of coverage and advertising has centered around that. Passkey isn't in the long run designed to be supplemental to traditional log-in methods, it's intended to replace them.
The solution is to not use Apple's keychain for passkeys (and really not use Apple's proprietary services for anything at all), but we can't depend on people to have that foresight.
The authenticator is given a lot of leeway in how it does authentication. In the Apple platform case, it is "the user authentication on the device which is on the iCloud account and has set up iCloud Keychain".
So on my Mac I can use TouchID. On my phone I use FaceID. Both allow me to fall back to the device password (such as when I have the lid on my Mac closed).
I can't rely on retaining access to my Google account for logging into things.
1Password has already announced their intention to use this once ready. I really hope iOS will provide something similar soon.
There's many implementations of OTP. I've never used google's and I've been fine.
Disclaimer: I own 2 NFC rings :)
https://developer.apple.com/passkeys/
https://arstechnica.com/information-technology/2022/10/passk...
Now I'm wondering what's the longest class name out there...
The longest class names I remember are in the Java Development Kit (JDK) version 1.6, under the Swing+Nimbus namespace:
There were threads in 2012 about them:• https://news.ycombinator.com/item?id=4549685
• https://news.ycombinator.com/item?id=4770861
Someone copied the code in this repository: https://github.com/zxiaofan/JDK/tree/master/JDK1.6-Java%20SE...
This is not what they want. They want to a) ensure passwords/accounts aren't being shared to ensure a single account is tied to a single user. They want this for all apps so they can recognize revenue for every user. b) They want more information on you as a user (as opposed to your family member on the same account). The wet dream is per-device, per-user profiles. Possibly even different [additional] costs for each attached device.
That is their goal. Big Tech all want this. That it increase friction to migrate is a side benefit (honestly not so much more than with passwords now). That it happens to benefit users is the lure to draw you in.
https://support.apple.com/en-gb/guide/iphone/iph0dd1796bb/16...
I don’t see any way that passkeys kill account sharing.
In fact, it's important that people do this so that the invalid concerns can be put to rest and (hopefully) the valid concerns can be mitigated.
To limit it to just one defeats the purpose of all this work. You really will only see that where there is a technical limitation (like... why does AWS only allow a single hardware key per user? If you setup SSO then you can have any number of keys)
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
The value of many of these schemes is authenticating under your google/FB identity (email, phone number, org affiliations). It makes a lot of sense for centralized identity providers to do this because they already know who you are and how to authenticate you.
There is a growing untapped market for the authentication and secure use of of pseudonyms. For instance people that want to run a blog and interact in social media under a name that is not connected to their true name. Or some Senator wants to play video games but might be worried that it looks frivolous. This is a setting where something like MPK really shines. I believe over the next five years we will see an ecosystem around a pseudonymous web. MPK might have just been too early as that ecosystem isn't quite here yet.
So it should be easy for everyone else to do their own.
There are payment rings a plenty though, for just using them instead of contactless credit cards.
What is the scenario in which SMS one-time codes are prone to fishing, but passkeys are not?
Eg you’ll get:
Token{domain:hax0r.net username:bob}
2. evil.example: confirm 2fa code to log in.
3. evil.example starts logging into good.example as you, triggering good.example to send the 2fa code.
4. You see the 2fa code and enter it into evil.example.
5. evil.example has phished your 2fa code.
This doesn't work with passkeys (or 2fa tokens) because those verify the domain matches.
Because when evil.example requests the passkey it has to do so through browser APIs [1], and it can't lie about its domain name. Your browser is what reaches out to your phone, which is how your phone learns what domain you are actually on.
[1] https://www.w3.org/TR/webauthn-2/
In this case your phone wouldn't even show you your passkeys from good.example.
Apple does not yet support Passkey for iCloud accounts login.
Those passkeys are asymmetric cryptographic keypairs where the private key is securely stored on a device, unlockable (for use, not reading) only by convincing your devices security processor to do so by pin/fingerprint/pattern. Which in itself can be secure, given you do trust that magic security processor (which you shouldn't, see yesterday's news for example). However, if that key cannot be read, you cannot make a backup of it, so it will be unrealiable and easy to loose. The recovery process will either be insecure and prone to social engineering, or unreliable because proving your identity will be nigh impossible without that passkey. Now one could allow backups of a passkey, but then that passkey would be as insecure as a password. One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances.
In all a bad and dangerous idea.
Which would be easier to use and more effective.
Programs such as Bitwarden already do this, where you send the hash of your password to the server instead of the password itself, because from the password you derive the decryption key and you never want that reaching the server. You then use that hashed password as the authorization password, but the client uses the actual password to decrypt the delivered password vault.
The value the user's browser sends back can't be reversed, so any website prompting from the wrong domain would only ever see an incorrect hash, rather then the cleartext as it does now.
On top of what you mentioned, it also fails really hard when someone has access to you and your trusted device (which will be the smartphone in most cases). It's already an issue allowing easy access to smartphone content, it will extend it to any account using that method of authentication.
FWIW, asymmetric PKI is technically mature and relatively easy to implement in most applications (without "vendor lock-in", I might add to comments upthread), and there are ways to address most of your concerns about key loss and recovery beyond what you describe, as by the ring of trust scheme Apple uses, for example.
The only way through this is forward. I'm confident it really will get better once passwords become a smelly indicator of bad security practice.
If passwords are like playing poker with your cards facing out, Passkeys are like playing with your cards facing in. Your secrets remain under your full control at all times. Nothing sensitive is sent over the wire.
Yes, for everything. Those who've implemented it so far have done a great job at making it /easier/ than handling passwords.
If you've ever used ssh with keys instead of passwords, it's the same thing, and it's so much easier while being more secure. A rare convergence.
The way this typically works is that the keys are stored in an encrypted file, which can be backed up securely as-is. It can also be copied around and sync'd to other devices.
Of course, this means the authenticator app/service that needs to use the private keys to respond to challenges has to be able to decrypt that file, which means logging in to it. Authenticators balance convenience with security in terms of how often you need to fully log in to it. They are also often configured to require a light-weight authentication on each use (fingerprint, face, pin).
With authenticator apps handling the private keys, secure backups should be easy and automatic. Things should improve since the people using passwords now who don't have a secure automatic backup mechanism for them and switch to passkeys will probably end up with an authenticator that does it automatically.
(Recovery processes will still exist and can still be an issue.)
That's literally part of what makes a passkey a passkey (v.s. just a WebAuthn credential), so that's a given.
> as insecure as a password
No. Passkeys can't be phished, passwords can. Passkeys can't be cracked after a data breach. Passwords can. Passkeys can't be set to something easily guessable. Passwords can. Passkeys can't be written on a post-it note and taped to your monitor. Passwords can. Passkeys can't be reused across multiple sites. Passwords can.
There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".
> One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances.
What? Malware stealing your password is "more secure" than malware registering it's own malicious key to each individual site it wants access to?
Passkeys don't need to be cracked after a data breach of your backup provider, they are just usable, right there.
> There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".
Passkeys are accessible permanently on some devices unencrypted or decryptable in the filesystem, if part of e.g. a backup. Whereas passwords are usually only accessible temporarily. That makes the attack surface top copy over some passkey far larger than for sniffing a password.
Let's take Apple's implementation as an example (since that was the one I could most easily find information on). Their implementation stores passkeys in the iCloud keychain[1], which is end-to-end encrypted[2].
[1]: https://support.apple.com/guide/iphone/sign-in-with-passkeys...
[2]: https://support.apple.com/guide/security/secure-keychain-syn...
I think you're mixing up server-side and client/sync-backend-side compromises here.
For the former (i.e. a compromise of hashed passwords and their corresponding salts), you'll need to rotate all passwords since the hashes can be brute-forced. For passkeys, all an attacker gets when compromising a service's database are public keys that can't be brute-forced and key handles that don't give an attacker anything without the corresponding authenticators.
For the latter, the situation is exactly the same for passkeys and passwords in a password manager, i.e. both are as secure as their on-device storage and encryption in transit and rest at a synchronization provider (if any).
This does not make it as "insecure as a password". It does mean you can use root/OS access to exfiltrate keys, but it closes the following security holes that affect passwords:
- keyboard sound-based exfiltration[0]
- visual exfiltration (someone recording you enter your password, or looking over your shoulder and memorizing it)
- credential stuffing, where people who reuse passwords get pwned when the same leaked password is used on other websites
0: https://www.independent.co.uk/tech/cyber-security-passwords-...
Passkeys are just asymmetric key-pairs. There will be a variety of client-side implementations. Some may make export and backup difficult or impossible. Others, such as 1Password's already extant implementation advertise backup and synchronization as a feature! There is nothing about the passkey standard which prescribes the reality you fear.
> Now one could allow backups of a passkey, but then that passkey would be as insecure as a password.
Wrong, absolutely and entirely. Its still more secure, because its an asymmetric keypair, and you're forgetting about the far more common attack vector against password disclosure: service breaches. That's how attackers learn about passwords by-and-large. And this is not just some nice-to-have side-benefit of passkeys: its a core motivation of this standard. With passwords, a service breach compromises not only the accounts of every user on that service, but potentially every other account every user has, globally, because of password sharing. With passkeys, all of that is resolved.
Even if we end up with a system that is the same level of effective client-side security, which is also extremely wrong, the net security of the system will be vastly improved because service providers aren't storing the private key used to authenticate user accounts.
But the client-side security is also substantially improved, because passkeys have much higher phishing resistance.
From the Google Blog I clicked on "Today, passkeys for Google Accounts are available. You can try them out here"
However, I got: "Passkeys aren’t allowed on this account. Contact your admin for help"
And the Workspace admin page doesn't seem to include any options for Passkeys.
https://security.googleblog.com/2023/05/so-long-passwords-th...
the first sentence reads, "Starting today, you can create and use passkeys on your personal Google Account." (Emphasis mine.)
I'm not surprised that Workspace accounts weren't included in the initial rollout. Workspace setups have interesting requirements that aren't necessarily there for personal accounts. For example, under some circumstances, if an employee gets hit by a bus, and there is critical business data which is stored in the employee's account, an appropriately authorized Workspace admin is supposed to be able to gain access to the employee's account. But what is the right thing to do for passkey access? Especially if the user uses passkey to authenticate to some non-:Google resource like, say, Slack which has been set up for corporate use? Should the workspace admin be able to impersonate the corporate employee in order to gain access to non-Google resources via passkey? What about if the employee (accidentally) uses their corporate account to set up a passkey to a personal account, such as for example E*Trade? Maybe the Workspace admin should have a setting where passkey creation is disabled except for an allowlist of domains that are allowed for corporate workflows? It's complicated, and if I were the product manager, I'd want to take my time, understand all of the different customer requirements (where customer === the Workspace administrator who is paying the bills) before rolling out support for Workspace accounts.
Currently I can just message them the password or even write it down on a post-it note and they'll have everything they need to complete the task as me. How does it work with passkeys? Does the spec allow my passkey HSM to securely share the secret by encrypting it against the recipient's passkey HSM? Can it use the concept of leaf certificates to sign a short-lived certificate allowing access to that credential without sharing the credential's secret itself?
I can't advocate for passkeys until the concerns above are resolved. The push for passkeys seems like yet another attempt to remove control from the user.
And if you both use iOS, you can Airdrop a passkey: https://support.apple.com/guide/iphone/share-passkeys-passwo...
I'm sure we will gain the ability to dump the key to a file or write down onto paper at some point but it seems that we are starting from the wrong end.
I've got to quit commenting, but humans are undeniably the weakest link in security. While I understand the perceptions and even share some of the concerns expressed in this thread about the loss of control, reverting to a human-readable string as a key would only regress the whole scheme to something that is, once again, as easily compromised as a system protected only by any other human readable string.
We just have to cultivate new habits. Enroll multiple keys or devices. Print the backup codes and put them in the fire safe with your birth certificate. Give trusted friends and family access to recover your account in the event you lose the credentials or get hit by a bus. It's a few extra steps up front, but once it's working, it's so much easier.
Honestly, there are so many people who never have any idea what their password is, so they end up resetting it all the time... passkeys is a net-positive. Now they don't even have to remember anything.
It's a few extra steps per site. Every time you get a new device you need to go back to every site you've ever visited and update the credentials. It is maybe feasible for a few important accounts but it doesn't scale.
Whatever solution we have needs to be syncable and able to be exported to a safe once and continue to be usable by new sites and devices into the future. People aren't going to print out their credential list every month to update the fire safe.
The device's hardware security facilities are there to protect the keystore. They aren't /the/ keystore.
Find a key manager. iCloud Keychain, Microsoft Authenticator, Bitwarden, something. Use that. Concerns about migrating devices dissolve away.
My experience is not necessarily representative, but I am not sure how big the issue you describe would be, in practice, for the majority of users, who will be, by and large, using one of these services.
What is clearly a major issue for the majority of users is unauthorized account access and resource theft through the use of easily-phished account credentials protected by nothing more than a character string being passed around in text messages and sticky notes.
Is this a major issue though? I think it’s pretty minor, not being able to share or backup my passwords is a pretty huge issue in my books.