YHK - yet another hacker news clone

So: currently, the cauldron is cold, therefore ignore the fire below it and hop right in.

"Password manager you trust..."

Not so easy.

I've worked at places where we use a password manager to manage lots of passwords for random services that we subscribe to. The engineering manager always says "you can put your own passwords in for free" and I say "no thanks, they're going to get hacked" and then six months later... they get hacked.

I use the password manager on my iPhone because it seems pretty secure and it is so miserable to type passwords in on a phone but my other solution for passwords has used cryptographic generation with the database playing only a secondary role and it is fine for passwords but does nothing for passkeys.

Thankfully someone with some sense. I saw that post title and didn't even bother to read it. It sounded like someone having argued with me a decade ago that IPv6 is a mechanism for the government to track you because you have no more privacy anymore because you don't have NAT...

Biometrics is my main concern around this, and in that the government can compel you to provide them for device unlock, unlike a pin or password.

Until we change our laws in the US on this front, I will continue to use passwords and hardware keys separate from my phone box.

100% correct takedown of the "Trap" article

Do passkeys have issues? Sure. Most of them are UX and are being worked on. As a user, I 1000% immediately register a passkey when a site or app offers it as at least on iOS and macOS, it is a superior user experience IMO and more secure. I never worry if I'm getting prompted for a Passkey, am I on the right site?

Also the remote connect functionality of modern browsers and mobile operating systems makes it trival if I need or want to sign into a personal account on my work PC where my personal passwords are not sync'd. Need to get into my personal GMail in an incognito window at work? No problem at all.

Anti-Passkey folks are just people who want to be against something to be against it

This author is astoundingly trusting.

> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that?

Any of them? All of them?

"Starting next year, only Google Authenticator and Google Chome passkeys will be valid for gmail logins. Help us keep your account safe by limiting access so ONLY YOU can read your emails"

"Good news! Your Instagram account is getting safer from hackers and spammers. As of next month, you'll use your Meta Metaverse token for all logins to Instagram, Facebook, Theads and WhatsApp"

Google already forced OAuth2 on Thunderbird [0] and the rest of the email-client universe.

[0] https://support.mozilla.org/en-US/kb/automatic-conversion-go...

I don't know enough to argue about whether passkeys are a trap or not, but I do know as a user that they appear to be a confusing mess.

When a website prompts me to set up a passkey, depending on the device I happen to be using at the time it could end up going to Google password manager, Samsung password manager, iCloud Keychain, or Windows somethingorother.

What happens when I go to the same site on a different platform? What if I can't use cross-device authentication because I'm on a locked-down work machine or one that simply doesn't have bluetooth? What if I want to consolidate them all in one platform just for the sake of being organised? What if I lose or simply don't have the device with a certain passkey near me?

I don't have the time or patience to work out any of that, which might absolutely be a 'me' problem, but TOTPs are pretty sodding frictionless in comparison. Scan QR in my chosen manager; type number into website; done. Why are passkeys better?

  [Passkeys] should never be exported in clear text
  Overview
  Passkeys should never be allowed to be exported in clear text.
  [...]

I hate passkeys because they're always tied to a specific account or a device like a phone. I hate being dependent on phones/devices. That being said I know they solve a lot of problems so....

I still prefer a good password written down in a paper book, with multiple methods of 2FA. But I know there are attack vectors for that.

This blog post is the perfect example of someone rationalizing away the bigger picture.

It's true that passkeys do not require hardware and OS attestation today, so all of the specific examples you cite are true. But the point remains that that passkeys can be EASILY extended to require hardware and OS attestation, and this will happen.

Banks have already done this. Before using an app was optional. Play protect was optional. It's like my uncle ted used to say, techonolgy is not optional.

> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.

Am I missing something? "Attestation tells websites what the authenticator is but it doesn't tell the website what the authenticator is".

The entire argument in this blogpost amounts to "nobody would ever turn on passkey attestation because it would require migration of people who already setup passkeys" which is a questionable argument- you could trivially imagine allowing unattested passkeys for existing users, but require it for new users. Most websites don't yet support passkeys to begin with, so this argument doesn't hold for the majority of websites.

The "biggest providers" bit at the end is odd too because the biggest providers are apple/google- who, as far as I know, do support attestation.

Let us consider the average user. The one who manages to lose their iPhone and has no idea what their iCloud account login is because they were aware of having to log into it once when they created the account at phone purchase 3 years previously.

That's where the trap is.

Saying "attestation can't hurt you, your password manager returns `none` today so it's not a concern" is avoiding the entire point of the original article which was that that can change at any time! I'm already seeing in a corporate context, IT departments forcing hardware attestation as required everywhere. Justifiable, but also clear evidence that it's no longer in your control as the person authenticating. That's the point, passkeys are marginally more secure for you, while handing huge amounts of control to centralized platforms.

"...if attestation is the thing you're worried about, the post's own recommendation pushes you towards attestation rather than away from it!"

It is plainly obvious that the worry isn't attestation per se, it's the restrictions that attestation may in the future require when they turn the dial on restrictiveness up, that was extremely clear to me from reading the first article. If you can get attestation without those restrictions, "sure, why not", and a Yubikey seems like a way to do that which could avoid those restrictions. Most of this article makes sense, but this particular line makes me wonder how the author got it so far off the mark.

They also did nothing to quell my fears that they will in the future use passkeys to prevent people from using software they can modify themselves by saying "...the guidance for consumer sites has been to not even request attestation for years now." as if everyone always followed the guidance, and as if there aren't tens of thousands of managers that think their case is special and they really do need the extra control because they're a bank or handle copyrighted content or have PII or PCI and feel extra risk-averse today.

I don't know if they failed to do so because they can't (and this is a valid fear of the original author) or if they just are bad at reading the room at what the concern is and vastly overestimate how much people trust companies to always have their best interests at heart.

What I am getting from this, though, is "If you authenticate with a yubikey then that's attested, so they can't use attestation through passkeys to make sure your OS and browser aren't modified", and I'm not sure if that's the correct take away or even a correct statement.

I don't find this post convincing.

> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.

This isn't a rebuttal to the claim that they're a hidden dial. It's just saying that it's too early to crank the dial.

>Attestation Isn't What You Think It Is

>The post describes attestation as proving "that an approved passkey manager, operating system, and firmware are in use" which is simply not true.

>When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.

This point is bypassed by websites only supporting specific authenticators and then those specific authenticators only supporting specific devices/OSs/browsers/etc via other attestation frameworks.

Passkeys are a trap in that they're a fairly confusing implementation that ends up tying you to a specific device or device ecosystem.

They're better than passwords but just as annoying when I have to sign into Outlook every 5 days

I absolutely love them now that I have a Mac. They're shared between my phone and my Mac automatically so I can just sign in to anything with my fingerprint.

Passwords just suck. If we're all going to use password managers anyway, what is the point? Might as well use a randomly generated passkey.

Anything that's tied to hardware is one accident away from locking you out forever unless you set of "2 of 3" or some other "let's make life even worse when it comes to authentication" solution.

Passkeys are such a flaming disaster from a UX standpoint. I can't recommend anyone use them.

I think it's a bad sign when someone immediately resorts to strawmen and argument from incredulity in their counter-argument:

>If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that?

The original didn't argue that, nor has absolutely anyone else concerned, nor has that been what has happened in historical examples people were concerned about. Because yeah of course that's ridiculous, it's "boiling a frog" by throwing it in already boiling water, that's not how it works. If anyone has freedom-reducing longer term plans for use of passkey attestation, the emphasis is on "longer term", being malicious doesn't mean being stupid. Step 1 is obviously getting people into the passkey ecosystem and out of passwords at all, which could well take years. And importantly as much as possible into closed passkey ecosystems. This is indeed one of the initial danger signs, because the author:

>iCloud Keychain, Google Password Manager, 1Password, Bitwarden

Is mixing together things that aren't like the other. Quick author, what's the EXPORT story for each of these ecosystems? Of those, Bitwarden can export a passkey into a plain JSON if you want. Do the others support that too, or at best only "app to app" encrypted transfer, creating a closed ecosystem? Already, can I get passkeys from iCloud/Google/1Pass into KeePass? Or is this restricted """for my protection :^)"""?

Author doesn't even touch on the lock-in that's already beginning. And right now everyone can technically claim "oh no of course you're not locked in! You just have to use an official option, or you can merely visit hundreds of sites individually and register new passkeys in all of them". Is it hard to see how players like Bitwarden would be pressured on continuing to offer plain export?

Then when most of the population is using passkeys everywhere in a closed ecosystem, now what is the response if friction slowly starts getting added. OK, you can still use what you like, but only export to other approved players. OK, you can still use unattested, but it's off by default now, "advanced users" can go enable it with this checkbox in the settings. OK, manual is still an option, but now it's buried deep and behind dark patterns and requires a text command. Hi everyone, we have statistics to show that only 0.85% of our users still use unattested keys. The support burden and security risk is now too high."

Like, we've seen this movie before.

I still don't use passkeys because I don't know what advantage it has over my existing method of generating random passwords in my passport manager and using that. My password manager generally autofills it anyway.

I know where my password manager syncs, it's on all my devices. Passkey prompts always seem confusing, I don't know if it's going to save to my browser, or my OS, or if those are gonna sync on what devices. It's just more confusing.

What would I gain from using a passkey?

For me, randomly generated passwords(via proton pass) combined with remembering to check the URL stops phishing and is easier to share.

The author is really missing the forest for the trees here

> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.

So if I was Netflix or a bank or w/ever I'd only allow new registrations from "trusted" authenticators, which would incidentally only run on iOS and play-protected Android.

Let’s assume passkeys are the greatest thing since sliced bread.

Passkeys face the same problem as the USB-C rollout. Lots of different incompatible implementations and standards rolled under one name that are almost impossible to distinguish between. Very little education on how to use it and be prepared for it.

The difference is that the consequences of getting passkeys wrong for the user is significantly greater than getting the wrong cable, and while the latter can easily be fixed, the former may be irreversible.

I truly believe pass keys are a way for yo to eventually lose access, or give someone or something else, access to your logins.

I'm a happy user of 1Password myself, but warning that they only allow export of passkeys through a specific protocol, and it has to be done on the mobile app. [0]

[0]: https://support.1password.com/export/?ios

I mean the desire to trap seems to be among the big corporations already.

I keep seeing major players promoting their own apps over standard TOTP, which I guess could be seen as a sort of proprietary passkey. Shopify, Google, Microsoft, and more, they all want you to download their app for MFA, instead of using a very open format.

As someone who works in IT, I just can't even imagine myself doing this. I have probably around 60 codes in my Aegis, how would it look if I had just a quarter of those in apps instead?

But the main issue I have with passkeys is the simple issue of backups. I can backup my Aegis keys, I can't backup an app, or a hw passkey. I have to get a second one, and keep signing for it or something, not sure of the details, I just know it would be a major hassle. And there is no way I'm trusting a little usb device to not break.

Right now I see no compelling reason to switch from regular OTP codes, change my mind.

Passkeys can be tied to a root of trust, like those owned by google, microsoft, apple.

Currently they aren't tied to that root of trust.

Most of those organizations have shown that they don't want people owning their own devices or being able to run their own software, and they use developer attestations, IE a revocable programming license to accomplish that.

Tools like android's safetynet makes it so that you can't run banking apps on a phone running your own software. One that bypasses developer attestations.

Passkeys are currently an open standard, but attestation is built in such a way as that it could be only usable on n approved operating system with programmer licenses.

Big websites like amazon, or websites you need to exist in society, could gradually start requiring the usage of attested passkeys.

---

There is a clear path from passkeys to the death of general purpose computing for 99% of people. Don't be a useful idiot, don't assume these corporations have your best interest in heart. See this for what it is, a path towards killing people's ability to run unlicensed software on their own devices.

At the end of the day, I just don't really want them. I already have passwords and I already have to put up with 2FA. Passkeys are just one more damn thing to understand in an ecosystem I already want to spend as little time in as possible.

The og article talks about future concerns even though things are fine today. This article claims things are fine today.

True, but doesn’t actually refute the original.

I have to say the messaging around passkeys is bad. So many providers show modals with big friendly lock logos superimposed on a smartphone to announce the change without offering any explanation about why the change is happening, why the change is happening now, or how the technology works.

I don't know when it started, I don't know who is to blame, but we've definitely arrived at a conceptualization of "the user" that is passive, uncurious, and incapable of being talked to like an adult.

Look, at best, Passkeys shift your logins from your head to OS-supplied keychain management. Whether they do attestation today or not, they big, industry-wide effort to move away from "what you know" (i.e. username/password) + "what you have" (2FA) towards "platform-authenticates-you-to-website automatically" has both security benefits and lock-in risks.

Maybe it was too strong to say the were a "trap", but it is also too strong to say there is no worries here.

I don't use passkeys but the thing that raised a red flag for me while reading the article that the OP is responding to is the "non-copyable" property. It's not possible to prohibit delegation[0], so the idea that a key can only be used on one specific device necessarily involves a form of DRM/wishful thinking.

[0] http://www.erights.org/elib/capability/delegations.html

> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up.

Me: The person who posted this post critical of The King on Facebook was totally not me!

Police: Here's "a WebAuthn attestation" that told Facebook "the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up" and it fits Evidence A.

No thanks.

Wouldn't web browsers themselves be the ultimate passkey managers like they already do with passwords? They'd need a way to export the passkeys to another passkey manager though.

I figured they weren't. People smarter than me made them.

I think they've been implemented well in some cases. I think they've been implemented poorly in others.

So it goes.

"Is not a trap" does not follow from "Is currently good".

A defining feature of traps is that they start out good.

There are a lot of good points in this article, but it fundamentally missed the point of the word trap. The most it said on that topic is:

  > If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.

Which is a statement about the near future. There is room for a conversation about the long term, but this article is not a part of that conversation.

I think the passkey standard included attestation for good reasons, but it is obviously also possibly a trap in the sense that I'm sure there were some people on the standards committee(s) envisioning a glorious world where they can flip this on for everyone and instantly all the bad stuff stops.

I have to admit I don't worry too much about the entire internet flicking attestation=true anytime though, because the resulting support nightmare would be ferociously expensive. I wouldn't be surprised that, on its own, it would be more expensive than the cases that the companies flipping the switch are trying to avoid. Which means it isn't going to happen.

The simple truth is metaphorical-Grandma can't handle the degree of responsibility put on the user that strict hardware attestation implies. Netflix et al are more likely to want metaphorical-Grandma's money more than an incremental improvement in their ability to be sure it's an attested login, and won't want metaphorical-Grandma to call Netflix every other week trying to figure out how to log in again. There is no way around the fact that strict attestation implies more user responsibility to make sure they don't lose their token, and at scale, they absolutely will. Work environments can get away with this because work environments have a scalable mechanism to re-verify identity to the extent the business cares about it personally, and reissue tokens. At scale the big companies do not have this for individuals. You can't use hardware attestation without this infrastructure for reverification, and any infrastructure for reverification a large corporation tries to create will have exploitable holes in it.

I don't like them, they offer no advantages to logins with random passwords. They would only be more secure if they were forced to be stored on hardware devices like Yubikeys, which almost never happens in practice. In reality it's true that they can be dangerous because they can be set up in a way that doesn't allow storing them in software and using them on multiple devices, and such device-bound passkeys will eventually lock you out or be reset in the same way as password+login (usually just by email).

The standard and implementations are also unnecessarily complex and obtuse. IMHO passkeys are not a good technology.

I introduced Passkeys in my company.

Every single IT person thought it would be an extreme mess, too complicated for regular users. In my company we work on the (gas) grid so lot's of blue collar types.

We went there, gave the pilot group a Yubikey and said: This is like the company pass you already have. Without the company pass you cannot enter any buildings. Without the Passkey you cannot enter a computer or app.

If you lose it report to the same people (service desk).

The response has been EXTREMELY POSITIVE. People fucking LOVE getting rid of passwords, password requirements and taking off their gloves to enter it every time.

We are now rolling it out to everyone and next year when we stop our silly "phishing game" contract we will actually save money while reducing a massive cyber security risk for our company: (voice) phishing.

"A passkey is bound to the domain it was created for, so your browser simply won't use your example.com passkey on examp1e.com." What happens if a service you use loses its domain? For example, if I run a marxist online forum, it could happen at any time that the US regime sanctions my site and seizes my domain. Would my comrades still be able to log in with their passkeys?

> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.

Practical experience from Austria where attestation is used to limit which hardware tokens can be used for the EU digital identity: it sucks. You're limited to a very limited number of keys: https://www.id-austria.gv.at/de/hilfe/hilfe-zu-ida/authentif...

Now: will more people do this? I don't know. But I fault the standard for enabling it in the first place.

I've set up a few passkeys to see what it's like and the experience is wildly different between sites.

State Farm is the only place I've actually liked it. I don't have to type ANYTHING in.

Open browser, open password manager, click the "sign in with existing passkey", browser and password manager talk, prompt me to confirm the passkey choice, and I'm in.

Most sites I've messed with insist on you entering a username first.

Last time I tried using Firefox on Linux with Keepass's passkey implementation it worked on the test page and a couple other sites but Facebook refused to add it, so I definitely believe that e.g. banks and various other important sites won't balk at restricting passkeys to Android, iOS/MacOS, and Windows. I am curious what other people's practical experience is with these kinds of sites.

If they are not a trap, then the standard should be amended to allow third party implementations to forge attestations.

Otherwise, it is a trap. The story of the last 25 years of the internet is user hostile ratcheting away of the open web. Passkeys are obviously another step in the process.

"AAGUIDs are unique identifiers assigned to FIDO authenticators (including passkeys and security keys) and are used to identify authenticator models for attestation and metadata purposes."

If there is any unique id that can track you, then it's a trap. No security system should be leaking unique ids that can be used to track users.

Do not handover your identity, or verification of it (as the current case is) to anyone else, irrespective of the benefits, including the security aspect.

---

The author has strong incentives for the success of passkeys.

1. Scott Helme is founder and CEO of Report URI, and Companies House records his ownership at over 25% and up to 50%. Report URI markets a "Passkeys Protection" offering, giving him a commercial interest in services for passkey adopters.

2. His WhyNoPasskeys.com campaign pushes websites to adopt passkeys, is sponsored by Report URI, and promotes its passkey protection services. The "Passkeys Are Not a Trap" article also carries a Report URI sponsor banner.

3. Troy Hunt, Helme’s Report URI business partner and investor, joined 1Password’s advisory board in 2020; Helme has also appeared in Hunt’s 1Password-sponsored content. That establishes an indirect vendor connection.

When a website forces a passkey into my password manager without even asking me (fucking Amazon), it is pretty unambiguously something that is not good for me.

QED, a trap.

I have seen an exception to this with Microsoft Entra. I was not able to store and use the passkey in my password manager of choice, I had to save it in Microsoft Authenticator. I haven't tried again lately since that was for a previous job, and I didn't look into the underlying reason it failed, whether it was attestation of some sort or something else about how they set it up.

I'm generally pro-passkeys, but also acknowledge they are a hot mess for the average non-techy consumer. And there does seem to be room for the screws to tighten, and we definitely need to resist that.

What I'd like to understand is why the majority of sites that allegedly supoprt passkeys do not let me store them on Yubikey hardware but instead are pushing into "cloud" passkeys. That's what is triggering my spidey sense about the whole scheme. If they are so great all around and vendor neutral why is everyone pushing me to store my keys in some "cloud" password manager? If I'm going to the trouble of setting up passkeys I want to be in control of them across all my accounts. That means my own hardware dongle. Not some cloud vendor's pinky swear that they'll take care of them and let me use them on my terms.

What's annoying about passkeys (and not talked about enough, including in this article) is that passkeys seem to be a boon for the targeted-advertising industrial complex.

Since passkeys are tied to verified devices, they guarantee absolute de-anonymization -- and further spread that advertising "wealth" by seamlessly linking across devices, and therefore to their respective corporate stakeholders (i.e. via bluetooth to conveniently login on a laptop via a phone-domiciled passkey).

Username + password at least requires circumstantial marketing analysis to "verify" whether a user is who marketers think they are. But with passkeys, your login confirms your Windows account ID, cell phone MAC address, home address, what have you.

As a user if you push something too hard I immediately think what the angle is. That is how i feel about passkeys.

If it looks like a duck...

Passkeys are confusing, fragmented, awkward, and annoyingly implemented. They aren't a trap, but they are far less efficient and less proven than a password and app-based MFA.

Lot's of additional great information for consumers and prosumers at whatarepasskeys.info. Many of the questions that are constantly discussed in these comments are answered in the FAQ and content.

Contributions and feedback are welcome! GitHub link is at the bottom of the page.

> [Attestation] say nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.

Largely false. The Pixel verifies the OS and will reveal `verifiedBootState != Verified` on GrapheneOS in the attested passkey at registration, which websites may choose to reject. Apple Silicon has an undocumented SEP which prevents Asahi Linux from accessing it. There may be other examples now or in the future.

Also, I think you can deduce the device color from [1] on Android.

So, in conclusion: https://storage.ghost.io/c/ee/88/ee889f88-37ef-43e5-9180-f9b...

[1] https://source.android.com/docs/security/features/keystore/a...

I was expecting the author to at least address the thinly veiled threat to blacklist KeePassXC at [0] (via the very same mechanism they claim is harmless), but of course it's not even mentioned.

I'm sorry, but if your system allows someone to make a credible threat like this, you should make sure to redesign your protocol so that kind of abuse is not possible BEFORE advocating for it. I'm so incredibly sick of people repeating history, only to disappear once we're all roped into yet another anti-user scheme.

And yes, passkeys absolutely ARE a trap.

[0]: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

Some context I think is missing: TFA's author claims to use passkeys for 2FA (and so, not as a password replacement as I think is often implicitly assumed in discussion):

> This one can be tricky because I've seen many sites using passkeys to replace passwords, but that's not something we've done on Report URI, passkeys are used as a 2FA mechanism.

Source: https://scotthelme.co.uk/xss-is-deadly-for-passkeys-the-hidd...

Every point in that post has been discussed at length other places, some of which is in the HN thread the author mentions. And the discussions make it clear that the points being made are not seeing the problem - not that there isn't a problem.

Passkeys have benefits - but they also have problems. Many people just don't think the benefits are worth the problems. And many people are afraid that sites will just stop accepting passwords in favor of passkeys, leaving people worse off.

>here’s why you should use XYZ!!

Few weeks later

>let me tell you why you should NOT use XYZ!!

Classic HN.

That being said, password and 2FA is the best combo, where you control the token of the 2FA and it’s on a separate app/platform/etc than where you have your passwords.