> Instead, your phone will store a FIDO credential called a passkey which is used to unlock your online account. The passkey makes signing in far more secure, as it’s based on public key cryptography and is only shown to your online account when you unlock your phone.

It looks like a token stored on your phone that will be used instead of your password to authenticate.

Apple did something similar: https://developer.apple.com/passkeys/ that is automatically sync-ed in iCloud Keychain, so on every apple device you own, you can use it.

More information here: https://fidoalliance.org/passkeys/ and this explains finally how it works FIDO in general: https://fidoalliance.org/how-fido-works/

So yeah it's sort of a token, but technically, it's a private key that is used to sign the challenge at login time.

EDIT: from what I understand, while this prevents from "stealing passwords" etc., there is still the risk that someone steals your private key (copy/paste your phone or ... well, steals stuff from iCloud Keychain) and tries to use that to sign the challenge. Did I get it right? Or what mechanism is in place to prevent it? It looks like this time we use biometrics first (to unlock the screen) and passkey later?

They don't need to be rebranded, they need to be taught in high school with the same words we've always used to talk about them.

You cannot use the private key within a passkey for general purpose data signing, for example.

The answer is that they're being used to pass an authentication challenge. Pass + key is no different.

Because the word "password" has been in use for a long time, before computers, for the purpose of physically passing from one place to another.

The thing about password wasn't that it is a secret word, it's that it allows you to pass somewhere. Typically, passwords were a shared secret (i.e. not secret).

A digital key is typically different from a password in that it's not a word, i.e. not something people can remember a type. It's more like something you have than something you know.

In the context of cryptography it makes sense to distinguish keys from passwords, and public keys (used to "lock" data) from private keys (to "unlock" data). The word key is used for that concept because of the semantics of how keys are used.

A passkey is an abomination. A key, a-priori, is an object that opens locks; and we already have words for keys that allows you to pass somewhere: e.g. door keys.

A pass, in general, is something you present to pass somewhere, whether it's spoken or written; a key is not something you present to pass somewhere.

We have pass words, pass slips, hall/press/ski pass badges, etc.

We don't have pass keys, because you don't show a key to pass somewhere. You use it.

A password encoded as a QR code that you could show to a sensor would be a passkey.

Whatever Google has is probably something else.

https://developers.yubico.com/Passkeys/Passkey_concepts/Sing...

I wouldn't be surprised if password managers implement sharing between users tho

Could be clearer for the tech folks though I agree.

this isn't just public key encryption. Think of it as a physical Yubikey but embedded in your ...whatever.

How convenient!

> Passkeys created on Android are backed up and synced with Android devices that are signed in to the same Google Account, in the same way as passwords are backed up to the password manager.

I don't like this. Time will tell if Google's implementation will be open source, and if third parties can hook into the OS level integration. I certainly don't like the lack of emphasis on interoperability from the get go.

I do not like this future.

It is all user terminology for Web Authentication features, so credentials stored on a current Yubikey are also "passkeys".

There are multiple open source security key hardware implementations that support the published specs.

There are multiple password managers that have started to implement "passkey manager" functionality - 1Password and Dashlane have made announcements here and have published code and Web Extensions for desktop.

Android 14 beta has a system API where software providers such as 1Password and Dashlane can work with this system, not just for Chrome but for installed applications.

I doubt Google's Password Manager will ever be open sourced, but it doesn't need to be for an interoperable ecosystem.

what you described above doesn't guarantee that the ecosystem is interoperable. With passwords, there is no way for the service provider to hide the cleartext password from you, this is inherent to the way passwords work. With passkey, a service provider could decide to hide the private keys from you, effectively locking you into their ecosystem, and there is nothing you could do to avoid this.

There's no guarantee that they will act in a user-beneficial manner, except they all already exist and already act in a user beneficial manner, and that there is no strategic benefit of acting in a user-hostile manner.

> With passwords, there is no way for the service provider to hide the cleartext password from you

Sure there is. They could refuse to do anything but form fill the passwords on registration and authentication pages, where the field in the browser will not allow you to copy the password back out.

The force that keeps them from doing such user-hostile behavior for lock-in today is that nobody would want to use that system. They would not use that vendor. It would be product suicide.

> effectively locking you into their ecosystem, and there is nothing you could do to avoid this.

Unlike passwords, sites are encouraged to allow you to register multiple passkeys. Some sites may push the user to do this for convenience, such as if they see user utilizing a security key or phone to authenticate into their desktop when the desktop is capable of doing passkeys directly.

This gives a whole new ability to jump ship if you decide you don't like your software vendor.

Now, there is a parallel question of "what if a vendor uses their monopolistic power to prevent an ecosystem from being created, and then acts in a user-malicious manner". I suspect they would quickly get multi-national scrutiny.

You can, but most people won't because they will be locked-in, this is not the case with passwords as it's quite easy to change password manager without having to reset all your passwords.

Assuming there is an ecosystem where they can play equally, I suspect they will find all sorts of ways to provide unique value. Their goal shouldn't to be the preferred system across all of Android or iOS, but to offer something a lot of people are willing to pay for.

This is not a remote possibility. It happens to thousands of people every day, for entirely frivolous reasons.

Until there is some authentication system that is genuinely robust to corporate control attacks, I'll keep using the imperfect password manager model.

Also it seems that Linux is completely out of the picture.

The Android implementation allowing for multiple third part passkey providers (typically, existing password manager that want to support passkeys) is in beta.

Apple does not pre-announce features, so we are all likely in the dark on their timelines, and whether their timelines extend to infinity.

However, I believe a passkey manager can replace the system implementation via the web extension mechanism in mobile Safari today.

My understanding is that the private key is stored on your own device, unless you decide to use something like iCloud Keychain (which should be encrypted).

The public key, on the other hand, is stored on the service providers' servers. That is used to create a "challenge", which I guess on your phone you will need to "decrypt/sign" with the private key to prove that "it's really you".

That's how I understand it.

You can for example use a Yubikey, on a Linux desktop system, to authenticate to services implementing the "passkey" standard. Does Google own my Yubikey in some way that I'm unaware of?

Nothing is owned by Google or Apple or Microsoft, there is no grand conspiracy trying to lock you into a platform.

Try educating yourself before spreading misinformation, and before assuming that everything is an Evil Conspiracy by Big Tech.

I tried to do some research myself, but there's no Wikipedia page for "passkeys" and they aren't mentioned on the Yubikey article.

Edit: this user has a helpful comment: https://news.ycombinator.com/item?id=35810144

> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.

I'd love to know more about how / whether these challenges are enforced as part of an open standard, or whether it's up to individual implementers of passkeys to roll their own.

The list of members of the FIDO alliance is public. It includes several companies that most people refer to as “big tech”.

Also I am not sure that I would consider not being able to access private key material from a enclave vendor lock in, since that's the entire purpose of the device.

I guess the same people arguing that passkey is a conspiracy are the same ones that think secure boot and TPM is a Microsofts conspiracy to prevent you from installing Linux.

They are an improvement for service providers, sure, but not for users, due to vendor lock-in. This was my initial argument from the start.

You kept countering with arguments such as "you can use a FOSS client", "but Google is a contributor to open source" or "Google can't access your Yubikey" - which are irrelevant to my point, which is that the new standard introduces further vendor lock-in.

In addition you resorted to personal attacks - calling me and other users in this thread conspiracists or uneducated - but could not counter any of the points we were making with valid arguments.

The keys are also per-device, so e.g. if you use your Google account from your phone, your laptop and your workplace PC, there would be three public keys associated with your account.

Because the private key (in principle) doesn't ever need to leave the device, it could be stored in a TPM, Secure Enclave or similar chip. The device itself is also supposed to protect the key with some sort of local authentication, i.e. biometrics or a PIN. That stuff only happens locally on the device though and doesn't involve Google's servers in any way.

Consequently, if you want to log in from a new device, you can't just copy over the key - you have to perform some complicated dance where the new device and an old device that you have already registered work together to generate a new keypair for the new device.

If you don't have an old device, e.g. because you're a non-techie and only ever used your account on your phone and now your phone just broke? Though luck, I guess?

Same goes for blocking a key: In theory, you can block access for each device individually - however, you need to be able to access your account using one working device in order to do so.

(There is also the hilariously useless flow of "delegating" to a device, for when you're really really really want to check emails from your friend's phone but also have your own phone right with you in your pocket. It will not actually help you if you want to check emails from your friend's phone because you have forgotten your's. This feature sounds a lot like they needed something to respond with if someone asks about logging in from 3rd party devices - without making that usecase actually practical.)

So I guess all that does make stealing the private key somewhat hard: Phishing is out of the question as the user can't access the key even if they wanted to. Even if you got hold if the physical device, you'd have to get the key out of the TPM.

The bigger problems I see is that your account is now tied to your devices instead of, well, you: If someone steals your phone and manages to guess the PIN or get through the biometric auth, they have instant access to everything. On the other hand, if you have no registered device left, you're effectively locked out of your account.

(All that assuming if passkeys were the only option for logging in. As of now, they still seem to plan with passwords as fallback, so that's just hypothetical)

Pretty close - in fact you can use passkeys for SSH access, a la "ecdsa-sk", and in some cases "ed25519-sk".

> The keys are also per-device, so e.g. if you use your Google account from your phone, your laptop and your workplace PC, there would be three public keys associated with your account.

They are per authenticator. Some authenticators, like a Yubikey, hold their credentials in hardware. Some are backup capable - e.g. the "authenticator" is your iCloud account or Google account's password sync fabric (which are often secured more than the rest of those accounts).

This second class is what is known as backup-capable. Buy a new phone to replace your old one, and within the same ecosystem things just work because the platform authenticator can see all your old passkeys.

Across ecosystems, there is the ability to use your mobile phone as an authenticator for other devices. You can sign into an app on a Mac desktop using an android phone, for example.

Going forward, Android has beta code to support third party passkey providers. Hopefully other platforms support similar schemes, which would allow users to choose a cross-platform product rather than being platform-locked (or requiring them to buy hardware).

I can kind of see the reasoning on why the browser wants to do this. Every one of them has a "generate secure password" feature bolted on, now. And I'm not clear that any of them have a way to port passwords out to another source.

Still feels a bit uneasy to me. Physical keys for property provide the kind of security that just doesn't cut it for virtual assets. Such that I'm having a hard time seeing any model without terrible failure cases. :( Super glad that isn't my day job. Good luck to them.

Guess that's the price i pay for using the hardware in a slightly different way than what google and the manufacturer wanted me to.

> using the hardware in a slightly different way

Honestly I wouldn’t classify turning a daily driver device into a semi-brick (if it boot loops and has to be hard reset regularly…) as “slightly different”. If you want to experiment that’s fine, but why would you subject your daily driver to that? Or, why not just have a phone for stable use / real world stuff, and a phone for everything else?

To put it bluntly: you’re wildly out of touch with reality for most people. 99% of people who have a phone — even those people who install custom ROMs on their daily driver — either plan around having to deal with this stuff or have an escape hatch. Most people refuse to tolerate such an experience.

My previous phone was a Xiaomi. Part of the reason they're cheaper than competitors with similar hardware is because that thing is filled to the brim with useless ads, extra tracking way beyond just crash analytics for the manufacturer and the regular google stuff and even some useless "phone booster" app embedded in the settings.

After waiting the two weeks so Xiaomi would allow me to unlock the bootloader (which is bullshit, by the way), i installed LineageOS.

The problem is that the regular updates with security patches sometimes would cause a boot loop. Some times is something as simple as a system file becoming read only, sometimes no thread on XDA developers could guide me to the right solution, and then i just do a factory reset and start over.

But aside from flashing lineage and an ad blocker, my usage is the same as anyone else: answer calls, use messaging apps, browse the web, play games and edit some documents when i'm far away from my PC.

My current phone is a motorola, though, and while i think the official ROM is pretty disappointing (too many pop ups nagging me to sign up to motorola or check motorola apps), as long as i can flash magisk and an ad blocker, i'm a happy person.

I don't think 99% of people who have a phone have any kind of extensively worked out plan for what happens if their phone is lost, stolen, or breaks. If we're lucky the number is more like 50%. For most intents and purposes, irrevocably losing access to a phone is equivalent to bricking it in the way OP talks about. Any passkey-esque system needs to have a fallback plan when the phone unexpectedly becomes unavailable.

So, a communication failure straight away. Does not bode well.

When you register a passkey to access a site, the component that holds the passkey generates a site-specific asymmetric encryption keypair. It then gives the site the (unencrypted) public key, and the private key encrypted with the passkey.

To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private key, which it then uses to sign the challenge, then it sends the signature back to the site. The site verifies that the signature is valid and then lets you in.

A lot of what is interesting about passkeys is the supporting components that are available on popular platforms. Generally speaking, on client devices they store the passkey in special hardware so that the passkey itself is not available to the regular cpu. They also store it in the cloud, probably also in special hardware, and can send it to new client devices.

This all has some nice security properties, namely: * sites don't have any information that would be useful in gaining access to a different site (reduced blast radius when any given site is hacked) * the passkey is not available in the clear to regular programs running on client devices (hard for malware to steal) * The client software ensures that the passkey is very hard to guess. * The client software authenticates the site before signing the challenge. (makes it hard to phish)

Close - it is a signing key, e.g. used for integrity and authentication

> To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private key, which it then uses to sign the challenge, then it sends the signature back to the site. The site verifies that the signature is valid and then lets you in.

This is how non-discoverable WebAuthn credentials (may) work, and is based on the U2F model. These hardware security key fobs did not have sufficient memory to store created credentials and associated metadata for potentially hundreds of sites. So instead, when you registered a credential it would generate a handle, and that handle would be returned to the site. To request authentication, you had to provide a handle which the authenticator understood. Such a model is really meant for second-factor authentication, e.g. after we partially authenticate the user with a knowledge factor, see if they have the physical factor.

A passkey in contrast is meant to indicate a discoverable credential. You don't need to provide those handles to authenticate. Instead, example.com shouts into the void (of browser javascript API) that it would love a previously registered credential. It hasn't authenticated the user at all, so it has no idea which credential that might be. An authentication response includes the handle and a signature, such that it can be correlated with the existing registration on a user account.

Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.

You're probably right that if an authenticator is supporting discoverability it no longer makes sense to store the encrypted private key with the RP. It's still allowable though[0].

[0] https://www.w3.org/TR/webauthn/#credential-id

Thanks for this helpful comment, it helped me understand the difference between U2F and passkeys. I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected. (I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys, or would this necessitate buying a new device - if you're not willing to use your phone for the purpose.)

The WebAuthn spec describes a Javascript API, and CTAP describes how to communicate with authenticators over various transports (USB and NFC being the ones with the most implementations).

Actual conformance to these, requirements on behavior, and things like whether the hardware has mechanisms to protect certain types of attack if someone has physical access all fall into certification. The implementations can provide attestations, which allow a third party like FIDO Alliance to assert some level of certification (even if at lower levels the implementation details are self-asserted by the implementer).

Without certification, it is the manufacturer's word to the user that it has proper security and protections. Without attestations, there is no guarantee to the site requesting authentication that any particular process took place or that the credential has any particular form of security.

But the reality is that while we have built sophisticated _models_ for describing authentication and compromise risks, most consumer-facing infrastructure is a hodge hodge of password-backed accounts with email recovery.

The user already has full choice in how they manage passwords - from established to shady software makers, to a printout of an excel spreadsheet in 5 point font they keep in their back pocket. The SMS you sent out to verify the user's account may very well be protected by a carrier account with the same password the user supplied to you at registration.

> I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys

Passkeys are "just" WebAuthn credentials with a couple of features - e.g. discoverability and user verification. With usability caveats (say, limitations around UX with NFC key fobs) I would expect hardware from the last 2-3 years to support passkeys just fine.

Support for new features may be added over time, both in software and hardware. For instance, a 2020 security key fob might only support a dozen passkeys, while a more modern fob might be able to store hundreds.

https://developers.yubico.com/Passkeys/How_passkeys_work.htm...

Passkeys are a better alternative to passwords. We don't have to think them up to meet arbitrary password complexity requirements. If a website gets breached it does not risk my account at other websites. It is phishing resistant, so I don't need to worry about accidentally using my passkey on the wrong website.

_We_ need to know more as implementers, but the average person signing into Google does not. It's an extension of the password manager experience, using technologies like public key cryptography and an authentication protocol rather than form-filling of text secrets.

For more technical details as an implementer, there are sites like https://passkeys.dev .

The article is very frustrating, very long on fluff and no substance.

If anyone has a link to a detailed technical description by an unbiased third-party (not google hawking their lock-in), I'd be very thankful if it can be posted.

Thinking about this some more, maybe we should start calling Yubikey etc. keyrings, rather than keys, given that they can store multiple independent passkeys securely?

It seems to be smoke and mirrors for you register a bunch of TPM/HSM.

As far as I can tell: it's a system of private keys stored on devices, in order to transmit a key you also need to unlock a device (e.g. phone) with some other method like a PIN or fingerprint/face scan. Combine those two things and it means a would-be hacker would need both the physical device as well as the local authentication for that device (PIN or biometrics).

What happens if user loses the only device on which passkey was enrolled?

Yes!

> What about desktop machines with no fingerprint sensor or faceID?

You can use a PIN, your login/screen lock password, or an external device offering a fingerprint sensor.

> What happens if user loses the only device on which passkey was enrolled?

You can either sync passkeys to an online account and across multiple devices, or use multiple passkeys stored in multiple physical authenticators.

But all of that has to be set up in advance, right? What happens if I really only have a single passkey, associated with my phone, and then lose the phone?

Not all authenticators are going to have backups enabled (even ones which are backup capable), so these are really meant as hints so that a website (a la Relying Party in the spec) can guide the user to a proper experience. For instance, if you use a hardware security key fob, they may recommend you keep your password and SMS enabled as options, so you can get in even if you lose it.

But if you have this and the old authentication methods, doesn't that greatly reduce the security gains of this? I mean, the old methods still exist, so what you've done is increase the attack surface.

If this is a Google Service, then that means begging, pleading, threatening, crying like a baby, then finally posting a rant on HN to get the service unlocked.

Google is fairly infamous for making it near impossible to recover lost account access, or appeal bans.

I have an account that I’m never getting back. I made an error, when setting it up, that resulted in me losing the password (I saved the wrong one, in 1Password). It’s been a few years, but I remember trying everything to get it back, and was stymied at every turn.

Eventually, I gave up. The reason I registered the account, was because it was the name of one of my corporations, and I didn’t want fraudsters registering it.

Mission accomplished. Ain’t no one using that account.

* Easy to understand. (A password is just a word/phrase/string of characters only you know.)

* Easy to use. (Using a password only requires remembering and typing it in when prompted.)

* Convenient. (Only your ability to remember and type required. No other tools or gadgets required.)

* Simple. (All of the above.)

If something needs an essay to describe itself, it's not killing off passwords.

Do you really want your only means of logging into a service identify you because it's also the only way you log into your banking?

And should you want to kill off an identity so you want to have to register everything?!

Passwords should be easy to retire and change if they are compromised. You can' easily change your fingerprint or iris circle on demand, if somebody makes a good enough copy.

On the other hand, I don't really know how would that work on desktops, should chrome use a Windows service for that? Would it use its own servers? Apple would probably do it themselves. And how about Linux? Would a cross platform option ever exist? Maybe 1password?

* Easy to understand. Your device will just ask "sign in?"

* Easy to use. Your device will just ask "sign in?"

* Convenient. Nothing to remember, nothing to do

* Simple (all of the above)

Passkeys are/will-be way simpler than passwords for the majority of users

Or if you drop your phone in a lake you’re out of luck too.

You use passkeys as a preferred login method.

If you do not have your passkey, you can tap "Try Another Way" and use your password as usual.

It just becomes much harder to phish out this password.

If you've also lost access to your email, you've got other problems.

Or better still, use a password calculator app such as https://spectre.app/

This kind of approach generates your passwords for different sites based on login information and a single password only you know. No other passwords are stored on any devices or services, not even within the app on the device you are using it on.

Which enables you to have different passwords for each service and solves the problem of "too many passwords to remember" without just having to write them all down in a dozen ways that can also be compromised.

https://www.yubico.com/blog/a-yubico-faq-about-passkeys/ https://nordpass.com/passwordless/ https://www.future.1password.com/passkeys/

The protocol is private key stored on your hardware; public on the service you're authing to. Google doesn't have a way to MITM that, but if you lose the machine storing the private key, best have another way to auth.

(Note: some implementations, including Chrome on Android, do allow sync and sharing of the key, but IIUC even if Google bars you access to your account, the phone will still have the private key and can still do the login).

right, so passwords it is then.

One of the main gripes people have is about whether or not the user actually has access to the key or not.

ie. Can I save my passkey somewhere that I control, can I login on another device, etc. etc. Or do I need google's sync/account to do that for me.

Google controls the software so it can MITM.

> Passkeys are easy to set up and let you securely sign in to your Google Account using your fingerprint, face, screen lock, or hardware security key. You can create a passkey on this device, or use another device.

When I press [Continue], Windows Security appears where I can then scan my fingerprint which I already use to sign on.

A single glide of my finger worked as expected and a 'Passkey created' screen appeared with [Done] being my only option to continue.

After a sign out, re-enter of my gmail and these are the next few steps: https://imgur.com/a/heLrUkb

It seems like it just integrates the built-in verification methods depending on what device you are on.

A passkey is a user facing term. Platforms have been working on technology to support that idea for years now.

There may be a difference in terms of how Windows Hello dictates the user experience vs what browsers show on other platforms - I haven't tried it recently.

The key word being identify, as opposed to authenticate.

Authentication using biometrics is only secure as long as the object being scanned cannot be physically replicated and you can verify that the data source is a physical scanner and not a simulation of one.

How do you implement that without compromising device repairability?

No, a password is a secret word for phrase that both you and the service you want to sign into know.

I don't know how to explain a passkey but at least in this one sense, a passkey is split into a public and private part. The public part is shared, the private part is not. The public part can be verified to match the private part without sharing the private part. Your device stores this private part. When service wants to let you login they ask your device "does this public part match this user's private part?". Your device responds in a way such that the service knows "only someone who has access to the private part could have responded correctly to -should this person be allowed to login'"

That would not be a password, that would be something you share. An actual password must be possible to verify without it being stored on any device. On the service side, it's the same as for certificates, as you describe. The service can't store the password because that would invalidate it's usefulness as a way to prove someone is who they say they are. This is why we store a cryptographically secure hash code instead. It is also why the password hash code must be generated on the user's end, not on the service side. You never want to "transmit" passwords in plain text because transmission across the internet is an act of making copies of the data transmitted in the memory and storage of all the devices it transmits across. The moment you send a password across the internet, it is compromised.

So as the service, you don't know the password, you only know that the hash code you received matches the one for that user, and you are reasonably certain that there is no known way for someone to generate that hash code without knowing the real password. Therefore the person trying to login in must be who they say they are.

Passwords and private keys only work as authentication if no one else knows it, has possession of it, or can get access to it. If there is a flaw in any one of those aspects, then the system doesn't actually prove a person is who they claim to be. It only proves that a person is someone who knows, possesses, or has access to that thing. That might still count as evidence that they are authentic, but more will still be needed to actually prove they are authentic.

It's lowercase "p" - it isn't a Google or Apple brand.

Developers can use terms like "multi-device discoverable user-verifying FIDO/WebAuthn credentials" which have very precise technical meanings with demonstrated interoperability.

And they will be fine with that because they have already been introduced to this because that is the way they authenticate locally with many apps on their smartphone already.

keeping your data secure is google's job, not the user's. if google stops asking for a password, that's going to make people happy and they're not going to ask a lot of questions about why.

From a practical one it's another way to get people to relly on major comporations for all Auth ises so they yet have another thing anchoring to their ecosystem.