[stavros]

The thread here seems like a dumpster fire to me. Everyone here is worrying about lock-in to an open standard, so I want to clarify things.

WebAuthn is an open standard. It's a way for you to prove to a website that you have a specific private key. There's no lock-in, because the key is portable (unless you don't want it to be). There's no privacy issue, because the key is unique per website. There's no security issue, because it's unphishable and can be unstealable if it's in hardware.

If you don't like Google or Apple, use your favorite password manager. All it will have to keep is a private key per website, and you're done. No usernames or passwords. You visit a site and are automatically logged in with a browser prompt.

This is amazing, it's the best thing that's ever happened to authentication. It's something the end user cannot have stolen. Can we be a bit more excited about it?

EDIT: If you want to try it, I just verified that https://www.pastery.net/ works great with Passkeys even though I haven't touched the code in a year.

That means that django-webauthin also works great with Passkeys, for you Django users:

https://pypi.org/project/django-webauthin/

Also, the latest Firefox on Android seems to work great.

[quadrifoliate]

> The thread here seems like a dumpster fire to me. Everyone here is worrying about lock-in to an open standard.

There is a certain fiddling-while-Rome-burns quality to this comment. The blog post is not about the open standard, it explicitly focuses on a specific company's products. People are naturally worried about this even though the standard may be open, because we are at historically high levels of platform lock-in from megacorps. Gmail is the new "Blue E". Getting locked out of your Google account in 2022 is probably much worse than not being able to use a different browser in 2001.

Sure, HTTP is also an "open standard". How many real browsers exist that can play DRM-encumbered media? You'll find that the answer is "very few – basically anything made by Apple, Google, or Mozilla" (perhaps Brave as well, which has an ex-Mozilla founder and uses Google-funded tech).

The best way to get people to adopt the open standard is to actually showcase uses of it that are not just a single company's product, not call them names for being worried about lock-in.

[stavros]

Right, but that's like Gmail coming out and people complaining about another proprietary product locking people in. There are two issues with the current comments:

1. Absolutely nobody currently uses WebAuthn. I'm extremely excited about the popularization, which, unfortunately, requires big players to get behind it.

2. The comments feel very "oh my God this car I'm driving is heading towards the edge of the cliff even faster". Don't use Google, they're unreliable and evil. While I'm very excited about Passkeys popularizing WebAuthn, I don't think anyone should ever rely on Google for authentication, so just don't use them and use Bitwarden instead, if/when it supports Passkeys.

A vendor coming up with an implementation of a great standard isn't the problem, the fact that people use it is the problem.

[Mindless2112]

> If you don't like Google or Apple, use your favorite password manager.

Unless the service you are trying to use requires that you use a particular model of authenticator, which the service provider can enforce via attestation.

[martin_k]

> Unless the service you are trying to use requires that you use a particular model of authenticator, which the service provider can enforce via attestation.

Android's implementation of passkeys currently does not support attestation. https://groups.google.com/a/fidoalliance.org/g/fido-dev/c/nh...

Neither does Apple's, I believe.

[Mindless2112]

Good to know! Hopefully this kills off unnecessary use of attestation.

[oezi]

Isn't it even worse? Browser vendors don't even offer any way to not use their baked-in authenticator? With WebAuthn they offered at least the options of using a security key via Bluetooth/NFC/Bluetooth as alternatives to the device authenticator. I don't see that option with passkeys.

So, there seems no way to use a password manager with passkeys.

[andrewxdiamond]

They can do this with SSO provided by third parties now.

[Mindless2112]

Sure, but passkeys are meant to replace passwords, not SSO (although I won't complain if they do replace SSO).

Most services probably would not restrict you to just one model of authenticator, but it wouldn't surprise me at all to see a service require that the authenticator be backed by a secure element, in which case you could use a security key, a passkey, a TPM, et cetera, but not a password manager. I'd still take that over passwords, but I don't think everyone would.

[minimaxir]

I recently got hardware TOTP keys and I wanted to use them with my financial accounts but all the banks have their own propritary authenticators :(

[rzimmerman]

I'm also surprised at how negative the reaction here is to Google embracing an open standard. Both Android and iOS devices keep your passwords/keys encrypted end-to-end between your devices. You can absolutely share passkeys between devices (if you want to) and even make them exportable to another secrets manager (if you want to).

If you ask me what's one thing in 2030 people will look back on and say "I can't believe we did that!" I'd have to say "passwords". Passwords need to die and WebAuthn is a great step forward.

[mimi89999]

Yes, WebAuthn is an open standard, but it seems that Passkeys can only be synced using Google password manager and I don't see any API that would allow the user to use a different password manager as is the case with the auto fill API.

[stavros]

Ah, that's interesting. So if I use Apple keys to log in to sites, I can never log in to them with my Android phone? That's unfortunate, though I don't see this being sustainable for too long, I imagine (and hope) they'll open it up to alternate authenticators soon.

[acdha]

Based on the way implementers at those companies have talked about it, I don't think that's the desired long-term state of affairs. One thing Adam Langley mentioned in https://www.buzzsprout.com/1822302/11122508-passkeys-feat-ad... was that the BLE handshake identifies the cloud service to use because they need to support corporations using their own services for all of their devices. Hopefully there'll be enough demand for that to ensure it's fully implemented soon.

[novok]

As long as you don't need master key escrow to essentially be with the vendor (ex google / apple), you can have the master key backed up elsewhere so you can pass the mud puddle test [0], and the vendor has no way to access the master key, I'm ok.

But push google / apple about solving mud puddle problems and it's curiously missing from their wallet implementations and they stutter around it when they give talks about FIDO2 and such and people ask them. It's the lock in direction they see everyone going towards that makes people uncomfortable.

[0] https://blog.cryptographyengineering.com/2012/04/05/icloud-w...

[xg15]

> There's no lock-in, because the key is portable (unless you don't want it to be).

> There's no security issue, because it's unphishable and can be unstealable if it's in hardware.

You mean, you can (in theory) choose whether you'd rather have a lock-in or a security issue. Both options are mutually exclusive, you can't have them both at the same time.

[stavros]

No, I don't. You don't have to use Google's thing, use an open source password manager that syncs via Dropbox or whatever. Same thing, different vendor.

[xg15]

Sure I can. But then, if an attacker gains access to my device, so can they. They can just set the phone to sync with their own cloud service.

Phishing would also be back on the table: The phishers' narrative would just change to something like "Dear $user, we're upgrading our systems. For technical reasons, please change your sync target to $url, otherwise you will lose access to all your logins. Yours truly, Dropbox"

My understanding was that many of the advertised security properties of passwordless logins stem from the property that no one, not even the owner of the account has access to the key. This renders phishing impossible because the user cannot physically give away the key even if they wanted to.

But that solution is fundamentally incompatible with copying the key to anywhere else.

[stavros]

No, it's not a choice between "lock in" and "security issue". Google is both "lock in" and "security issue". A Solo key is neither.

The tradeoff is, as always, between security and convenience.

[oezi]

> EDIT: If you want to try it, I just verified that https://www.pastery.net/ works great with Passkeys even though I haven't touched the code in a year.

It does not work with Chrome on Android.

[stavros]

Ah, thanks, I'll look into it.

[mimi89999]

It's a known issue with Android. You need to install Play Services beta. It will work flawlessly.

[webmobdev]

> There's no privacy issue

There is a real privacy issue if online services will now force you to store your "passwords" on a device - whether it be in your phone or a password manager.

[PassageNick]

The passkeys are stored in a Trusted Platform Module, and as far as I know, it is basically impregnable, even with access to the physical device.

[webmobdev]

That's irrelevant as the real issue is that if anyone gets access to your device, they can then get access to all your online accounts.

[PassageNick]

Well, no, that is not right. Passkeys most definitely not available to someone who steals your phone.