Google Introduces Passkey Authentication
security.googleblog.com
security.googleblog.com
1. If you are using this to authenticate a non-Google service, can Google cut off your access to that service?
2. If your Google account is terminated, do you still have access to non-Google services?
3. Does Google possess sufficient information to log into non-Google services as you?
4. In the event that any of the above happen, do you still have the right to sue Google?
I think this is a great question, and that the answer depends on the 3rd party site.
AFAIK this part has nothing to do with passkey's and is an issue with OAUTH, and has been an issue for years.
This issue is not caused by OAuth, but by offering authentication via a third party. If you allow visitors to authenticate via a third party, you implicitly trust that third party. If that third party decides to revoke your account, then the logical consequence is that you can no longer authenticate. There’s no solution for this problem imo, other than not allowing authentication via a third party.
It is the same as airlines; They want you to identify using a passport. If your country decides to revoke your passport, you cannot check-in. That’s not an issue, but a logical consequence of choices made.
I'd like to have a regulated entity such as a bank, or even the California DMV, as a backup authentication provider. They have legal obligations that Google does not.
[1] https://www.jpmorgan.com/technology/technology-blog/protecti...
1. no, it's a cryptographic key stored on your device. but also yes, because if you're using a passkey on a device you sign into using your google account, google can lock you out of that account and potentially that device. if that device is your only way of logging into a service, you'd be locked out of the service in the same way that losing or destroying the device would lock you out of the service. but authorizing multiple passkeys and adding backup authentication methods is encouraged, so for practical purposes the answer is no.
2. you should understand that passkeys are issued by your device or browser. so if you don't want to trust google, you can use a passkey issued by safari or iPhone instead of Chrome or Android. if you're using an apple-issued passkey to sign into some other service that isn't your google account, google has literally no involvement anywhere in that chain.
3. not according to the spec. the passkey is a certificate that gets stored on your device. your device shares a signature (not the certificate) with the service you're signing into to prove you have access to the certificate. but they're issuing you the cert through their proprietary software. if you don't trust google to not snag a copy of the passkey when they generate it for you, you should use passkeys generated by an issuer that you do trust. (in apple's implementations, passkeys are synced through iCloud, so the answer there is yes - apple does have your passkeys and could sign in to services as you if they wanted. google is not doing that.)
4. you'd have to read the ToS for yourself to figure out what you could sue google for. but the more relevant thing than legal recourse is that this scheme doesn't really give google any power they don't already have, and in many ways distributes power out to third-parties so you have to trust google less. apple's passkey implementation is leading google's. others will follow. this is about allowing you to use an open standard to authenticate with your google account.
So, the solution here seems to be not just creating backup devices (using the same account) but diversify the platforms as well like use a mix of android, yubikey, ios and any other supported platforms.
Doubt many people would have the time and resources to do it correctly.
If your threat model includes “the manufacturer of the device I use to authenticate myself is actively working against me”, you are already completely lost.
Have a look at https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... and multi-device passkeys.
Your keys may never leave secure storage (tho again that is an implementation detail), but how sure are you about the sync implementation or the backend configuration that dictates which keys or methods are acceptable authenticators?
As a trivial example, it seems very likely that providers will implement one or more forms of backdoor to ensure that LEOs can access your cloud resources.
1. Google can lock you out, but it’s ok because 1% of users have a workaround,
2. You will lose access, but it’s ok because you won’t if you didn’t use this product,
3. Google can log in as you, but it’s ok because we should trust them not to, and
4. We’ve got no recourse, but it’s ok because we were probably helpless anyway?
Companies may get away with this for other products, but the bar is way higher for security products. There are real solutions, or at least ameliorations, and it’d be unsafe to use the product without ensuring they’re there.
With this announcement, you can log into a Google account with a Passkey. That Passkey could be generated by anything implementing the spec – an iPhone, a browser, a home-grown Python script, whatever you want.
Google can still lock you out of your Google account whether you use a Passkey or not. If you use your Google account to sign in to other sites, Google can also therefore still prevent you from logging into those other sites, as they have been able to do before (I don't know if they do this as a matter of policy, but they theoretically can).
Passkeys do not change this.
The only potential place that Passkeys might change things is if you use a Passkey generated by a Google technology, like Android or Chrome. You could use those Passkeys for logging into anything, not just Google accounts. As these are tied to a device, I don't believe the Google account on that device affects them in any way. Google can't lock you out of your Android phone, and can't prevent you using Chrome, so can't prevent you using Passkeys in either of those systems.
1. They can lock you out of your google account and services you authenticate using login with google, but no more or less than they can lock you out without passkey authentication.
2. You may lose access as per #1, but no differently than if you lost access to your google account having used MFA or whatever other method to log in. It's completely orthogonal.
3. This is just wrong. The passkey is a cert which is used to sign something and send them the signature they can verify with the public part of the cert. They can't login as you. If you don't trust them not to backdoor the passkey itself during generation you can use a passkey generated by someone else.
4. You never had any recourse. This doesn't change that at all either way. It's a login methodology.
Passkeys are stored in the iCloud Keychain which is end-to-end encrypted with 256-bit AES. Passkeys cannot be read by Apple anywhere but on your own device.
Unless you control/audit the whole stack (and forbid updates), you have to trust somebody.
https://web.stanford.edu/class/cs208e/cgi-bin/main.cgi/stati...
iCloud Keychain is e2ee.
It's a shame that you can add hardware security keys to your Google account and all of that can be bypassed just by pressing "approve" in the Gmail app when you're trying to login.
The attack vector that I'm thinking of here is your phone being stolen while in public while unlocked, it doesn't even prompt for further biometrics when approving a login from the app.
AFAIK this removes the ability to use a phone prompt as 2fa.
(frequent international travel while having strong opsec)
So the only option to have recovery codes available is to not used advanced protection and then have this “Google Prompt” forced on you, which I’d like to disable as it is another physical attack vector which is undesirable especially when travelling.
All security is a trade off. For a good chunk of people that is a rare enough occurrence that it is a good trade off for them.
But I do wish that people on standard accounts could just disable their forced “Google Prompt” authentication method and just use their own 2FA security keys with fallback to backup codes.
You’ll be able to sign in securely with just a passkey or device prompt.
So, if I want to, say, authenticate my Gmail account with Fastmail or ProtonMail, I can't also be using Advanced Protection. [0]
With Google Workspace, admins can allowlist OAuth applications registered with Google APIs for users who use Advanced Protection. Consumer accounts have no such feature.
I am not arguing the logic; I understand it. I just wish it were different. I suspect that passkeys are one stepping stone on the road to increasing account security baselines to be more like Advanced Protection, which may ultimately give me what I want one day. Wishful thinking, perhaps.
[0] These are OTOH examples, which may not be accurate as of this writing.
Except most people are operating under a flawed assumption that the trade-off with Google is like a trade-off with any other institution - that is, if the worst happens, you can get a human on the phone, or visit a branch office, and get the issue sorted out. This critical fallback is, unfortunately, missing for Google and many other on-line service providers.
Irrelevant to the problem of "I want to just disable phone prompt of 2FA without everything else included with Advanced Protection" - there's no intrinsic "security tradeoff" here, just bad and overly restricting design decisions by Google.
There used to be a way to intentionally (after 2FA) add or remove devices to "Google prompt". These days, it just seems to be any device I'm logged in to, sadly.
I didn’t mention it in that post but that is _exactly_ the attack vector I had in mind also- even if someone stole my phone, Touch ID should stop them from getting at my passwords.
This is exactly why I'm a big fan of larger, heavier devices, such as my rack-mounted desktop PC, being their own 2FA device. It's pretty hard to steal my 4U desktop that is bolted down, there's no reason why it should depend on anything else for 2FA.
Similarly, laptops should be their own 2FA device and not depend on a phone, since people are generally more careful to not take laptops into high-crime areas.
Skip password when possible - You’ll be able to sign in securely with just a passkey or device prompt.
>Creating a passkey on your Google Account makes it an option for sign-in. Existing methods, including your password, will still work in case you need them, for example when using devices that don't support passkeys yet. Passkeys are still new and it will take some time before they work everywhere. However, creating a passkey today still comes with security benefits as it allows us to pay closer attention to the sign-ins that fall back to passwords. Over time, we'll increasingly scrutinize these as passkeys gain broader support and familiarity.
Passwords had a security and a usability problem, I guess, and so the solution was to add 2FA, which allegedly improves security. Now, we’re dropping the security of passwords to solve the usability issue. This doesn’t seem to be a big improvement to me.
That's not how 2FA works.
I believe Passkeys are great for those whose threat profile doesn't include physical assault risks.
Passkeys are stored in Secure Enclave on Apple devices, or on YubiKeys. Not sure about Androids.
IMEI number?
2FA just means 2 factors.
Passkeys are just a factor. Usually a more secure factor than a password.
So Passkey = Something you have, PIN = Something you know.
> this means that passkeys protect you against phishing and any accidental mishandling that passwords are prone to, such as being reused or exposed in a data breach. This is stronger protection than most 2SV (2FA/MFA) methods offer today, which is why we allow you to skip not only the password but also 2SV when you use a passkey.
Right now, I am able to back up all my personal passwords and all my personal TOTP secrets into printed paper form that I keep in tamper-evident packaging and distribute to a safe-deposit box and the basements/attics of different trusted friends/family members. The printed packet of paper has instructions on how to use it, the passwords and TOTP secrets themselves, and the brief source code for one program, one that lets you generate TOTP codes from all my secrets (TOTP is very simple, it's like 30 lines of python[0]). I've tested it all and it is sufficient to access any account I have. Since it's all recorded on paper, each packet will function for my entire lifetime; I don't have to worry about storing a device and that device's charging/power equipment, and I don't have to worry about that device's capacitors or battery going bad in 10 years.
So in the world of "passkeys", how do I simply and durably record them so that if need be, someone who is not me, who I've never met, and who has access to none of my electronic devices, can authenticate as me given that this person is willing to put several days effort into dealing with my authentication archive (e.g. an estate lawyer)?
I know that this is "possible"; it's all based on data and secrets recorded somewhere, but I'm having a hard time understanding the FIDO description, and I don't see an Open-Source equivalent of what Google's offering here. Is there a "KeePassX" of the passkey world?
> Is there a "KeePassX" of the passkey world?
Both 1Password and Bitwarden have announced support as soon as OS support will become available, the latter being open source.
https://security.googleblog.com/2022/10/SecurityofPasskeysin... claims it's encrypted using "an encryption key that is only accessible on the user's own devices":
> When a user sets up a new Android device by transferring data from an older device, existing end-to-end encryption keys are securely transferred to the new device. In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup.
> To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys.
> Screen lock PINs, passwords or patterns themselves are not known to Google. The data that allows Google to verify correct input of a device's screen lock is stored on Google's servers in secure hardware enclaves and cannot be read by Google or any other entity.
How does Google know my device's local PIN in the first place? Are Android phones phoning home to Google with their local PINs, like how they already "helpfully" backup your Wi-Fi passwords to Google servers? And what's stopping the FBI from asking Google to send them every device's PIN as it's created?
They could lie about that, but they could do a lot of things.
> And what's stopping the FBI from asking Google to send them every device's PIN as it's created?
device PINs are never sent to Google in this scenario - but nothing is stopping them from being asked to log your Password the next time you sign in, and it's up to you to trust that they'd never do this even when asked via national security letter since it destroys all trust people (and Google Workspace enterprise businesses) have in their login system.
In short we can only verify PINs, and only a very limited number of guesses, enforced by hardware.
Having both behind your phone makes it easy to drug someone and get inside.
Passkeys simplify the email reset/OTP loop, for the most part.
I'd maybe be worried about the drugging if I'd ever heard of it happening to someone I know.
Yes, but this is the reason that password managers encrypt your other passwords with a master password, rather than a master biometric. The master password is still the "something you know" factor.
When the "safety interval" expires, or if you fully shut off the device, or if you manually trigger a "something unusual is happening" mode (https://www.idownloadblog.com/2017/08/21/how-to-disable-touc...), then the password manager will lose this cached "already mostly satisfied" state, and so will require you to present the "actual" something-you-know credential again.
> Mac Keychain for example is "unlocked" at login unless you change that.
That's because you just fully authenticated it by providing your master password (which for the macOS local keychain is your local account's login password, which you had to present in order to unlock the FDE disk at startup.) In fact, ignoring FDE, this is what "logging in" means on macOS: decrypting the local-account keychain.
You'll notice that this doesn't apply to your iCloud keychain, since that doesn't use the same password as your local account, and so you didn't present that keychain's unlock password when you signed in.
Interestingly, this also doesn't apply if you set your FDE unlock password to be different than your local account sign-in password. The FDE unlock password will do some magic that gets you logged into your account; but you will end up in your account with your local-account keychain still locked — which will cause a lot of annoying prompts on login. (I ran macOS like this for a while back in ~2013, because I wanted a really secure boot passphrase, but didn't want to have to type it every time I locked the screen, and TouchID didn't exist yet on Macs. Wasn't worth it.)
> iPhone Keychain will input passwords from just FaceID, no passcode prompt
Again, that's because you signed into your phone with a password recently-enough to make it satisfied with you; and this safety interval is much wider on a phone than on a PC, because people keep phones "securely" with them, rather than e.g. letting them sit turned-on and unguarded at work when they go home for the day.
You'll find that companies that have confidentiality requirements, deploy MDM policies for employees' mobile devices which make this safety interval much shorter — if they even allow it at all. (I worked for IBM Canada, and my phone would force a password unlock after being locked for just 30 seconds.)
> Desktop Chrome and Firefox just autofill passwords no questions asked.
This is true, and because of this, security people do not consider these browser "autofill" features to be "password managers." Don't use them! They don't encrypt your passwords at rest, either! Viruses can steal your passwords right out of these autofill databases, and many modern viruses do do that!
(I would note that Chrome does prompt you for your [local-account login] password in order to be able to browse your autofill passwords — which is at least something. But this is just security theatre; you can still read the passwords right off the disk without knowing your login password.)
I booted my laptop maybe several months ago and unlocked the screen with TouchID at the moment.
> Interestingly, this also doesn't apply if you set your FDE unlock password to be different than your local account sign-in password. The FDE unlock password will do some magic that gets you logged into your account; but you will end up in your account with your local-account keychain still locked — which will cause a lot of annoying prompts on login.
Haha, I've been there by accident before. Or before FDE was a thing, having a different keychain vs login password because of some migration gone wrong.
> Again, that's because you signed into your phone with a password recently-enough to make it satisfied with you
Not sure about this. Usually I use FaceID. Does that ever expire and need the passcode? I don't think it does; the only times it asks iirc is when I fail the FaceID auth repeatedly (it doesn't like my second pair of glasses).
> This is true, and because of this, security people do not consider these browser "autofill" features to be "password managers." Don't use them!
Yeah, it's jank, but people do use them. Personally I use Safari for important stuff just because I want Keychain instead, but otherwise, your only option is dealing with a third-party password manager.
And clicking the side button ten times locks it to needing the pass phrase.
Holding the power/side button and either volume button for a couple of seconds (just pressing them together and letting go creates a screenshot) presents a menu allowing you to power the phone off, display your medical ID, or call emergency services. You can also configure settings to have this action do the countdown as described above instead. Either way, biometric unlock is disabled until you re-enter your passcode/PIN.
Either option is pretty easy to do unnoticed with your phone in your pocket.
My password manager generates unique strong passwords, is offline and no big multinational advertising company controls it. The only thing I need to worry about is individual companies security practices. Passkeys offer me nothing of an improvement over this and only more obstacles and hoops to jump through.
Until I can use passkeys like I can my password manager I'm not using them
So my password that I stupidly shared among my accounts and was then leaked, can still be used to compromise my Google Account.
Wake me when I can create a Google Account without a password, email, or phone number, period.
Sounds like with other methods (SMS 2FA, USB hardware key, etc.) you may be able to eventually turn password sign-in off on your Google account and use passkeys exclusively.
Passkeys can substitute the former, but (by design) not the latter.
* I activated the passkey, but since i had one saved from an old device, it did not set up my new device. So i got locked out of my account (luckily i have a backup option)
* How does this work with desktop PCs that don't have a camera?
* Now we have a web of primary, secondary, n-ary authentication methods that need managed. Password, app 2-fa, phone 2-fa, tokens etc. Any one could be a weak link in the chain. Now warnings, notifs & reporting is needed to maintain security among all the auth methods.
It reminds me of the XKCD "standard" that now means we have n+1 protocols
> In fact, if you sign in on a device shared with others, you should not create a passkey there. When you create a passkey on a device, anyone with access to that device and the ability to unlock it, can sign in to your Google Account.
... I wonder about the general layperson, especially older generations who (in my experience) tend not to use very secure passwords or MFA. Historically, all they would need to do is use their username and password, and now they are into their account, regardless of which device or location they are at. With passkeys, they have to not only learn a new login paradigm, but also remember that it's different if they are signing in at e.g. the library vs on a desktop at home.
We are not taking responsibility for the unusable UX we are applying to cars, home appliances, phones, consumer devices, televisions, etc.
Mechanical and even electronic devices have an intuitive direct-feedback UI. Flip on an old iron and it heats up.
Modern devices are multi-modal, with soft-touch keys and modal LCD displays. Some buttons are long-press (variable input).
And don't get me started on cars. Total chaos.
Sign in on a different device with the passkey stored on your iPhone iPhone stores your passkeys in iCloud Keychain, so they’re automatically used whenever you’re signed in with your Apple ID on another device (iOS 16, iPadOS 16, macOS Ventura, or tvOS 16 required). However, if you use a device that’s not associated with your Apple ID, you can still sign in to an account by using the passkey stored on your iPhone. Signing in usually consists of the following steps: Use the other device to go to your account sign-in screen. On the sign-in screen, tap the account name field. Tap “Other options,” “Passkey from nearby device,” or similar, then follow the onscreen instructions to display a QR code on the screen. Use your iPhone camera to scan the QR code.
the docs https://support.apple.com/guide/iphone/sign-in-with-passkeys...
For linux users, not entirely sure which environments support any form of "biometrics".
it sounds like an app can consume passkey logins without registering with a provider?
do providers phone home when I log in? can providers block an app from using them?
can I self-host a provider, or is there a shortlist of approved providers?
is there any provider that allows me to backup private key without sending it to their cloud?
is it similar to openid in that it shares email etc with the app on login?
Passkeys are an open standard, and they basically are just public/private keys with a wrapper. When you create a credential which is just a call to `navigator.credentials.create` with options to indicate a PublicKeyCredential type and that it should be a client-side discoverable key and a user ID to associate with it (and some optional info). Its gives you back some meta-info and the public key to store.
For a login flow, similarly a call to `navigator.credentials.get` indicating you want one of those discoverable keys to be used and a challenge. The browser returns a signature to you along with the key info (that user ID from the creation) and you are responsible to verify the signature is appropriately signed.
---
So, on the actual crypto side, nothing about it requires any centralization, there is no required phoning home or to a remote source. On the creation/storage/retrieval side, the WebAuthn Authenticator Model is defined as part of the standard so anyone can implement it. I don't know enough about how you'd register as such an authenticator. Dashlane already supports passkeys, so it is possible for a third-party to do so, Bitwarden and 1Password are also working on it.
So my understanding would be that self-hosting is more just a matter of giving it time for others to implement the necessary components and not there being any restriction on who can do this.
"The beginning of the end of the password"
This is confusing. Is there some plan on Google's part to kill passwords that I'm not aware of?
Apple: https://developer.apple.com/videos/play/wwdc2021/10106/ https://developer.apple.com/passkeys/
https://blog.google/technology/safety-security/the-beginning...
Is any Linux distribution, let's say Ubuntu or Fedora a "major platform"? Is Firefox a "major browser"?
There are PAM modules you can install and configure for Linux and OSX.
Browser support is slightly different depending on the browser, but support for credential creation and assertion using a U2F Token (passkey) is supported by Edge, Chrome, and Firefox.
Roaming authentication is well supported on Linux, and you can cross-device sign in using your iOS/Android phone (assuming you haven't DeGoogled it), but the Mac/Windows experience of just having the computer itself act as an authenticator isn't supported. You're still going to need to use a locked down, proprietary device to log in, it's just that the proprietary device can help you log in on your Open device.
That is a really good question.
For whatever reason, I'm not aware of a single Open Source platform authenticator for any platform. It seems to me like that would be a pretty big priority for an Open standard, but what do I know?
Google has said they have "no plans" to support platform authentication on Linux[0]. I don't know if this is just them saying they don't plan to build a platform authenticator themselves, or if they're saying that if a Linux box advertises that it has a platform authenticator, they're not going to trust it.
Either way, passkeys basically require you to either buy a Yubikey/dongle (which will not support cloud sync) or to use a proprietary OS as your authenticator.
https://developers.google.com/identity/passkeys/supported-en...
So I'm not sure I believe that really strong stances on potential phishing attacks are the real reason here. Passkeys with cloud sync are phishable.
> why bother
A single master password would still be a massive increase in security and would still eliminate a ton of phishing attacks. The cool parts of passkey aren't really the biometrics, the cool parts are how they get shared with websites. That's where the real phishing protection comes from.
Have you done that recently? What a godforsaken pain in the ass it is, especially if you don't have another Apple device handy that you are already signed in to.
Though even ignoring SMS and recovery codes, I'm not sure that using a second Apple device as 2FA would change anything; we generally don't consider one-time codes to be unphishable.
But again, that's only me looking at the docs. Is there something I'm missing about the process that would block a phisher from using an iCloud password plus an SMS hijacking attack or phished one-time code to log in and set one of their devices as trusted?
This support has existed for a while, but not with this rebrand. I hope more companies will adopt this approach as it seems like an effective strategy.
Not to rehash the entire previous post, but this should have a giant asterisk next to it. It's very technically cross-platform, but there is no batch interchange format. If you use Safari, your passkeys are only synced to iCloud. You can share them via AirDrop... to other Apple users. If you lose your phone, you can recover them... if you buy another iPhone.
You can use your iPhone to log in on a Windows device, that part is cross-platform. And you can add that device as a second authenticator. But there's no actual portability there. You have (limited) cross-platform support (there is no Open Source platform authenticator that I'm aware of, and I'm not aware of any platform authenticator for Linux). But you can likely use passkeys with whatever platform you want. It's just once you choose a platform, there's no way to export from that platform unless you per-site add a new authenticator.
Think of a passkey as a device identity credential. It gives credential X that you can register on your backend as belonging to device Y; not to user Y. You need to additionally keep in your backend a mapping from devices to users — where almost certainly, a user HAS MANY devices.
You know how, in well-thought-out auth systems, you can "sign in with a password" and "sign in with [SSO provider]", and those will result in signing into the same account, where both the password credential and the IdP subject-claim are separate "credentials" bound to that account?
Each passkey is a "credential bound to the account" in that sense. You create one for each device, and they all log you into the same account.
In short, they're a "third-party-ization" of the thing that Apple, Google, etc already do with their "you're trying to sign into your Apple/Google/etc account from a new device. Confirm this on an existing device" workflows — where each device creates its own separate credential, that is enrolled to your cloud account. This is that, but for any third party website, rather than just the cloud service itself.
No, they're explicitly not, they're synced to the cloud for both iOS and Android. Microsoft also plans to do cloud sync (if they don't already).
Yubikeys are device identity credentials. Passkeys are user credentials, they get backed up off device. That's a really big deal that both Google and Apple have been heavily advertising about their implementations -- you make a passkey on your phone, lose your phone, buy a new phone, and you get your passkey back when you sign into your account. They are very much user credentials rather than device credentials; anyone who has access to your iCloud can use your passkeys.
Passkeys aren't bound to your iPhone, but they are inexplicably bound to your Apple devices. That's the portability problem. The major companies (Google, Microsoft, Apple) got rid of device-bound keys. But they kept the platform lock-in.
> where almost certainly, a user HAS MANY devices.
Speak for yourself, I have exactly one device that will work as an authenticator, and even it only works as an authenticator because I've been too lazy to install LineageOS on it.
Most people own one phone and a laptop, and they frequently travel with both of them at the same time. I think Google/Microsoft/Apple went the cloud-sync direction partially in acknowledgement of the fact that "use multiple devices" doesn't really work for everyone.
You're interpreting "device" differently than I am, here. Maybe let me use a different word.
There's a physical hardware device (the device's "body") and then there's a particular installation of an OS (the device's "soul.") Unlike humans, these device "souls" can leave and come back (restoring from backup) or be reincarnated into a different body (transferring a backup to a new hardware device.)
What Apple, Google, etc. are claiming is that passkey credentials are bound to the soul of your device — the unique installation session that resulted in a unique product-key "activation" in their servers — rather than to the body of your device. So wherever the installation goes, the passkeys go along with it.
But this does not mean that passkeys are portable between installations. They still inherently represent "devices" — just semantic, abstract devices, that may be incarnated at any given time in zero or one physical hardware devices.
And, again, this is exactly how Apple's and Google's own device enrolment for sign-in to their respective cloud accounts works. I have devices listed in my iCloud account that currently have no "incarnated" form — the hardware was wiped, sold, and is now being used by someone else! — but those unique installations do still "exist" and could be "reincarnated", as long as I keep my iCloud Backup of them.
This is an interesting theory of device uniqueness that would be potentially cool to build a service around, but it is inaccurate to how passkeys are implemented.
iCloud sync is cross-device; if you make a passkey on your iOS device, it gets synced to your Mac. You can also share them with other iOS devices that aren't even linked to your iCloud account using Airdrop. They're very separate from the OS or "instance" of your device's software.
And in fact, you actually can't use platform authentication in Safari unless you sign into an iCloud account to sync your keys. Not only is it not tied to the "soul" of the device, you're not allowed to tie it to the soul of the device. Apple requires you to tie it to your account.
At their core, passkeys are a easy and nice way to move from passwords to public private key cryptography. And hardware based authentication does allow more security. And by leveraging the tpm, hardware-backed keystore, or security enclave, you can use your phone and computer the way FIDO keys are already used.
But there are many reasons why I will wait as long as possible, maybe indefinitely before I start using passkeys. The idea of this being tied to Google or any other major company for my logins is not okay. There are many cases of people being locked out of Google accounts without the ability to appeal. I don't appreciate the idea of large companies being able to whitelist which passkeys are allowed, which is possible depending on how attestation certificates are handled. With current 2factor, you can control the secrets yourself if you choose to. While it's true that you can't be phished into sharing your passkey as easily, you also lose a lot of convience and flexibility in login management. And it makes login sharing or multi-account management very inconvenient and difficult.
I was hopeful with 2FA rolled out that my accounts would be more secure, but most companies give you very little control over which methods of 2FA are allowed or enabled. I don't want to be forced to enroll a phone number just to enable TOTP 2FA. I want to be able to choose between TOTP or HOTP for my accounts. I don't want to be forced to use a 2FA app that doesn't allow me to export and manage the secrets myself. In some ways FIDO keys solve some of those issues, but the hardware security aspect of it contradicts giving the end user the choice to self manage. I expect some policies will change over time based on uptake and issues people face.
https://www.concordlawschool.edu/blog/constitutional-law/fif...
Edit: Apparently, in iOS and Android, passkeys are backed up to the cloud, and iOS even allows you to airdrop them.
https://www.nytimes.com/wirecutter/blog/what-are-passkeys-an...
Pegasus ?
> In addition, some platforms securely back your passkeys up and sync them to other devices you own.
If they can be copied (or "synced"), they can be copied to a piece of paper and copied to a nefarious actor.
It's all the dangers of 3rd party passwords - namely, before you had two parties, now you have three and thus inherently less safe - but worse.
Now, it's just even HARDER for you to control your own keys to your own stuff.
There's one and only one reasonable way to execute this, and that's to include huge liability for the 3rd parties. Unless they'll pay up or otherwise fix in the event of a breach, this is a non-starter.
To me it reeks of something that looked great, when you show a room of engineers. But for regular people?
That itself may be too complicated for some but it essentially was a few automatic prompts and instructions to scan my finger to login after it was done.
Every worry I've heard about passkeys can be leveled at 2fa schemes as well. The upside of passkeys is they can't be phished, can't be revealed in data breaches, and can't be forgotten. What third company is involved? Are you thinking about syncing services? With the exception of Linux (for now), you can have passkeys enabled on any modern device. It is just public/private key sharing right?
A bad actor would have to have your device and be able to unlock it in order to get access to your accounts secured with passkeys. Every time passkeys are mentioned on HN the FUD starts flying and people lose their minds. Passwords are terrible with many weaknesses. There isn't perfect security, there are always weaknesses but I have yet to be shown how passkeys are worse than passwords for typical users.
One being, when you're entering them on a phone in public, someone can watch you type them. This makes them easier to clone than biometrics.
Passwords are safer not because they're bulletproof. They're safer because they fail elegantly. You can't change biometrics and that's why they're definitely worse. They might be acceptable as one of many factors, but they're absolutely the worst idea for a primary.
> You can't change biometrics and that's why they're definitely worse.
Sure you can, you've got ten fingers and after that all it takes is a blowtorch.
I can't see myself using this unless I can store the passkeys in my own keepassx (or similar) system, that I can manage 100% the backup, replication + storage of myself, without any assistance from a 3rd party.