←back to thread

225 points Terretta | 4 comments | | HN request time: 0.001s | source
Show context
troupo ◴[] No.41856125[source]
I came across an opinion I largely agree with: https://mastodon.social/@lapcatsoftware/113308133338196824 and https://mastodon.social/@lapcatsoftware/113308273654667583

> These big tech companies will do anything possible to prevent users from ever actually being able to access their own passkeys.

> Export and import should have been extremely simple. Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.

> With passkeys, the big tech companies are executing a coup d'état of authentication, just like they did for HTML itself.

> In the end, they control every protocol, become the gatekeepers for the web.

replies(8): >>41856181 #>>41856189 #>>41856247 #>>41856254 #>>41856772 #>>41862312 #>>41862676 #>>41881156 #
lll-o-lll ◴[] No.41856254[source]
This is an exceptionally cynical take. WebAuthn is an open standard; this new credential transfer spec is the opposite of “big vendor lock-in”. It’s standardising the export-import.

Standards are slow and expensive to create and evolve. They involve endless meetings, discussion and design. However, the outcome is freedom.

The idea that this should have been “extremely simple” is just standard hubris.

replies(1): >>41856421 #
lapcat ◴[] No.41856421[source]
> This is an exceptionally cynical take.

> However, the outcome is freedom.

This is an exceptionally naive take.

> The idea that this should have been “extremely simple” is just standard hubris.

Why? Export-import of passwords is extremely simple and can be done with copy-paste or CSV. The only thing preventing this with passkeys is the paternalistic idea that users of passkeys should not be allowed to access them directly.

replies(2): >>41856486 #>>41856950 #
lll-o-lll ◴[] No.41856950[source]
> FIDO Alliance’s credential exchange specifications define a standard format for transferring all types of credentials in a credential manager including passwords, passkeys and more in a manner that is secure by default.

The hint of why this may be just slightly complicated is in that final phrase.

replies(1): >>41857285 #
1. troupo ◴[] No.41857285[source]
> The hint of why this may be just slightly complicated is in that final phrase.

The hint is that they are putting the cart in front of the horse, have decided on an outcome, and now are busy working towards that outcome.

ssh isn't less secure, and yet you can just copy-paste the required files on your own, instead of relying on convoluted protocols for moving data between black boxes.

It reminds of of their "Data Transfer Initiative" which "let's people move their data around easier" but underneath it's just "well, some of data between Google Apple and some other third party services only": https://dtinit.org

replies(1): >>41863271 #
2. 9dev ◴[] No.41863271[source]
SSH keys are a massive security liability. A private key, readable by any process you execute, without you noticing, that acts as a key to the kingdom? Maybe protected by a weak passphrase - since you probably have to enter that often - an attacker can brute force at their own discretion after copying it? A heap of public keys belonging to god-knows-which-machine, copied manually to every other server?

Designing a system that is secure, scalable, and works for billions of people worldwide in a highly adversarial environment is freaking hard.

replies(1): >>41865074 #
3. _hyn3 ◴[] No.41865074[source]
> A private key, readable by any process you execute, without you noticing, that acts as a key to the kingdom?

You're lumping together the data and access that SSH keys protect (which might be actually nothing) with the key mechanism themselves. The private key itself can be armored or stored in a Yubikey itself, or you can even use more exotic ways of protecting it.

The public keys can be easily automated while the private keys stay safe somewhere. Systems like SSH Universal Key Manager or Userify are out there (both on-prem, and Userify also has saas) to make maintaining the public keys across huge swathes of servers relatively simple (or sometimes extremely simple).

And not just authentication, but authorization, too (usually through something like sudo or doas). Or you can just roll your own with Ansible or LDAP (not nearly as flexible when dealing with two axis of variations - users and servers, but still doable). SSH keys being easy to manage is extremely important, because when things are hard to manage, people open security holes, either through ignorance or to save time.

So, like all keys, yes, SSH keys can be a massive security liability if not properly secured, but they're not so (intrinsically), or even by default.

replies(1): >>41867806 #
4. 9dev ◴[] No.41867806{3}[source]
But that's exactly my point; securing SSH keys properly is hard to do right at scale, and Passkeys are a solution to manage key pairs at scale.