Hacker News Reader

Comment by tialaramex | Hacker News Reader

Do you have some examples where people actually require attestation in 3rd party facing systems? Or is this purely "But in theory..." and you've dismissed all the very real problems with the alternatives because you're scared of a theoretical problem ?

I always reject attestation requests and I don't recall ever having been refused, so if this was a real problem it seems like I ought to have noticed by now.

View on HN

Microsoft Entra ID goes out of its way to enforce attestation for FIDO 2 keys.

The protocol normally allows you to omit the attestation, but they worked around an extra call after a successful registration flow that sends you to an error page if your FIDO2 passkey isn't from one of these large approved vendors: https://learn.microsoft.com/en-us/entra/identity/authenticat...

I found out by trying to prototype my own FIDO2 passkey, and losing my mind trying to understand why successful flow that worked fine on other websites failed with Microsoft. It turns out, you are not allowed to do that.

To defend Redmond here, Entra is an enterprise system. If the company you work for or are interfacing with wants to enforce attestation, that's their business.

B2C I would expect more latitude on requiring attestation.

A problem is that once a thing like that exists, it ends up on security audit checklists and then people do it without knowing whether they have any reason to.

I would counter argue being the person pushing passkeys in an enterprise: noone in the business knows what attestation is, but we're going to do it because the interface recommends it.

I'm not sure it's the standards committee's fault that your employer hires people that don't know how to do their job.

I think it's reasonable to have attestation for the corporate use case. If they're buying security devices from a certain vendor, it's reasonable for their server to check that the person pretending to be you at the other end is using one of those devices. It's an extra bit of confidence that you're actually you.

It's the standards committees job to design standards that are difficult to misuse.

The most common fault of committees is that they overengineer processes and specs wander out of scope. The result is that users (dev & consumers) either neglect the bad parts or the spec doesn't get used at all.

Exactly. For personal authentication, you are at least personally incentivized to do the right things. For corporate auth, people will do whatever it takes to skip any kind of login.

I once knew a guy who refused to let his office computer go to sleep just to avoid having to enter his password to unlock his computer. He was a really senior guy too, so IT bent to allow him do this. What finally made him lock his computer was a colleague sending an email to all staff from his open outlook saying “Hi everyone, it’s my birthday today and I’m disappointed because hardly anyone has come by to wish me happy birthday”. The sheer mortification made him change his ways.

A culture of harmlessly pranking computers left unlocked goes a long way. ThoughtWorks veterans know what I mean.

lol this is funny, why he didn't want to sign in more often tho???

He was completely non technical and I guess he figured that IT should be able to work the security system around him.

The most common human trait ever.... laziness

Don’t put in place systems which encourage lock-in, even at the B2B level.

Aren't those usually used inside an enterprise vs B2B between enterprises?

Ah, and even if you can turn it off as the administrator, you still need to include the attestation, it's just not checked. Gotta love Microsoft...

Yeah Microsoft is so annoying. It's also kicking me out every day now (with this passive aggressive "hang on while we're signing you out" message). On M365 business with Firefox on Linux with adblocker. I hate using their stuff so much.

Same has been happening for for a few months. I get thrown out of all o365 services multiple times each day.

Yes me too since a couple months :( So annoying. It doesn't of course happen on Windows.

It started with OneNote web a couple years ago. Every day that gave a popup "Your session needs to be refreshed) and it would reload all over again. Microsoft don't bother to make a OneNote desktop app for my platform and the web version is really terrible anyway (you can only search in one tab, not a whole notebook). So I moved to self-hosted Obsidian which I'm really happy with. Now I can basically see myself typing in a note from another client.

But replacing Microsoft for email is another topic.

I don't work in August, so I can't (well, won't) check, but my boss had the infrastructure team turn on FIDO2 for the mandatory 2FA on our administrative accounts and I do not remember having any problems with this.

I do remember explicitly telling them (because of course having agreed to do this they have no idea how and need our instructions) not to enable attestation because it's a bad idea, but you seem to be saying that it'll somehow be demanded (and then ignored) anyway and that was not my experience.

So, I guess what I'm saying here is: Are you really sure it's demanded and then ignored if you turn it off from the administrative controls? Because that was not my impression.

It's been a little while, but I believe at the time you'd get a CTAP/CBOR MakeCredentialRequest, the browser would ask you to confirm that you allow MS to see the make and model of your security key, and it would send the response to a Microsoft VerifySecurityInfo API.

If you refused to provide make and model, IIRC you would fail the check whether enforcement was enabled or not. Then if enforcement was enabled and your AAGUID didn't match the list, you would see a different error code.

Either way, you're sending over an attestation. They understandably forbid attestation format "none" or self-signed attestations. It's possible that this has changed, but the doc page still seems to say they won't accept a device without a packed attestation, it's only that the AAGUID check can currently be skipped.

Passkeys are in their infancy. You don't go about rolling out such patterns when most users haven't even switched yet and big players like Apple are still resisting attestations (last time I checked). The problem is that the feature is there and can be (ab)-used in this way, so it should be rejected on principle, irrespective of whether it's a problem right now.

I understand the value of attestations in a corporate environment when you want to lock down your employees' devices. But that could simply have been handled through a separate standard for that use case.

At the very least the spec should be painstakingly insistent on not requiring attestation unless implementors have really thought and understood the reasons why they need the security properties provided by attestation in their particular use case. And that it has to be something more meaningful than “be more secure this way” as security is not a rating (even though security ratings exist) but a set of properties, and not every possible security guarantee is universally desirable (please correct me if I’m wrong here, of course), and at least some are not without downsides. Maybe even strongly recommend library authors to pass the message on.

I agree, but unfortunately the spec authors are already going out and dangling possible bans in front of projects who implement Passkeys in more user-friendly ways:

https://github.com/keepassxreboot/keepassxc/issues/10407

> To be very honest here, you risk having KeePassXC blocked by relying parties

But having a choice about how you store your credentials shouldn't depend on the good faith of service providers or the spec authors who are doing their bidding anyway. It's a bit similar to sideloading apps, and it should probably be treated similarly (ie, make it a right for users).

There's a tension here between "user freedom" and a service wanting to make sure that credentials that it trusts to grant access to stuff aren't just being yolo'd around into textfiles on people's dropboxes.

People forget that one of the purposes of authentication is to protect both the end user and the service operator.

Sure, but as long as the fallback for account recovery is sending a reset email or sms (both of which are similar or worse than yoloing textfiles on dropboxes), that's a very tough argument to make in good faith.

I agree that account recovery isn't the best. But just because that sucks doesn't mean there's zero value in improving credentials.

What people do on their own computer is none of the service's business.

It is if it puts the service at risk.

This attitude has got to stop. Is it not enough that there's no customer service and it's almost impossible to sue these companies thanks to arbitration clauses? Now they need to have control over our computing to keep themselves safe? And how many recorded incidents of losing an account because someone had their "password in a text file" are even out there? The most common scenarios one hears about are either phishing or social engineering.

Do you think someone running a service that's under constant denial-of-service attacks would be sympathetic to the argument that "What people do on their own computer is none of the service's business".

Pretty much every service out there has "don't share credentials" in their ToU. You don't have to like it, but you also don't have to accept the ToU.

Note the scare quotes around user freedom. Perhaps user freedom is a notorious fake issue, a bizarre misconception, or an exotic concept that nobody understands.

I don't know what "scare quotes" are. They're just regular quotation marks, because I'm quoting.

Sure, I stand corrected, you "don't know" what I'm talking about.

Literally no idea.

My point was that freedom is not an absolute, it's balanced against other freedoms. It's hard to tell whether you agree with that or not.

What does Microsoft stand to lose if someone steals my passkey for Outlook from a text file I yolo'd into a Dropbox?

The exact point of passkeys is to remove all rights from users )

Ensuring it's not possible for remote attackers to easily steal users passkeys is not "removing all rights" for someone. It is setting a security bar you have to pass. One user's poor security can have negative effects on not just them but the platform itself.

You don't need attestation to allow users to secure their passwords.

You don't, but with one services have a better guarantee that they are.

You’re falling for the exact “better security” fallacy I was trying to warn about. Security is not a rating, “better security/guarantee” is not a really meaningful phrase on its own, even though it’s very tempting to take mental shortcuts and think in such terms.

Attestation provides a guarantee that the credential is stored in a system controlled by a specific vendor. It’s not “more” or “less” secure, it’s just what it literally says. It provides guarantees of uniformity, not safe storage of credentials. An implementation from a different vendor is not necessarily flawed! And properties/guarantees don’t live on some universal (or majority-applicable) “good-to-bad” scale, no such thing exists.

This could make sense in a corporate setting, where corporate may have a meaningful reason to want predictability and uniformity. It doesn’t make sense in a free-for-all open world scenario where visitors are diverse.

I guess it’s the same nearsighted attitude that makes companies think they want to stifle competition, even though history has plenty of examples how it leads to net negative effects in the long run despite all the short term benefits. It’s as if ‘00s browser wars haven’t taught people anything (IE won back then - and where is it now?)

>You’re falling for the exact “better security” fallacy

How is it a fallacy? The rate of account compromises is a real metric that is affected by how good security there is for accounts.

I've tried to explain it in my comment above.

Yes, the rate of account compromises is a metric we can define. But attestation doesn't directly or invariably improve this metric. It may do so in some specific scenarios, but it's not universally true (unless proven otherwise, which I highly doubt). In other words, it's not an immediate consequence.

It could help to try to imagine a scenario where limited choice can actually degrade this metric. For example, bugs happen - remember that Infineon vulnerability affecting Yubikeys, or Debian predictable RNG issue, or many more implementation flaws, or various master key leaks. The less diverse the landscape is, the worse the ripples are. And that's just what I can think of right away. (Once again, attestation does not guarantee that implementation is secure, only that it was signed by keys that are supposed to be only in possession of a specific vendor.)

Also, this is not the only metric that may possibly matter. If we think of it, we probably don't want to tunnel vision ourselves into oversimplifying the system, heading into the infamous "lies, damned lies, and statistics" territory. It is dangerous to do so when the true scope is huge - and we're talking about Internet-wide standard so it's mindbogglingly so. All the side effects cannot be neglected, not even in a name of some arbitrarily-selected "greater good".

All this said, please be aware that I'm not saying that lack of attestation is not without possible negative effects. Not at all, I can imagine things working either way in different scenarios. All I'm saying that it's not simple or straightforward, and that careful consideration must be taken. As with everything in our lives, I guess.

It's just passwords from HIBP, you're not going to solve any other attack.

Services, by definition, serve. Why should we, the users, care about their guarantees?

Because users want the services they use to be good. They don't want to be sent phishing links from their friend's account that was hijacked by attackers.

I had a meeting with a public servant this morning. He is part of an organization that promotes multi-factor authentication and publicly endorses the view that users are stupid.

The meeting was about him unable to test the APK of the new version of their mobile app. He felt embarrassed, his mobile phone is enrolled in the MDM scheme that disallows side-loading of apps.

What I am trying to say is that assuming users are stupid carries a non-negligible risk that you will be that stupid user one day.

The solution here sounds like having a separate development device that is used to sideload test versions of the app. The idea is that devices may require different levels of security depending on how much can be accessed from that device.

Reducing passkeys to the security level of passwords is not just "making something user friendly". It's undoing all of the hardware everyone else in the ecosystem is putting into to making a more secure way for authentication to be done.

Passkeys have several advantages over passwords but not all of them rely on UX controls. They are, after all, public-private keypairs and the private part is never shared during authentication. The wider web never adopted PAKEs so passwords are still sent verbatim over the (TLS-protected) wire.

With password managers passwords are not reused which avoids this problem already.

Not reusing passwords across sites greatly limits the blast radius but verbatim password exchange still carries its own risks. The widespread adoption of TLS addressed most of the issues, as I alluded to already, but there are still insider threats, MITM phishers, and infrastructure compromises from time to time.

How exactly is this "reducing the security level to those of passwords"? For example: you can't use a passkey on attacker's web site even if you have a plaintext copy of the private key.

I'm not following. The issue is about it being used for the site the private key is for. The attacker's site is irrelevant here.

Apple hasn't been particularly resistant to offering device attestation. The DeviceCheck / App Attest system has been offered since iOS 11 released in 2017. https://developer.apple.com/documentation/devicecheck

I assume they mean attention in the webauthn/passkey specs specifically

The Fido2 folks really really want things to be so secure and centralized, with so little user freedom, and they want to use attestation to do it.

Here's a Fido2 member (Okta) employee saying "If keepass allows users to back up passkeys to paper, I think we'll have to allow providers to block keepass via attestation." https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

All because passkeys backup is deemed "too unsafe and users should never be allowed that feature, so if you implement it we'll kick you out of the treehouse."

The authoritarian nature of passkeys is already on full display. I hope they never get adopted and die.

Those quotes aren't in your source.

Hi, since you mentioned me, that's not what was said and putting it in quotes as if I did is really inappropriate.

I'll post the same response I replied to other on a different thread:

Wild that you (and a few others) continue to make these accusations about me in these comments (and in other venues).

1) I've been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice

2) What makes you think I have any say or control over the hundreds of millions of websites and services in the world?

3) There is no known synced passkey credential manager that attests passkeys.

tl;dr attestation does not exist in the consumer synced passkey ecosystem. Period.

They paraphrased what you said in the thread, but I don't think it's much of a misrepresentation.

You may have "been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice", but as soon as one such credential manager allows export that becomes "something that I have previously rallied against but rethinking as of late because of these situations".

There may not currently be attestation in the consumer synced passkey ecosystem, but in the issue thread you say "you risk having KeePassXC blocked by relying parties".

The fact that that possibility exists, and that the feature of allowing passkeys to be exported is enough to bring it up, is a huge problem. Especially if it's coming from "one of the most vocal proponents of synced passkeys never being attested", because that says a lot about whoever else is involved in protocol development.

You should really re-read the entire discussion. It wasn't about passkeys being able to be exported. It was specifically about clear text export.

> The fact that that possibility exists,

The possibility does not exist in the consumer synced passkey ecosystem. The post is from a year and a half ago.

A year and a half ago doesn't really matter; that this was ever even a concern from the industry, something that the industry could make happen at all, or even just was thinking about doing at some point in the past, poisons the entire effort. In a world where password+totp already exists and requires almost no hoops, no dependencies and is incredibly secure vs basic password flows, it's no wonder that folks remember discussions around curtailing user freedom around a new authentication pattern which already was less convenient, offers less user control, and further centralizes infrastructure in the hands of a few major brokers of technological power.

Until we have full E2E passkey implementations that are completely untethered from the major players, where you can do passkey auth with 3 raspberry pi's networked together and no broader internet connection, the security minded folks who have to adopt this stuff are going to remember when someone in the industry publicly said "if you don't use a YubiKey/iPhone/Android and connect to the internet, ~someone~ might ban you from using your authenticator of choice."

> Until we have full E2E passkey implementations that are completely untethered from the major players, where you can do passkey auth with 3 raspberry pi's networked together and no broader internet connection

This is already possible today. And since it's a completely open ecosystem, you can even build your own credential manager if you choose!

I don't believe it is a misrepresentation, you are bullying a project for letting users backup their own passkeys.

>which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).

This is exactly why we need truly open standards, so people who believe they are acting for the greater good can't close their grubby hands over the ecosystem.

Systems are usually more open while they are trying to onboard users than they will be once the moat has been established.

We have already been through this with many services suddenly demanding that you give them your phone number "for security".

They're not going to start requiring them until they've phased out non-passkey login. But at that point it will be too late.

I don't know why people don't see this coming: very obviously once Passkeys are everywhere, it'll become "we're requiring attestation from approved device bootloaders/enclaves" and that'll be your vendor lock in where it'll be just difficult enough that unless you stick with the same providers phone, you might lose all your passkeys.

> very obviously once Passkeys are everywhere it'll become "we're requiring attestation from approved device bootloaders/enclaves"

This is far from very obvious, especially given that Apple have gone out of their way to not provide attestation data for keychain passkeys. Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen.

If there's no intention of doing this, it should be removed from the protocol. "I promise we'll never use this feature, so long as you implement it" isn't very convincing.

Not all people who want to replace passwords are running services available to the general public.

There are a bunch of service provider contexts where credential storage attestation is a really useful (and sometimes legally required!) feature.

Great, they can use standards that aren't targeted at running services for the general public. It seems like the requirements already diverged.

Drop attestation from passkeys, and I become a promoter. Keep it, and I suggest people stay away.

If it's not something anyone intends to use on public services, this should be uncontroversial. Dropping attestation simplifies implementation, and makes adoption easier as a result.

What makes you think that the Webauthn standards are "targeted at running services for the general public"?

> It seems like the requirements already diverged.

No, the requirements are _contextual_. This isn't a new idea.

The fact that sites targeted at the general public are prompting me to use them. Should websites avoid using passkeys and webauthn? Would you like to tell them that they're doing it wrong?

I missed a word out from my question. Let me try again.

What makes you think that the Webauthn standards are _only_ "targeted at running services for the general public"?

Yeah, so if you want me to trust them, the harmful parts need to get removed from specs used in public contexts.

I would love to use public key cryptography to authenticate with websites, but enabling remote attestation is unacceptable. And pinky swears that attestation won't be used aren't good enough. I've seen enough promises broken. It needs to be systematic, by spec.

Passwords suck. It's depressing that otherwise good alternatives carry poisonous baggage.

If you make something possible, it will be used.

> If you make something possible, it will be used.

Sure, but that's not without tradeoffs. I come back to:

> Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen.

And I come back to: if it would never work, why not drop support? "We pinky promise" is just not good enough.

> if it would never work, why not drop support?

Because passkeys are designed to replace passwords across multiple different service contexts, that have different requirements. Just because there's no reason to use it for one use case doesn't mean it's not actually useful in a different one. See things like FIPS140 (which everyone ignores unless they're legally required not to).

Can you sketch out for me the benefit of a public-facing service deciding to require passkey attestation? What's the thought process? Why would they decide to wake up and say "I know, I'm going to require that all of my users authenticate just with a Yubikeys and nothing else"?

> Can you sketch out for me the benefit of a public-facing service deciding to require passkey attestation? What's the thought process?

A misguided administrator is very likely to think "They can't use a malicious device to access our service".

What's the benefit for a private service?

Is there a difference? It's a field in the response payload that nobody is filling out except the corps that need it. Would it make you feel better if they moved it to an appendix and called it an optional extension?

> Would it make you feel better if they moved it to an appendix and called it an optional extension?

That kind of thing can make a huge difference once this standard starts becoming e.g. required for government procurement.

As long as it required an extension and extra application.

I should need to install an enterprise authenticator app, which speaks webpki-enterprise, if you want to enable that shit.

Great. At that point there will be a real market niche for people who (can, want, might) think a bit different.

> Do you have some examples where people actually require attestation in 3rd party facing systems?

Austria's governmental ID is linked to 5 approved tokens only.

> Do you have some examples where people actually require attestation in 3rd party facing systems?

That's not the right question. The right question is "what companies would be using passkey's if there was attestation on their security". To answer that question, you might look at the answer for a similar one on X509: "would we be doing banking over http if X509 didn't have attestation?".

Seems very argumentative for somebody who's just saying there's no issue.

Reply on news.ycombinator.com