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.
The answer is that they're being used to pass an authentication challenge. Pass + key is no different.
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.
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.
You cannot use the private key within a passkey for general purpose data signing, for example.
this isn't just public key encryption. Think of it as a physical Yubikey but embedded in your ...whatever.
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)
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.
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).
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.
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.
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.
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.
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.
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.
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.
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 what 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.
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.
> 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/