This title is highly editorialized so as to be very misleading. The video doesn't mention Safari at all, it describes new APIs in iOS and in the web standards that allow developers to transition users to passkeys. Notably, these APIs work on iOS for whichever password manager the user has configured, not just the built in one. To the extent Safari is implicated in this at all it's that Safari implements CredentialsContainer.create [0], but that's a web standard that every major browser is implementing.
I'm all for scrutinizing the rollout of passkeys to make sure it doesn't turn into a lock in situation, but editorializing a video title is particularly egregious because, as we see in this comment thread, people are even more likely than usual to read only the title.
Yeah, it seems bad enough that Apple are seemingly encouraging developers to push their users into using passkeys without asking the user. It’ll still be the website or app that instructs the browser to create a passkey if possible, and Safari will oblige (other browsers might have the courtesy of asking which the demo didn’t seem to do for Safari on iPhone).
I really hope that developers ask their users before installing a passkey on their behalf. The assumption that whatever happens to log in now should be trusted for future logins seems dangerous, and I’d hate for passkeys to get a reputation for something people use to hijack their exes accounts or whatnot.
Assuming the Apple side of the API doesn't prompt the user before setting a passkey, sites will inevitably start using passkeys as tracking cookie replacements.
I can't believe they'd be that shortsighted when designing up the APIs for this.
That’s an interesting aspect. I’m not sure that’d be practical, but I’m not sufficiently read up on passkeys to say for sure. I don’t think passkeys are passed automatically and I really hope they’re not available via CORS? That should limit the utility of passkeys as tracking cookies. I also believe it informs the user when it’s used, based on the demo.
And if that’s an attempt at circumventing the EU ePrivacy directive (“the cookie law”) it’s unlikely to work based on my reading (IANAL) of the paragraph in question:
> Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.
The idea of using passkeys as a tracking mechanism is intellectually interesting but I am dubious that it's technically feasible with the current design.
Passkeys, be they platform or roaming authenticators, are generally bound to a public key and/or a public key + domain name. My understanding of the design is that the specification doesn't contemplate the idea of passing around passkeys via CORS or similar mechanisms. Part of the security design rests on mutual authentication by means of asymmetric cryptography.
As long as passkeys require user interaction there is a lot of friction to attempting that. And even if you could get over that hurdle, you still have all manner of other browser based hurdles.
What you could do is bind a passkey authenticated user to some kind of session/cookie tracking, but ITP/per-domain cookie restrictions would still block that.
I'm hesitant about embracing passkeys. I think passkeys are poorly implemented at this point because of the inability to move them around like passwords - I don't want to be locked in. But I don't think what he is explaining is forcing an automatic upgrade for passwords, he is explaining that it can happen at the request of the user or application prompt. Notice that the diagram - The user in the app requests to upgrade (sure, let's call it an upgrade) from a password to a passkey.
Same. I have a pair of Yubikeys that I have a quite strict process of management that I'm confident enough in. One lives in a "fireproof" lockbox, the other on my keyring - and I make decisions about whether to get the locked one out when activating 2FA immediately or wait til later based on the nature of the login I';m protecting. I will keep using this as long as needed until time and social media outrage (or lack of) proves out the effectiveness of passkeys over time.
A second Yubikey in a safe is a lower cost option than a second passkey compatible device...
What happens if both are lost? Homeless people often lose/are robbed of their possessions. Many people have abusive partners. Sudden destructive emergencies occur (house fire, night tornadoes, unfortunate simultaneous emergencies).
What is the recovery process and what prevents it from being gamed itself?
But I bet those scenarios you've posited apply equally to the devices with your passkeys on em, right? I'm confident enough that between the one on my keyring in my pocket and the one in my lockbox at home, if I've somehow lost access to _both_ of those I've got more problems in my life than my gmail/github/whatever logins.
And the recovery process and gaming thereof questions apply equally to the passkey protected accounts as well, no?
The inability to move them is a feature, not a bug. If you can't move them you can't accidentally give them to the wrong person.
A passkey only authenticates a device (or group of devices). All passkey providers must provide secondary methods for validating the identity of their users so that additional passkeys can be issued when a device is lost.
But if that secondary validation is garbage then the passkey is also garbage, but that problem is not unique to passkeys. (Strong passwords have the same problem, they're only as strong as the reset mechanism).
> The inability to move them is a feature, not a bug.
Wasn't the whole point of passkeys over FIDO2 keys the fact that you can have the same secrets stored on more than one device? (thus mitigating the largest pitfall of FIDO2 keys -- losing the physical key)
Passkeys are an implementation of FIDO2 - technically an expansion of the protocol to include so-called platform authenticators that are device bound, but also syncable credentials, which is what the major players are implementing with storage in iCloud Keychain, Google Accounts, Microsoft Accounts, password managers, etc.
In this way the promise of passkeys, and the main marketing message around passkeys, is that they are phishing-resistant. This isn't strictly true though, because within some of these syncable ecosystems you can share a passkey. For example I can AirDrop a Cloudflare passkey to someone else's iPhone. If they accept, they can now authenticate as me.
The core intentions of FIDO2 generally and passkeys specifically is sound, but solving the age-old problems of device loss, resets, impersonation, sharing, etc, are human issues that the tech companies and consortiums still can't solve. In this way I would argue that passkeys are an improvement but are oversold. They are still better than passwords for many use cases though. And IMHO should remain optional.
>In this way the promise of passkeys, and the main marketing message around passkeys, is that they are phishing-resistant. This isn't strictly true though
So, it is not true.
However, what's true is that if you're arrested, the police won't have to ask Google/Apple/anyone to give them access to your accounts.
They'll just hold the phone to your face, and get a convenient list of all your accounts and a means to log into them.
Granted, you'd need to have biometrics involved. But you can be simply asked to unlock the phone, if that's FSB doing the asking, you won't say "no".
e.g., they could block ones that allow exports, or they could block ones that are FOSS. To their credit, it looks like Apple's throwing their weight around to prevent such blocking from being technically possible.
The more I hear about this standard, the more concerned I become.
I expect Apple's focus on privacy (whether you wish to believe that is for marketing, or real) is at play here. While passkeys don't really work as a tracking mechanism, you could do some profiling based on attestation. I am sure Google would love for you to use passkeys and be able to control what devices those are used on, and know about what devices you have. "Oh you want to sign into YouTube? Are you really on an iPhone, or are you pretending it's an iPhone?"
I use AAGUID attestation for Yubikeys at work, but that addresses an actual security need to enforce known authenticator types and prevent enrollment of non-hardware tokens.
Losing access to a service because of device loss is part of threat model for most people (including me). Security isn't binary. Failure to provide adequate recovery should be treated as insecurity.
Always do threat modeling when talking about security, otherwise you end up just bike shedding.
No joke, I once recovered access to google account by loading a TOTP backup in an app in Android emulator. Otherwise I might have been a bit in trouble.
When I bought a new iPhone, and restored it from my old phones backup, my TOTP data from the Google Authenticator apparently didn’t make the trip.
If I didn’t have my GitHub recovery codes, I would have been in trouble.
Arguably, that’s what those are for. But the key point is that I did a mundane, routine transaction. My house didn’t catch fire, my phone wasn’t stolen, I didn’t act negligently. But I was potentially this ][ close to disaster.
Computer security is usually defined as achieving three things: Confidentiality, Integrity and Availability.
If device loss (or a google/apple account ban) leads to permanent loss of access to your (other) accounts, then passkeys aren't providing availability, so they're not secure.
Put another way: If you ignore availability, then passwords are even more secure than passkeys when used "correctly":
When creating a new account, choose a random 80 digit string for your password and don't record it anywhere. Also, don't set up an account recovery email address / phone number / etc.
Of course, you're always at the mercy of customer service. Not having a backup email or phone number can make your account easier to attack since the customer service agent has fewer options before they resort to just giving your account away to the attacker.
And those experts have designed something entirely inappropriate for non-corporate users (who can't just have IT reset their credentials) largely solving problems no one has while introducing real problems (e.g. accidental self-DOS and backdooring device attestation into the web again).
Browser generated strong passwords with auto fill exists today, pretty much solves all security concerns, and doesn't have the same pitfalls.
>From the perspective of the security experts who designed the system, it's a feature and a requirement.
Great, all day I dream of making someone else's job easier by adding hassles to my life.
What's next from the "security experts", booby-trapping front door entrances to deter thieves?
Oh, I have another idea. Let's restrict the number of accounts people can have to, like, two, so that they don't have to struggle with remembering passwords! From the perspective of IT helpdesk, it's a feature and a requirement.
It doesn't seem like it will i.e. _delete_ your username/password, but the behavior is actually automatic without user prompt.
See 1:10-ish[0] for the demo - I found this at least somewhat surprising, though I submit this as a passkey advocate (for a while, my side business only-supported passkeys, but we backed away from that).
I'm using exportable passkeys in .kdbx format right now. There's no reason conceptually why passkeys have to be non-exportable. Regular keys are only seldom implemented in that way.
Yeah. For a while when I was mostly working on mobile apps, I'd switch between iOS and Android every year. I've almost like clockwork switched between macOS and Windows with every job change. I'm very much leaning into going all Linux for personal stuff based on MS and Apple's pushing Gen AI into the OS.
I'll stick to Yubikeys and TOTP 2FA for as long as I can instead of jumping into passkeys.
Think about all the regular (read: non-Hacker News) users out there who fall for a phishing email/SMS, or who re-use passwords and get popped by a credential stuffing attack. Passkeys provide not only massively-improved security (they can’t be keylogged; they are linked to a specific domain so can’t be spoofed by look-alike fake login pages; they’re protected from replay attacks even if the transport mechanism is compromised), but a much nicer login flow as a bonus.
Many people also don’t understand how easy it is to login from a different device: say an Android user created a passkey for a site with Chrome. Now that user needs to sign in to the same site on a Mac running Safari (where there is no passkey for the user). They can still use their Android device to login from the Mac by selecting “use a passkey from another device”. Safari will show a QR code that they scan using the Android phone, and verify with their screen lock. A one-time passkey signature is transferred to the Mac, which the website uses to authenticate the user. The two devices verify that they are in proximity with each other using Bluetooth. This cross-device, cross-operating-system mechanism of passkey authentication is standardized under FIDO; no additional work is needed by the website to enable this login flow.
If you are “anti-Apple” or “anti-Google” and have strong aversions to them securely backing up things like passkeys (again, think of all the non-Hacker News readers where this is not the case), then go ahead and continue to use passwords. But we should be encouraging our parents, grandparents, siblings, friends, etc. to embrace passkeys to make all of their accounts more secure and phishing-resistant. The more passkey FUD they see, the longer people will have to deal with annoying (and still insecure) SMS codes, the longer passwords will be stolen/re-used, etc.
Because a standard with device attestation should be rejected outright, real world implementations use it as a form of lock-in, and password managers are more ubiquitously available anyway (e.g. I can't use passkeys on my primary computer, which doesn't have the necessary hardware). This would be different if browsers added software implementations with easy export first and removed the attestation part of the standard, but they didn't.
I see device attestation is a different issue. Passkeys don't have to have device attestation. FIDO2 has long-supported this already in the form of AAGUIDs [1] which do address a valid use case of wanting to restrict the kinds of authenticators that can be used. For example if you have FIPS requirements.
I do agree that passkeys, implemented in software, should categorically prohibit attestation. I think the cost of needing attestation should be that you have to require/invest in the actual hardware tokens.
Attestation does not belong in a standard that's used with consumer devices. Make the payloads extensible so that corporations/gov can add their own attestation data as an extension if they want, but websites have no business being able to enforce whether I am using a Microsoft or Google approved device, and e.g. banks inevitably will unthinkingly add it as a "best practice" if it's there (they already do this with mobile apps). This decreases user security as the options we all know will make up the acceptable list are compromised with built-in malware today.
I don’t think it’s realistic to expect browsers to not support attestation.
Business is already able to use attestation to enforce/deny the use of specific kinds of keys. Removing this ability would break web based SSO for businesses that rely on that ability. For example, if that vanished overnight then the only way I’d be able to login to our Entra tenant is via a break glass account that is exempt from attestation.
If you want your bank employees to be able to authenticate to web applications with _only_ approved authenticators, then attestation is the way that is accomplished.
You can do FIDO2 Enterprise Attestation as well, but those devices aren’t generally available outside of (rather pricy) enterprise sales channels and require more overhead.
Device attestation with consumers is already unpopular. Google experienced this recently with their “Web Environment Integrity” ~~con~~ proposal. It’s also a logistical nightmare. If Apple, for example, supported attestation then anyone who implements it now has a bunch of additional headaches in keeping it updated with fingerprints and the risk of extra failure cases.
The people who want attestation for consumers don’t have their interests at heart, and the people who would have to implement attestation in consumer devices aren’t interested in doing that. Except for Google, because it suits their interests.
I’m not saying the case is strong that attestation won’t happen. I’m simply saying the case for attestation in business contexts is strong, is already deployed and relied upon. The interest for consumer attestation isn’t very well aligned with those who have to do the work to make it happen. Google is an exception to that and sound technical and policy minds keep showing their attempts the door.
Edit to add: for better or worse, consumer and business devices are virtually the same these days. I would argue it’s worse to bifurcate them because that would enable rapidly realizing the world none of us want where no one has any control over any part of their device unless it’s owned by a business.
Attestation is going to be abused. The only thing it is useful for is establishing centralized control over client software. That'll eventually imply that all clients are user hostile, probably both from a surveillance capitalism perspective, and from a government surveillance perspective.
This isn't a theoretical concerns. All of the groundwork (except device attestation at login) has already been laid:
- The US CLOUD act already says that service providers have to provide the government with access to all information they're technically capable of accessing.
- Microsoft's existing client debugging mechanisms allow them to pull files from windows machines with management approval.
Once there's a de facto ban on running web browser binaries that aren't produced by a FAANG (established by the passkey standard), all the vendors have to do is add MS-style telemetry / debugging, and it's game over. In all likelihood, there will be legislation in a few years that forces any holdouts to implement that sort of a mechanism.
Passkeys are great. Me and my colleague are sharing a GitHub account that we use for managing a GitHub app on our autograder server. Previously we had to share the password. Six months ago we set up one passkey each on the GitHub account and no longer need to think about the password.
(We are only using this GitHub account for this one thing, and we don’t use it for commits etc.)
The trouble is, Apple devices, which Apple can update remotely and for which no one external can see the source code, are trusted. There's this one huge single point of failure.
Can you use this without iCloud? Can you avoid any iCloud involvement?
EDIT: I know many people love their Apple devices and take criticism of that company as a personal attack, but please consider that I speak from experience of a US person whose laptop and cellphone were stolen in Poland in 2022.
Instead of downvoting, please help me understand: how would one re-gain access to services used with passkeys in this scenario?
Note that T-Mobile won't ship a SIM card overseas.
-----
Great reason to not use Apple ecosystem.
Having a cellphone / laptop broken and/or stolen is enough hassle without all the authentication being tied to the device that you aren't likely to use for more than a couple of years anyway.
And yes, things like that actually happen to people who are not CEO of Apple. Especially while traveling, when your other devices are far away.
It sounds like someone decided to reinvent 2FA hardware in the worse way, combining the inconvenience of needing a physical key with all the hassles of password and adding a million ways for the key to self-destruct.
Oh, the passkeys can be transferred through the cloud? Explain like I'm five how that's more secure than email/SMS OTP for authentication then (which are an awful thing too, but at least I can have my own email). So we have one more link in the security theater that I absolutely trust is more secure than having passwords.txt in Dropbox (how is it different, again?).
From a user's perspective, passkeys sound like a solution in search of a problem. The only thing I can see passkeys doing for me is locking me out of my accounts when I need them most.
This is straightforward illegal monopoly nightmare fuel right here. Apple passkeys are going to be locked-in into their infrastructure, with no possibility to easily switch devices.
This doesn't have to be true, there are third-party password managers with Passkeys support (e.g. BitWarden), but they are not going to be able to access Passwords. It's specifically locked to only browser applications, Apple will not provide entitlement to access the keychain for any other app.
This isn’t true as far as I can tell: when you create a passkey on iOS, the first screen prompts for which app to use to create the passkey and LastPass, at least, implements the necessary APIs
Maybe not, but you can install 1Password later, go to the account with the iCloud passkey and use it once, then use 1Password to generate a new passkey for that account. This flow is also generally better than trying to port keys between accounts, which adds a lot of security concerns.
I might not understand the tech as well as you do, but does BitWarden have rights to read 1Password vault, or 1Password have rights to read the Lastpass vault?
Generally I thought with passkeys, the logic is that you provision one passkey per app you want to have access to a service?
Ie, I can provision a separate passkey for GitHub, for instance, both in 1Password, and in Keychain if I like, and sign in to the service with either one?
BitWarden technically can read the 1Password vault on macOS, though not on iOS. Unless 1Password developer agrees to the collaboration. This is kinda expected, given the crazy locked-down iOS.
I don't believe there are easy legitimate ways to work around it. Disabling SIP (System Integrity Protection) will render passkeys inaccessible, though I'm not sure about that.
> Generally I thought with passkeys, the logic is that you provision one passkey per app you want to have access to a service?
Passkey is basically a private key that is specific for a given site. Nothing more, nothing less. So you will have separate passkeys for Hacker News, Slashdot, Reddit, eBay, etc. They will be stored in iCloud Keychain and synchronized across devices.
Apple is not going to provide easy ways to bulk-export all this data if you want to migrate to Windows. Or maybe even to switch a browser.
If you use an alternative password manager like BitWarden, your ability to export passkeys will depend on its implementation.
I'm all for scrutinizing the rollout of passkeys to make sure it doesn't turn into a lock in situation, but editorializing a video title is particularly egregious because, as we see in this comment thread, people are even more likely than usual to read only the title.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Credentials...