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 issu…
Bringing passkeys to Android and Chrome
241–250 of 264 posts
Re: Bringing passkeys to Android and Chrome
#242Earlier quoted context omitted.
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.
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, Dropbo…
The tradeoff is, as always, between security and convenience.
Re: Bringing passkeys to Android and Chrome
#243The 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 issu…
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.
Re: Bringing passkeys to Android and Chrome
#244Earlier quoted context omitted.
I founded Hellō to solve this problem. A neutral service where you get to choose how to login, and how you can recover your Hellō Wallet. Done. See Show HN post I wrote this morning https://news.ycombinator.com/item?id=33178285
I think you've pasted the wrong link.
Re: Bringing passkeys to Android and Chrome
#245Earlier quoted context omitted.
The entire third party auth push has turned into what may be one of the largest incumbent power grabs I have ever seen. Stuff like Google Amp or even App Store walled gardens pale in comparison. What drives me nuts is how little discussion of this I've seen. People don't even seem aware of the implications of it. It's being pushed hard as a boon to security, which it is in some cases, but at a cost that nobody is eve…
Man, every one of these comments has completely misunderstood the point. WebAuthn is an open standard. The provider is only there to sync your key. If you want, you can keep it yourself. Why is everyone yelling about the sky falling down when this is the best thing to happen to authentication since ever?
All I'm saying is that authentication is literally the keys to the castle, and inviting third party control of authentication has some scary implications in terms of privacy, monopoly control, and security.
We should at least be discussing this, but I don't really see that much discussion. People are just blindly adopting this stuff because it's convenient and not even thinking about what's under the hood or whether there is a way to back out or change provider.
Re: Bringing passkeys to Android and Chrome
#246Earlier quoted context omitted.
First, note that the article you linked is pretty old — the people who build biometric systems have added countermeasures in the last couple decades. They're definitely not perfect but it's not an especially easy attack since it's personalized and doesn't scale. The first thing to remember is that your fingerprints / face scan are not the identifier for your passkey. They are used by the local device to unlock its se…
> The interface also does not provide access to the private keys ever There are both statements all over this thread, "the private key is inextricably bound to the device" and "the private key can be backed up". This seems to be an attempt to declare both the problem with theft and the problem with lost devices as solved. Except, they are mutually exclusive: If the key is bound to the device, I can't back it up. If I…
It's a bit more complicated than that: if you enable synchronization, Google or Apple have stored encrypted blobs but they don't have access to the data. To decrypt it you still need access to one of your linked devices.
The other thing to remember is that the keys can be exposed only for the time it takes to install them: you get a new phone, it downloads the blob and has one of the other devices approve decryption, and that key is immediately re-encrypted locally. That makes it a lot harder to get a copy because the attacker has to compromise one of the registered devices enough to attack that process rather than simply getting access to an unlocked phone.
Finally, it's not as simple as one-key-to-rule-them-all: the WebAuthn handshake has both the synced key and a device key. That means that a high-security application could still do additional checks any time they see the synced key used with a previously-unseen device key.
> If a phone is in the wrong hands, it's much easier to gain access to the phone using fingerprints than it is using passwords: There is a good chance some usable fingerprints from you are still on the device cover itself. Sure, an attacker would need some resources to take the fingerprints and build something that can be used with the phone's sensor, but if enough people use fingerprints for auth, attackers will streamline this step quickly.
Again, I would suggest looking at the decades of prior art (or considering that it's moot for the majority of Apple users using infrared facial scans with liveness checks). It's actually pretty hard to get usable prints since they need to have some structure, not just a single flat image, and people don't commonly build phone cases out of things which record that kind of detail.
It's not impossible but the odds are already low even before you consider that the attacker only has a few tries and a time window to accomplish it in. Most people are not interesting enough to launch this type of attack against (think about what it's like trying to make money with that unlocked phone without leading the police to your door) and in a targeted attack looking for something like political dirt they're going to get that password by watching the user type it because not using more advanced systems means they're forced to do so frequently.
> That's bad enough if it grants "only" access to the phone itself, but now it would also grant the attacker access to each and every online account.
Kind of like what happens if they get full unrestricted access your phone without this and recover all of the saved passwords?
Remember that this is all optional geared at the vast majority of normal users. If you really think that the risk of someone recovering a fingerprint / facial scan is too high, you're free to continue using hardware WebAuthn tokens like you are hopefully doing right now. What this is solving is the friction around creating secure passwords and not losing them, and getting away from the idea that an email address is the real key to everything.
If you want more details about how it works, I would definitely listen to Adam Langley's interview here: https://www.buzzsprout.com/1822302/11122508-passkeys-feat-ad...
Re: Bringing passkeys to Android and Chrome
#247Earlier quoted context omitted.
> 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.
> 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.
Re: Bringing passkeys to Android and Chrome
#248Earlier quoted context omitted.
Man, every one of these comments has completely misunderstood the point. WebAuthn is an open standard. The provider is only there to sync your key. If you want, you can keep it yourself. Why is everyone yelling about the sky falling down when this is the best thing to happen to authentication since ever?
If it syncs your keys, it has full access. All I'm saying is that authentication is literally the keys to the castle, and inviting third party control of authentication has some scary implications in terms of privacy, monopoly control, and security. We should at least be discussing this, but I don't really see that much discussion. People are just blindly adopting this stuff because it's convenient and not even think…
It does, but it doesn't have to. You can use any provider you want, or self-host.
Re: Bringing passkeys to Android and Chrome
#249Earlier quoted context omitted.
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.
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.
Re: Bringing passkeys to Android and Chrome
#250I'm noticing very little discussion about the user aspect, and I say that with non-savvy users in mind. I run a mid-sized web app/community where I've been supporting such users for a long time. Right now, I offer a classic login, and a few social providers. You'd think this is straightforward to support, but about 70% of support requests consists of the endless ways in which users can mess this up. "Can't get in" Tr…
The flip side is that it’s incredibly easy to use, faster, and means you don’t have to worry about forgotten passwords or phishing. It’s like an order of magnitude faster than less secure MFA options, too.
Passkey? What's that? New word thus meaning unclear.
Doesn't seem to ask for an actual pass-anything, so more confusion.
No email identifier or thing to remember. How can I know log on at my other device?
With a QR code? What on earth is that?