WorldMaker

The big situation is enrolling an Apple consumer device under corporate management, which Apple calls "Declarative Configuration" and others call things like MDM. Declarative Configuration can turn on Apple's support for attestation (and is today "the only way" to get Apple's official attestation support).

Declarative Configuration is also the thing that allows the controlling corporation to remotely wipe the phone and other such things where they own the phone more than you do.

I know not every person has the luxury of telling their employers that they will not install corporate apps on personal phones and that if their employer wants to own their phone they should pay for a separate work phone. But that is the big scenario to avoid attestation becoming more common in the wild, making sure people realize that "No work apps on personal phones" is maybe something worth striking about.

I don't know how you could screw that up and not break the UX flow in a way that would have some sort of noticeable hiccup, given the Webauthn API as it has been standardized. The response to a Passkey challenge includes only a short fingerprint or "unique name" of the public key, not the full public key. Off the top of my head I think you only see the full public key in registration steps, and then if you try to re-register a key most Passkey implementations are going to enroll an entirely different key.

I'm sure that there are big enough fools out there, I'm just thinking there might be signs they are doing something wrong in that case.

Netflix already tries to crackdown on account reuse by policing the number and type of devices you install it on at the same time. They don't necessarily need to double down on it by policing Passkeys. But also "Netflix is a bad actor" is a threat model that has a market correction: If you can't login to your Netflix account then don't pay for your Netflix subscription.

Netflix is more incentivized to keep people paying subscriptions than they are worried about people sharing passwords or passkeys. No one "needs" Netflix, it's an entertainment service. If they are truly a bad actor with respect to Passkeys then they upset too many consumers and lose a chunk of their audience.

I have started using Passkeys everywhere that I can. One of my "requirements" is "do they support multiple key enrollment". Most do, it's sort of required by the spec and semi-required in practice by the giant number of consumers in the US with iOS or Android phones and Windows PCs. The open source libraries certainly push you in the direction of implementing it properly multi-key per user. (I've also implemented Passkey-Only website login.)

I generally add keys from two very different Password Managers to every site/app I use Passkeys with. Both Password Managers also sync between multiple devices I own.

Redundancy is already an option. Choice in Password Managers to use for your Passkeys is an option.

I understand that accidental denial of service fear, but the tools exist technically to deal with that fear if you wanted to try to deal with it.

"They". Again, it was one guy, who didn't have the full backing of his employer much "the FIDO group". Who made a suggestion, though it was written as a threat because he was bad at communication.

Not to mention the only way to blacklist a specific app from Passkeys is to use the AAGUID from attestation which means it only applies to attestation. A few pieces of software were providing AAGUIDs by choice even when not attested and Apple helped remind them that the spec says non-attested Passkeys should always just return an Empty UUID (all zeroes) in AAGUID. The people that are going to block non-attested Passkeys might as well block all of them, including Apple consumer Passkeys.

My understanding is that some of the curves are still considered high enough entropy that the number of qubits needed is "unreasonable". The important point remains though that passkeys don't have a fixed encryption suite and can be updated over time.

In best practices for SSH keys you should be using different keys on every device and shouldn't be extracting/copying them. Best practices are also to use different keys for every SSH host in addition to per-device keys.

Passkeys enforcing keys not be extracted/copyed as plaintext and that keys are per-host/domain are just following ancient SSH best practices.

Because yes the SSH world is sloppy with dangerous plaintext (or modest password encrypted) key copying and reuse. That does make it a "simpler" ecosystem, but that doesn't make it a better ecosystem.

That said, Passkeys generally are frequently copied, most of the ecosystems support multi-device sync and backup. They just aren't done in a way that provide plaintext export if you want to print a book of your Passkeys and store it in a safe deposit box or sloppily `scp` them from one machine to another.

It seems to vary with how often you purchase things from the App Store and iTunes Store and how "high value" your account seems to some sort of iOS metrics. Which is why it also often seems like "phone is in a weird state after a software update" as that is probably also when some of these metrics reset/get rechecked.

Apple does not support Passkey attestation on consumer devices. They've said between user privacy concerns and user experience concerns (syncing and backup are critical requirements to non-technical users) they will not support attestation on consumer passkeys. They worked through the standards process to push compromise standards that are not attested but help with some of the "compliance issues" that might have come to require consumer passkey attestation (these are the uvi and uvm extensions which are not attested and essentially are "I solemnly swear a biometric unlock was used to access this key" for basic 2FA/MFA CYA).

So the "biggest providers" very much have some champions against attestation.

You can use it computer to computer, too, as long as the laptop has a camera to read QR codes.

In theory phones and watches could implement the other direction and generate the QR codes, there's just less pressure on the ecosystems to make that easy to do so it's not there in practice today.

It's easy to install Chrome on most devices and even iCloud Passwords has an okayish and getting better Windows app today that works in supported browsers. (It would be nice if it also acted as a Windows-wide plugin for Passkeys, but it doesn't yet today.)

2FA exists because defense in depth. Even if passwords weren't phishable, it can still be handy to defense in depth that a person is who they say they are by checking multiple factors ("something you know", "something you are", "something you have").

Passkeys largely meet 2FA requirements by themselves because they are "something you have" (its stored on a device you own) and require "something you know" (device PIN) or "something you are" (biometric unlock) to use.

Passkeys in their current state essentially are just SSH keys with added website verification.

A lot of the "slippery slope" confusion in the past couple of articles has been that this "cheap SSH key" approach was built on top of the same standard for "expensive hardware key" (Webauthn). This is great because it means a rich backwards compatibility story across a long history of devices and "expensive hardware key" remains an option for Passkeys. This is unfortunately confusing because Enterprises still need Webauthn for "only expensive hardware key" usage so need options in the standard like "Attestation" which specifies things like "exactly which expensive hardware key vendor was used".

People see this confusion and think it leads to a slippery slope of attestation being required "in the future", but the reality is more that attestation and things like it were required in the past and are optional now because we realize "cheap SSH keys" are good enough for most users (with some standardization and shared "branding").

My dad didn't like iCloud Passwords because he still uses a Windows laptop and only recently has the iCloud Passwords app been good or all that useful. We settled on 1Password a few years ago and having 1Password on his phone and setup as his default password app means that iOS uses it as the default Passkey app as well. "It just works."

The vendors could use it to enhance lock in, but for the most part the vendors all seem in agreement that the rising tide safety to float all boats of Passkeys is worth investing in making them friendly, especially to non-technical users, and to some extent try to avoid direct lock-in.

Most "Passkey" branded approaches are portable. The "not portable" subset of Passkeys is primarily backwards compatibility with things like Yubikeys. That's also what attestation is mostly for, backwards compatibility with applications and Enterprises that still need "this is specifically the physical Yubikey I mailed this user" type keys, not as much Passkeys.

That wasn't FIDO as a group. That was one vocal member and even their employer ended up disowning the comment. It also wasn't about sync, it was about plaintext export.

It's not on by default but there has been a packed ref format for git for some time that can be opted into for repos with lots of refs. It's one of the things being considered for the new default in the 3.0 defaults review.

https://git-scm.com/docs/git-pack-refs

I'm a big fan of just adding a simple script like `git describe --always --dirty > VERSION` in the output files of the deployment process. Or otherwise including it in bundle or executable metadata. (Subtly reformatting it to pass to `dotnet build -p:Version $GITDESCRIBEISH`, for instance, or putting it into a .json file that a web service will statically serve.) Similarly outputting `git describe --always --dirty` into CI/CD logs can be very handy.

You can use git describe's output to exactly name a commit. You can also use annotated tags to tag semver releases or marver (Marketing Version) releases and if you output the git describe to users that care about semver or marver they see confidence in your deployment system when you deploy exactly a tag versus deploy something like a hotfix after it. But git describe is also useful for lower environments because it will have useful output when not directly on a tag.

(ETA: For a monorepo you can still use semver/marver annotated tags with `git describe --match subproject/` to use a tree structure for tags.)

- Your Passkey Manager generally offers some form of multi-device sync. Most Passkey Managers are the same as Password Managers so it may even be a multi-device sync you are already used to.

- Devices support a flow where a QR Code kicks off a Bluetooth LE handshake between two devices to sign a one time Passkey challenge. That can be used for one time login on devices you don't sync your Password Manager to or to help bootstrap additional Passkeys on the new device.

It's definitely not a unicorn situation.

Copy and paste is not a skill that requires much technical literacy. I've not seen a Password Manager that makes the copy button hidden or hard to find or need much technical skill to use.

Many "legitimate" websites, especially corporate "SSO", accidentally train users that autofill just doesn't work some of the time. Example Corporation's SSO configuration generally has users put their password into auth.example.com, except when the app in question is using some weird SAML flow and accidentally ends up at saml.example.com or auth.okta.com. An old legacy internal app still needs the password inputted in an HTML Basic Auth prompt due to a redirect through oldauth.example.com. The user learns to just copy and paste and have no idea why autofill works on some internal apps and not others because they have no idea what SAML is or why a legacy app is special/different from modern ones.

It happens on the public web, too, to a lesser extent. A website goes through a "rearranging deck chairs phase" and can't decide if id.example.com is cooler than auth.example.com or if they should just put login only on top level example.com and flip back and forth over a few weeks as different internal teams "win" or various A/B tests run.

> Passkeys don't offer portability, user choice, or user control.

This is objectively false. Every major platform provides user choice in Passkey Manager. It's the same flow/settings to setting up a third party Password Manager.

All of the ecosystems have defaults that include some amount of portability: iOS defaults to Passkeys synced through iCloud Password Manager and backed up/restored with device backups. Android defaults to Passkeys synced through Chrome Password Manager. Windows defaults to Passkeys synced through Edge Password Manager. All of the ecosystems have plugin systems to support third party Password/Passkey Managers such as 1Password or Bitwarden.

Most devices that support Passkeys support a QR code bootstrapped flow for cross-device/cross-ecosystem Passkey challenge signing via Bluetooth LE.

Most ecosystems deliberately don't provide explicit private import/export to help protect users, but that's more an implementation detail than a technical requirement, and mostly not an implementation detail for "lock in" reasons but for simple security reasons: the private key you cannot export is the private key that is harder to steal by bad actors. The private key that you cannot manually import is the private key that can't be installed by bad actors.

How? Public keys are public keys. They are designed for full disclosure. They are "leak proof" in the sense that leaks should not ever matter. The useful thing about public key infrastructure is that it asymmetrically moves the security threat to managing the private key, which is in the user's hands, and away from the public key. With a strong password I have to assume that both my Password Manager is up to the task of not leaking it and that the remote website handles my password correctly (including salting and hashing and not leaking and not using a hash algorithm with known collision flaws and not using a hash algorithm with large well known rainbow tables, etc…). With a passkey I mostly only have to worry that my Password Manager is up to the task, those are the threat models I get to worry about, I no longer have to worry about if a remote website is keeping pace in the ongoing arms race because all they have is a public key that I don't care if it leaks.

The threat models here are often very similar to existing Password Manager threat models. If an attacker gets access to your Password Manager they get access to every password you have stored there and can do what they like with that information. The same applies to your Passkey Manager, which in many cases (including for your own peace of mind) is/should be the same app/vault as your Password Manager for other types of passwords.

A lot of the same Password Manager requirements and best practices apply to Passkey Management such as using strong master passwords or biometric unlocks or device PINs. Using Password Managers that support device bound hardware security enclaves, etc.

But even more so than average Password Management, because Passkeys are public key infrastructure the benefits you get out of the box exceed those of ordinary passwords. One of the factors in most Passkey implementations here is that sites (defined by hostname) all get different public keys. (Users are suggested to use different passwords for every site, but are not required to. Passkeys do that technically and are generally enforced in that effort by browsers and Operating Systems.) Leaking those public keys is no longer an issue (they truly are public keys), and leaked public keys aren't generally useful to other sites and apps. (Passwords that leak and even sometimes salted and hashed passwords that leak are liabilities and can be useful for rainbow table attacks or social engineering attacks or password reuse attacks.)

There are certainly edge cases to Passkey Management but in general the threat models follow Password Management threats: does someone have physical access to your device? Do they have access to your biometrics or device PINs?

But also the blast radius is reduced compared to usual Password Management threats: a single leaked private key generally only impacts a single website/app. Being able to sign a Passkey challenge once doesn't mean unlimited access (a password can be used forever after finding it), because challenges have timestamps and random entropy and generally don't support replay at all.

Most Passkey implementations by default are syncable/copyable/backupable. The iOS default is iCloud Password Manager and keys get backed up to iCloud and restored on device restore when replacing a phone (just like the rest of the users passwords they choose to store). Android has similar defaults with the Chrome Password Manager.

Most Passkeys use PQ PKI algorithms. From statistics I've seen most are Elliptic Curve on currently recommended PQ curves.

For better and worse, Webauthn is one of the "choose your own adventure" PKI systems where the keys themselves suggest which PKI algorithm/details they use. This is partly because Webauthn has been around a long time and has had to backwards compatibly support a wide variety of physical security keys over the ages.

Most good open source libraries for implementing passkeys will do a good job of limiting passkeys to known good algorithm choices, including any PQ requirements/suggestions. The Passkey standard itself also sets a "higher water" baseline above Webauthn's supported algorithm list.

iOS has really good support for third party Password Managers. I've seen the integration with both Strongbox and 1Password. I've heard Bitwarden supports it as well. I think it is a Lastpass problem in this specific case.

Supporting multiple passkeys should be a minimum requirement for every Passkey implementation. It's generally worth naming and shaming the websites that don't implement that correctly. People want backup passkeys. People want both iOS keys and Windows keys for the most convenience.

My general advice for non-technical users that seems to work pretty well is "sign up for new sites with passkeys on your phone" because most non-technical people trust the password manager ecosystem on their phone, have some amount of multi-device sync already established, and the QR code started Bluetooth LE flow on desktop/Windows PCs for sharing passkeys works easiest with phone passkeys.

(I run a tiny site that is Passkey Only for login and it's been interesting providing technical support for it. One of the biggest recurring issues at this point is nothing in the Passkey flows themselves but the fact that the Facebook in app browser does not support Passkeys for a number of presumably security reasons, plus Meta being jerks, and having to remind new users to "Open in External Browser" before signing up/logging in when posting links to the site in Facebook.)

> The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows

It's still just biometrics as "device PIN". The crucial difference remains that the biometric data never leaves your device. To support Passkeys the remote website only ever sees your Passkeys' public keys, they never see biometric data, they never have a chance to store biometric data in a database to violate PII/HIPPAA/etc standards when it inevitably leaks to "hackers" (or gets sold to the highest bidder).

If you find a Brother printer is full price from Staples, Best Buy, and the Brother website, but $50 off on Amazon, you take that price information to your in person Staples or Best Buy and ask if they price match it. They look at your rewards card/members card, say "Sure" and throw in extra toner at a good price. Or they point out that you are looking at a counterfeit product on Amazon and you get a good collective laugh.

I don't know. I haven't heard loud complaints about it, at least. It certainly has taken me a few days to get used to it.

Mine has my home address saved. I think you have to save your home address in Apple Maps.