zlacker

Just like every other piece on passkeys it does not justify them, at all.

Passwords have problems, but less than putting all authentication secrets in a single basket or ecosystem is (which is what big tech fundamentally wants).

Passkeys are a solution to a manufactured problem, and keeps getting pushed because it is a useful big tech honey trap that solidifies their user's captivity in their ecosystems.

>>_Alger+(OP)
100% agree. Passwords + OTPs are the best solution, IMO. No big tech can control this, and it's easy to keep a grasp on all the credentials we have.

WebAuthn? No, thanks.

>>_Alger+(OP)
Those are pretty strong claims.

KeePassXC has support. Many people use Vaultwarden. And so on.

Also, end users are already locked into Chrome and Safari (and Meta's webview and even worse fates).

Passkeys right now has upsides and downsides, like all technology.

I think they are both too complex/clunky on the data/spec/API side, and not complex enough on the UX/lifecycle side. But likely both will evolve based on the usage patterns that get solidified.

>>reddal+A1
How does big tech exert control over your usage of WebAuthn?

>>_Alger+(OP)
This is an extremely bad take. Webauthn and Passkeys do not necessitate handing over control to "big tech". They are standards implemented by open source projects as well as megacorps. Webauthn offers substantially better security than passwords, which we should all be moving away from by now.

Disclaimer; I work in security so my opinions are informed by actually knowing what I'm talking about.

>>pas+y5
> KeePassXC has support. Many people use Vaultwarden. And so on.

It doesn’t matter if other authenticators could work if a relying party refuses to allow its users to use them.

> Also, end users are already locked into Chrome and Safari …

Not this end user; I am typing this in Firefox right now. Not coincidentally, WebAuthn is yet another bit of complexity making it slightly more difficult to implement a browser. From the perspective of the big tech companies, end users aren’t expected to write software, or to run anything the big tech companies haven vetted.

>>greent+29
> Webauthn and Passkeys do not necessitate handing over control to "big tech".

Attestation enables a relying party to deny users the right of using their own software or devices. That hands over control.

>>former+F5
By enabling relying parties to blacklist or whitelist the devices their users are allowed to use.

It’s one more brick in the wall preventing general-purpose computing. Want to authenticate to Banana Computers? Well, you have to use one of their oDevices, because they will not let you use a RoboPhone to store your passkeys.

>>greent+29
Appeal to authority does not make a good argument.

We have witnessed the user capturing playbook of big tech for decades at this point. Ignoring what they are doing at this point is naive at best, malice at worst.

>>greent+29
It might provide more security but no, more security isn't the only metric when it comes to user facing stuff like this. If it was some implementation detail in a b2b service sure. But there are a lot more variables to take into account than just "how secure it is". As a trivial example, being able to recover an account is insecure by definition, yet is almost always necessary for any user created accounts.

>>eadmun+wa
You seem to be thinking of attestation, which is not a thing anymore with at least Apple's and Google's implementation. (They both had it for their non-synchronizing device-bound authenticators, but have heavily or even entirely rolled that back in favor of passkeys.)

And since any solution excluding either of these is a non-starter, ironically the passkey push has made WebAuthN more open when it comes to client choice.

So while I agree that Apple and Google not allowing passkey exports (yet; I am cautiously optimistic that they'll eventually be pushed to offer that too) runs the risk of locking in non-sophisticated users, the future is looking very bright for everybody posting here at least.

>>eadmun+ia
Apple and Google discontinued attestation when they introduced passkeys. It's gone.

There are still lots of problems with passkeys, but it's worth staying up to date if you want to contribute to that discussion.

>>_Alger+Ba
I obviously wasn't doing an actual appeal to authority. I'm anonymous on here, so it would hold no weight even if it wasn't a poor argument. I was just being snarky because the ignorant objections are so very stupid.

I didn't argue big tech isn't doing user capture. I pointed out webauthn is a standard and does not necessitate getting into bed with "big tech".

>>eadmun+3a
> It doesn’t matter if other authenticators could work if a relying party refuses to allow its users to use them.

You keep repeating that, but that's not possible anymore, since both Apple and Google removed attestation from their respective passkey/WebAuthN implementations.

For details, see >>42522490 .

>>eadmun+wa
Yeah, you're missing the point of why attestation is in the spec in the first place.

Show me a widely available service that filters authenticators based on attestation attributes?

>>lxgr+Ql
> Apple and Google discontinued attestation when they introduced passkeys. It's gone.

It would be great if you’re correct, but these references sure seem to indicate that attestation is still a thing.

Microsoft, November 2024: https://learn.microsoft.com/en-us/entra/identity/authenticat...

Yubico: https://developers.yubico.com/Passkeys/Passkey_relying_party...

Apple: https://developer.apple.com/documentation/devicemanagement/s...

Apple: https://support.apple.com/guide/deployment/managed-device-at...

Google, September 2024: https://android-developers.googleblog.com/2024/09/attestatio...

A Tour of WebAuthn, December 2024 (aka the fine article): https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn...

>>eadmun+zT1
Android exclusively supports attestation for non-discoverable/synchronized keys, i.e. not passkeys. This also matches my observation that by opting in to attestation, you're automatically opting out of discoverable credentials and vice versa. (I don't remember from the top of my head which one you get if you both require attestation and discoverable credentials.)

TIL that Apple still supports attestation for MDMed devices, but MDM means corporate/enterprise managed devices, not regular iPhones and Macs. (I also suspect that these would be non-synchronized in the same way that Google does it.)

Yubico and other "key form factor" authenticators indeed do still offer it, which is why I only mentioned Apple and Google.

So my point stands: Passkeys as implemented by Apple and Google don't support attestation. TFA also does not contradict this.

And how would they? Attestation semantically certifies that a given key will never leave secure embedded hardware; passkeys are intentionally cloud-synchronized and users can replicate them to an unlimited number of devices.