Hacker News Reader

Comment by whack | Hacker News Reader

Like the blog post mentioned, 99.9% of users already have JS enabled, and this number is only going to go up as websites rely more and more on JS. For them, this is a purely beneficial change, with no downsides. It's somewhat selfish for you to ask that your system be made more secure, even at the cost of security for 99.9% of other users.

View on HN

I'm hijacking this thread to say we need a better ID system for the web! That preferably work without JS. Something built into browsers, that also allow you to create as many identities you want. When a id-signup header is detected, the user see a signup button, and can chose what information is sent to the web site/app. The user can login to any site with the push of a button, or even automatically. With a built in public-private key ID solution your friends will have the same ID-public-key on both site A and site B. The contact list can even be inside the browser, and web site's can ask for it, allowing for example white-listing in messenger apps, or let the user pick who are allowed to see their family pictures, etc. And web sites/app no longer have to store, username/password/keys, they only have to make a "challenge" where the browser automatically proves the ID. The private key should be exportable and standardized, and it should be possible to also use smart-cards and second factor logins. Having ID built into the browser means every site/app no longer have to build and manage all this functionality independently.

This is brilliant! Has the IETF put out any proposals for a standard of this sort or is this just an idea you had?

Unsure if sarcasm, but OpenID has been a thing for over ten years, and the only place it's ever gained significant traction is with Facebook and Google as the providers: https://en.wikipedia.org/wiki/OpenID#History

Other than StackExchange, I can think of no other major site who looked at the over-engineered protocol, the implementation headaches, the confusing user experience (nascar board of provider logos), and said "yes, that is definitely what we want to have rather than a validated user email address."

Chrome supports U2F and that is basically a client cert based ID. But yes, the browser should be able to manage identities on a per domain basis.

> The contact list can even be inside the browser, and web site's can ask for it, allowing for example white-listing in messenger apps, or let the user pick who are allowed to see their family pictures, etc.

How would that work for sites like Hacker news, reddit, and twitter? Does every single user have to preview and approve every single other user on the website? That doesn't scale at all.

It would work the same, except you can sign up with one click, login with one click, and the server wouldn't store any password/key. But it also allows for additional functionality, for example in a photo sharing app/site you could tell it that only those with these ID's should be able to see the picture, without the site/app needing to know who those people are, they don't even need to have an account on that site.

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.

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.

This is basically U2F

One of the reasons that the percentage of users who have JS enabled continually goes up is because web developers make their sites non-functional when JS is disabled.

An error only becomes a mistake when you refuse to correct it.

Reply on news.ycombinator.com