Hacker News Reader

Comment by OtomotO | Hacker News Reader

[flagged]

> I don't give a fuck if other people can't manage secure passwords.

Sure you do. When your local tax office / hospital / large data holder of your personal data has an administrative interface that only uses passwords, then the administrator gets fished and your identity stolen, suddenly you care a great deal.

That seems like a separate problem, since no authentication mechanism can somehow force a competence floor onto your local government office. Even if passkeys become the industry standard (or even required by law) your local government office will always rise to the challenge to lose your data, leak your data, sell your data, etc.

Phishing isn't a competence issue. This is well studied. In practice, even security practitioners trained to be vigilant against phishing attacks fall to targeted ("spear") phishing attacks of suitable sophistication; that's the impetus behind phishing-proof authenticators like U2F and WebAuthn.

Phishing is a technology issue, not a user issue.

I work in the security space and fell victim to an internal campaign as they sent a very enticing looking email at a point where I was on leave and my grandfather just passed.

You simply cannot know what mindset youll be in when you get phished :)

Edit: To clarify i was itching to work because it helps distract me from the reality that someone so dear to me was gone forever. I didnt want to cancel leave though because my output would have been absolutely turdy

Problem is that passkeys aren't resilient enough to loss of the authenticator device, which means a fallback flow is always made available, that is vulnerable to phishing/MITM/social engineering.

This is even more pronounced thanks to the efforts to roll out passkeys to the masses. Most of them don't understand what they're getting into and are most likely gonna get themselves locked out quite quickly, which may mean recovery flows need to actually become more relaxed than they currently are.

I'm not interested in litigating the broader question of Passkey-only login setups, only in spelling out why the field cares so much about phishing-resistant authenticators, which password managers and random passwords do not provide.

Can confirm, I know all about cryptography and security and the things, and I still got phished for a bunch of cryptocurrency. The only thing that saved me is that it was in a hardware wallet, so it was physically impossible to steal. Otherwise I was ready to happily paste my private key into the (official-looking) form and domain.

> Otherwise I was ready to happily paste my private key into the (official-looking) form and domain.

Sorry, why would you ever disclose your private key to some online forum? I can't see a situation where it makes sense.

Clearly there's something I'm not thinking of, so I'm genuinely curious

I think you misread the word "form" as "forum" there.

Ah you got me, though I don't think it changes that much.

Even with an online 'form' (presumably a phishing page) I don't understand why anyone would ever upload private keys for their wallets.

In the case of exchanges, users typically don't get access to the private key for the wallets anyway, so pretending to be an exchange to phish for something the victim can't even provide wouldn't make sense.

In the case of a local wallet, the whole purpose is personal ownership of the coins—which obviously becomes moot when sending the private key to some random person—so I don't see why a user would upload them in this circumstance either.

Though yes, the situation is certainly more understandable than GP posting private keys to an online 'forum' ;)

I don't think it changes that much.

There's overwhelming empirical and anecdata evidence people make mistakes and fall for phishing. If that doesn't change your mind that much, it's not obvious what reasonably could.

Sure, but you're moving the goalposts. We're comparing a system that relies exclusively on passwords Vs one that relies on webauthn.

The operational competence of the dba is the same in both cases.

Or they store your password insecurely — plain text or merely “encrypted” with XOR.

I still see both of those regularly.

Everything boils down to some password or key (effectively a long password) access to some SQL instance.

Anything on top of that is just fluff. The database can still be compromised directly.

Keys are _not_ just long passwords. They're asymmetric. Feel free to steal any and all of my webauthn public keys.

Heck, here's one: "kty": "EC", "alg": "ECDSA_w_SHA256", "crv": "P-256", "x": "xYkEVgMClD28hXHn5JQjrgjRX3crmr0OhGiWKsLvxUY=", "y": "5lZZGFF6VrVubIHfRhGbvQBGpw6LcbP3/ZBVk7PqH0Y="

It's what you'd get if you somehow got into the db and decrypted it.

Now, do feel free to give me your nice symmetric secret password, since it's the same, yeah?

Keys can be symmetric or asymmetric depending on the algorithm.

From the standpoint of a non-technical user, they're not any different in nature; a password and a private key are both just strings that give full access to your account. One is easier to remember (password), one is harder to remember (key). The one that is harder to remember usually ends up in a Google doc, iCloud, or saved as a text file.

There's a difference between fluffy that's phishable (passwords) and fluff that isn't (webauthn).

Not all fluff is equal.

How is Webauth'n Crunch not phishable?

Most implementations throw about 20 "recovery codes" at you and at the absolute fucking worst possible moment while the user is trying to do something urgent, they say "save these in a secure place right now".

It's not 1, but 20 passwords that ALL give access to your account. Where do you think those codes go?

They are not only phishable, but they usually end up in a Google doc, screenshotted and pasted to Notion, or some other insecure place.

We're talking about webauthn, not recovery codes.

We have decades of supporting evidence that passwords are rubbish at this point.

Congratulations on being able to maintain good password habits yourself. It sounds like you already know how vanishingly rare that is.

and yet everyone recommends ssh keys over passwords. passkeys are just the ssh keys of the web

Ssh keys are files that can be moved easily from device to device. That's very different to using e.g. your proprietary macbook internals as your login key. Completely different lock-in.

You can just enroll multiple keys from different devices, just like you do with SSH, that's the recommended way. But even then, there are software implementations of WebAuthn, like 1Password. You can then use the local TPM as a "last mile" authentication mechanism to quickly and effectively unlock your local encrypted password database and then get the needed key material to do WebAuthn. I use this across all my devices e.g. to login to GitHub, even on my iPhone.

You could accomplish something fairly similar to this for SSH keys actually (an encrypted sync layer + deriving master keys from a local trusted source), but I don't think anyone has done this to the same level of polish.

You can do passkeys in software too:

https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys

A passkey is a synced, discoverable WebAuthn credential. While many implementations protect the private keys with additional security measures like secure enclaves or TPMs, it's not required. If you want to use an implementation that doesn't use those types of lock-ins, even when they're there to protect your credentials, you can. Multiple software-only implementations exist.

Until they start trying to enforce attestation. Then your only choice will be giving a large corporation control over your online access.

> I don't give a fuck if other people can't manage secure passwords.

I infer that you use a password manager.

Consider passkeys as a standardized interface for password managers.

> Consider passkeys as a standardized interface for password managers.

I have not followed WebAuthn spec for a while but I vaguely remember that the spec discouraged software-only authenticators.

Which made me feel like WebAuthn is yet another attempt to take the power from users and even states and concentrate it in the hands of a few multinationals controlled by US government.

Pretty much what happened to Certificate Authorities and the push to use HTTPS everywhere.

Of course there are benefits to HTTPS Everywhere and to passwordless authentication.

But they do not outweight concerns over the digital autonomy of my country.

For ordinary websites none of the existing platforms support WebAuthn attestation AFAIK, because the spec for attestation was not designed with key synchronization in mind, which is a key use case; otherwise, basic features like Keychain synchronization via iCloud would not work and the whole thing would be DOA. Synchronization is widely considered to be a core necessity to match the functionality of existing password managers.

I believe you can enforce attestation using MDM and a custom app as far as I'm aware. But for general people using Safari or whatever, you can't request any kind of device attestation.

1Password supports passkeys, and I am sure that others do as well.

Given the convenience factor (no extra install), I imagine that device/platform passkeys to be the most popular, but there should be no problem with using alternatives.

If the passkey protocol didn't support attestation, then that would be true. But since it does, passkeys aren't as good, since I can't make my own backups of them.

Generally attestation is not supported outside of enterprise contexts and Apple for example doesn't support it without mobile device management policies being applied to the device.

You can make your own backups of passkeys from your password manager.

I believe you are confusing ones that are stored in software or syncable (Passkeys) with the hardware backed credentials (platform authenticators).

> I believe you are confusing ones that are stored in software or syncable (Passkeys) with the hardware backed credentials (platform authenticators).

The problem is that the protocol allows websites to require use of the latter. If the two were indistinguishable to the website, then passkeys would be a good thing.

You're confused. You can use software that doesn't provide backups or clear exports, but attestation is not supported for any widely used websites or WebAuthn software because it defeats synchronization, something pretty much everyone widely considers to be a benefit. It would for example completely negate the ability to synchronize passkeys over something like iCloud, whether or not it had the ability to export keys in a standardized format. Attestation is basically a boondoggle solely for corporations with device management policies, so they can use a standard protocol/framework at the app layer while still enforcing stuff they already enforce.

The amount of people in this thread who don't understand the very basics of this stuff is a pretty good counterexample to the common trope they somehow "know better." I kind of doubt that when many people here can't even get the basics straight.

Couldn't, e.g., Apple implement attestation in such a way that you can move credentials between Apple secure enclaves, but still never export them in a way that you have control over them? That's what I'm worried about.

I don't believe there's any (public, stable) implementations of it yet, but Secure Credentials Exchange will let you export, transfer, and backup passkeys

https://fidoalliance.org/specifications-credential-exchange-...

https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html

That lets the megacorps make backups for me, but it doesn't let me make my own backups, because they'll only encrypt them to each others' public keys, not mine.

I do, so I have a working solution.

I am not migrating to something just because it's new.

My solution works for me. If it doesn't anymore, I'll see what I'll do.

Depending on the service I'll swallow the bitter pill and use another solution or simply not use the service anymore.

Every and any decision has consequences, on any side.

https://f8n-ipfs-production.imgix.net/QmaangUFNxGD6vRjnqzVnL...

Thank you, this made my day :)

Passkeys and 2FA recovery codes are all just shitty replacements for passwords.

Fight me. Grandmas and Joes end up putting these recovery codes in a Google doc because they don't know what the hell else to do with them. That is NOT more secure.

Hell, even try explaining the difference between the "secret key" and the "password" in 1password to a non-technical person. It's impossible.

> That is NOT more secure.

"More" implies a comparison to something.

Given that Grandmas+Joes were using "passw0rd!" for all their passwords, I would argue their GDoc of backup codes is considerably more secure.

Reply on news.ycombinator.com