Live data from Hacker News

Passkeys and Modern Authentication

lucumr.pocoo.org

41–50 of 212 posts

Re: Passkeys and Modern Authentication

#41

Unfortunately the tech community is full of people who pride themselves on being aware of and advocating for the latest standard put out by whatever company. That's how we end up with lots of complicated nonsense like most of what is sent in HTTP headers, or the contents of a TLS certificate. On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse . Signing up is uploading…

> Signing in is cryptographically signing a commitment to the current ephemeral tunnel. I can see how SSH could be used for authentication on the web. And I have no doubt that it would be sound out-of-the-box. But I am not sure what you mean by your last sentence. Do you mean that authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding? Aside from the wonderful possibi…

Not just non-technical people, but a lot of Windows developers I've worked with over the years can't seem to grasp the asymmetric key concept enough to use it for git (and then complain about git over over https).

Being in charge of the strength and security of your private key is something most people don't want to do, so we get multiple identities made "easy" by walled gardens getting popular in passkeys.

Re: Passkeys and Modern Authentication

#42

Earlier quoted context omitted.

There are multiple solutions to this, with tradeoffs. Doesn't change the fact that the service should only want a public key, and you should only give the service a public key. That's where this new complexity is being forced on users and developers. You need to be able to sign in, or let your users sign in, but you can choose how complicated of a key management strategy to have. You can either have 1 key pair per se…

You are describing passkeys. All of this applies to the passkey scheme. Actually, a benefit of passkeys is the standardization of client-side cross-device authz operations via caBLE and similar; your secret keys never leave your primary device, but are usable from other devices over a variety of transports.

> All of this applies to the passkey scheme.

It also applies to SSH keys. I never said that passkeys couldn't do everything SSH keys can do. My criticism is that they are more complicated to do the same thing.

This is exactly what not valuing simplicity looks like.

Re: Passkeys and Modern Authentication

#43

What do security professionals think about passkeys? In particular, those who were not involved in designing them. Lots of the arguments in this article feel very much like the sort of thing one would expect from someone into open source (not saying they are wrong, and I think they are well explained here) but I feel they will inevitably be the product of different concerns than those a security practitioner might ha…

Security people are generally pretty positive on Passkeys. Eliminating passwords has been the white whale of information security for over 3 decades. Practitioners are generally positive about FIDO2 (Yubikeys are fetish objects for them). I think message board people would probably be surprised at security practitioner attitudes towards Apple and Google authentication lock-in (locking my team into Google authentication would be one of my first moves at a new firm, and that's not an idiosyncrasy of mine so much as me doing what other CISO-types all say they do).

Re: Passkeys and Modern Authentication

#44

> there is effectively no way to export private keys between authentication password managers No exporting really is a feature. Otherwise people would be tricked into giving away passkeys much like they are with passwords today. You can always register multiple passkeys with providers though. Already have a passkey with google but want another one via a different password/account manager? Just go into settings on goo…

> Otherwise people would be tricked into giving away passkeys much like they are with passwords today.

Is this really a common attack vector vs. a company leaking their whole customer database and a bunch of password being revealed that way?

Re: Passkeys and Modern Authentication

#45
One day Authy for desktop was deprecated and all of a sudden I was forced to always have my smartphone with me, which I was struggling to replace with a dumbphone. To this day, I have no way out of owning an smartphone for this very reason

Re: Passkeys and Modern Authentication

#46
post #7

Exporting passkeys is the single required feature for me to start using them more. The "anti phishing" push has really gotten a little too crazy. It seems mostly related to our legal inability to push security responsibility onto consumers.

Given that you don't strictly need to have one passkey per site, is this desire to move passkeys around a holdover from wanting to "export" your passwords? Because if you can export them, an exploit can too. I find passkeys rather more interesting when they cannot be exported from a HSM / key enclave / yubikey, but of course I need to be able to register multiple yubikeys per site, and a few of my accounts didn't all…

You should be allowed to keep your passkeys in such enclave. But there seems to be no alternative. I'm in the same boat as the GP. I'm not touching passkeys unless and until I can export them into a file I can get my grubby hands on. I'm guessing that's never happening. Not sure what one-passkey-per-site has to do with it.

Re: Passkeys and Modern Authentication

#47
post #7

Exporting passkeys is the single required feature for me to start using them more. The "anti phishing" push has really gotten a little too crazy. It seems mostly related to our legal inability to push security responsibility onto consumers.

Nothing to do with legal responsibility and it's not about only consumers.

I have 50 terabytes of data breaches on a NAS with lots of plain text or badly encrypted passwords, and that's just a small subset of what's out there.

Re: Passkeys and Modern Authentication

#48

Earlier quoted context omitted.

But requiring exports to be encrypted is the least one can do to maintain a degree of security while still allowing exports. Why is the protocol dictating the user's security model? I can see why particular applications wouldn't choose to support insecure exports (and would even agree with that), but I genuinely don't understand why the protocol is dictating that an application can't allow users the freedom to choose…

The other side of this is the Relying Party, a.k.a. the website operator that is relying on the user's password manager to be decently secure and resistant to phishing. Otherwise, why ditch passwords plus 2FA?

The website already has guarantees against phishing because those are enforced by the managers. What's prevented is the snooping case of taking an export and cloning it without the exporting manager being involved. This is essentially indistinguishable from many legitimate use cases like archival or access to deceased relatives' credentials, which users might want regardless of the website's preferences.

Re: Passkeys and Modern Authentication

#49

> there is effectively no way to export private keys between authentication password managers No exporting really is a feature. Otherwise people would be tricked into giving away passkeys much like they are with passwords today. You can always register multiple passkeys with providers though. Already have a passkey with google but want another one via a different password/account manager? Just go into settings on goo…

> Otherwise people would be tricked into giving away passkeys much like they are with passwords today. Is this really a common attack vector vs. a company leaking their whole customer database and a bunch of password being revealed that way?

Yes, it's called phishing.
Post reply on HN