Hacker News Reader

Comment by STRML | Hacker News Reader

In a certain sense this existed with the `<keygen>` element (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke...) which is unfortunately deprecated. But you still have all the same issues of moving and safeguarding key material.

These days with browser/mobile sync, maybe it's actually possible. But like a synced password manager, it makes a primary account breach that much more devastating.

View on HN

The problem with certificates is they require a central authority, eg. politics. We need something that can work anywhere, without any third party or central authority.

There's nothing about <keygen> specifically that requires a central signing authority. You could just as well generate a public/private pair, feed the website your public key, and sign challenges with the privkey to log in.

You can also create a public-private key pair using JavaScript. Only problem is that when you go to another site, it wont let you identify yourself using the public key you generated on another site. And the browser won't answer the challenge automatically. Lets say we make a browser plugin, as a proof of concept. Then when it has "product market fit" browsers can make it a built in functionality. It will however be hard to ask a user to install a plugin, just to signup/identify to your site/app.

FWIW, this is something U2F somewhat solves. There is still the following exhaustive list of problems:

1. Education for and purchase of U2F keys 2. Key loss recovery mechanism 3. Key stolen defense (you can't just rely on the U2F key alone, there must be a pw or other type of second factor) 4. Widespread browser & device support (without it, a user/pass is required as a backstop)

Nevertheless, it is progress.

A problem with U2F and prior solutions is that they are hard to implement and public/private key pairs are specific to website origin, meaning I can not use the public key as an identifier. We need something much more simple, basically all it needs to do is to proof the possession of the private key. It would however have the same problems, those you mentioned, which are difficult problems. My idea in order to make those problems less painful is to require key rotation at regular intervals, that way people will automate away those pain points. For example by generating two backups keys that the user is instructed to store off-line, which is then used every second month to rate keys, and can be used as proof of you owning a lost key. Then you can implement certificates etc independently eg proof that the person holding the key is a certain person. But it's important that such things are not in the spec - or it would be too complicated, leading to no- or slow adaption.

Reply on news.ycombinator.com