Hacker News Reader

Comment by TacticalCoder | Hacker News Reader

I don't think it's misinformation. You may decide, on your own website, for your own users, to accept passkeys from everybody but others won't.

Sadly enough it's a near guarantee that the less secure implementations of passkeys (the software ones, allowing cloning and backups in the cloud) are likely to be the most accepted.

While actually secure implementation with the secret hidden deep down behind an HSM and never leaving it, made by smaller companies who do care about security, are likely to be rejected on the ground that it's too much of an "obscure" vendor.

I already posted about it today but if you think about it it's literally insane that cloning was meant to be detectable (and detection was enforced and upon detecting a cloned key, one of the two keys would stop working) and that this feature has now been removed with the sole justification being: "Because software backups to the cloud".

It is not good.

View on HN

I don't understand how what you say relates to what was said. You don't need to trust Google/Microsoft for your Passkeys, you can use a Yubikey, or whatever else you want.

If Google wants to only accepts its own Passkeys to log in to your Google account, that's as much its choice as any other site has for its authentication.

> that's as much its choice as any other site has for its authentication.

A site having the technical ability to determine not just its authentication mechanism but how that authentication mechanism is stored is not its choice and should not be its choice and is not its business.

And its a clear degradation in user freedom over passwords, a system where it's impossible for Google to dictate that you use only a specific password manager to store and sync that password. It shouldn't be possible for Google to know how I'm storing a passkey.

It's not their right to decide anything about that. They've never had that right. We're not taking a freedom away from Google, we're saying that Google should not have the ability to take away a freedom that we've always had, because they're our devices and it's our login information; it doesn't belong to Google.

I suppose the answer is to use Apple, then? It sounds like you have something against attestation, which is a reasonable point, and Apple doesn't support attestation in their implementation of passkeys. Given the size of their customer base, that pretty much guarantees that nobody is going to be denying passkeys based on lack of attestation.

Yeah, I wrote this comment before I knew that Apple was dropping attestation. Them dropping attestation kind of renders the entire conversation moot, practically no one is going to require it if it means cutting off the entire Apple userbase. It's good news.

It's honestly kind of the best possible situation short of attestation being outright removed from the spec. My bank doesn't understand "I should be able to use real 2FA instead of a text message", but they will understand "I should be able to log in from a Mac."

What would happen if Apple just started using attestation at a later date? It is still in the spec after all. I could see some services being willing to drop Apple for competitive reasons. ChatGPT only works on Edge browser at the moment IIRC.

:shrug: that would be a very bad problem if it happened.

Removing it from the spec would be better for precisely this reason, but making it harder to use is the next best answer. Bing AI's browser restrictions for example are a pretty big restriction on the service -- that comes with penalties that will discourage many sites from going down that route.

If Google also drops attestation for synced keys then it would become even harder to use attestation, and harder for Apple to go back on its decision. But yes, you're right, it would be better to have stronger guarantees about the future.

> A site having the technical ability to determine not just its authentication mechanism but how that authentication mechanism is stored is not its choice and should not be its choice and is not its business.

If that site is legally held liable for fraud happening due to credential compromise, as (hopefully!) would be the case for e.g. consumer bank accounts, I'd say there is at least some legitimate interest.

> If that site is legally held liable for fraud happening due to credential compromise, as (hopefully!) would be the case for e.g. consumer bank accounts, I'd say there is at least some legitimate interest.

I kind of disagree honestly. I think consumer bank accounts are some of the least secure accounts I have online. My consumer bank account has removed 2FA options over time. They've literally gone backwards on security.

I don't think there's much evidence that holding banks liable for fraud means that they're going to responsibly make their services more secure. Consumer banks in the US at least are wildly behind the times on account security, and I really don't trust them to make choices about what device I use.

What I do think banks do is invest a lot of effort into looking secure, and I think that stuff like attestation would (if supported) provide an easy mechanism for them to look secure at the same time that they allowed anyone to get into my account with just a social security number and my mother's maiden name. So I feel like, don't even give them the option. There's so much they can do to improve security before we ever start talking about requiring users to use specific hardware devices. Let's have them catch up on basic industry practices before we have that conversation.

This is certainly true in the US in my experience, but not everywhere globally.

EU regulations require 2FA both for logins on unknown devices and for every transaction initiation (whether on a known/trusted or new session), for example. Often, this happens in the form of dedicated "authenticator apps" that currently take quite frustrating/ineffective security measures like trying to detect whether the device is rooted.

Attestation could at the same time make this actually secure and give users more freedom to e.g. use whatever OS/mod they want to (since the actual root of trust would be an external authenticator or potentially their phone's TEE/Secure Element, not the OS).

I guess if this was regulated to be optional or regulated in such a way that it could only be used for keeping keys on-device and couldn't be used for locking out other devices from making accounts, then I'd be OK with it.

But we don't have those regulations in the US, and banks here shouldn't have access to this. We are so behind on security, it just doesn't make sense to give them yet another tool to lock down devices while they're ignoring everything else they could be doing. I would at least advocate for some kind of pact from FIDO Alliance members that attestation will only be implemented for devices sold in countries that have that kind of regulation.

Or, maybe there's a way to do attestation where it's entirely user opt-in and isn't something that the service provider can dictate? Or maybe there's a way to do it where it can't be used to verify the OS/manufacturer during signup, and can only be used to verify that it's the same device where the credentials were created? I think I'd be OK with that existing.

Are passkeys somehow signed by Google/Apple? I thought passkeys are like ssh keys.

They are, except they have a vendor ID that allows you to tell which vendor made the device you're talking to. You can get Passkeys by any number of vendors, but any authenticating website can decide to only allow a few vendors to log in with it.

> any authenticating website can decide to only allow a few vendors to log in with it.

That's an excellent way of telling your customers you want them to go somewhere else. What's the upside?

I'm not sure, it sounds silly to me. I guess you can mandate "secure" brands?

Synchronized passkeys by both Apple and Google don't use that mechanism (attestation).

There's also the AAGUID, but without attestation, every implementation is free to provide Apple's or Google's, should websites ever start requiring that.

Reply on news.ycombinator.com