Hacker News Reader

Comment by ora600 | Hacker News Reader

What I'd really want to see is public-key authentication for website.

Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.

View on HN

Have you read the spec? https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol

That's essentially what this is... with a verification service and web based UI to help bootstrap it.

A good way to check if does the right thing is to make sure it does not depend on the security of DNS. Is this the case? (I'm still trying to find out.)

BrowserID implements https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol

From that document: "destination.com retrieves Alice's public key from mailhost.com by using a webfinger lookup over SSL."

So it looks to me that the system's security depends on the attacker not having compromised DNS such that the relying party's query of mailhost.com is intercepted. Depending on the implementation doing this "over SSL" provides some additional security over unchecked reliance on DNS, but given how frequently keys roll, it may not be that much in practice.

BrowserID references the verified email protocol as an inspiration, but they specifically removed the webfinger bits.

Apparently, it does not do what I hoped it would. Assertions are about ownership of an email address, not about control of the private part of a key pair.

This already exists, but the UX is terrible and there's a chicken-and-egg problem in getting it fixed in every (deployed) browser.

http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...

Yeah, even using them over at GitHub (well, pushing with Git over SSH in general) has proven to be a rather steep learning curve for a lot of people. But hey, it's being widely adopted there, so that's a step in the right direction for this.

Something like this already exists. Your browser can already identify itself with a certificate.

The interface is ugly and cumbersome for the non-technical (even in Firefox) and I don't think it's used very often, but I know that MIT issues certificates to students which identify them to all MIT's web applications, as well as third parties like the Apple and Dell student discount pages.

Dartmouth does this as well, and I agree the interface sucks in browsers. Especially since most browsers will gladly show expired certificates for you to choose so you have to manually prune your list.

Same here. That's basically what I suggested here: http://news.ycombinator.com/item?id=2677140

Email addresses are typically controlled by a third party, so it doesn't make much sense to me that they should be equated with identity. Would you equate your identity with your IRL work address?

On the other hand, private keys are held only by the person whose identity they represent. They are a better way to represent identity because they do not rely on third parties.

They don't equate with identity but give a way of communicating with the user using a different channel. In a world of passwords this allows that password to be reset.

FireGPG has something built in to do this. It's called gpgAuth. http://getfiregpg.org/

It's discontinued though unfortunately. Although there are still people out there making it work with newer versions of Firefox: https://grepular.com/FireGPG_on_Firefox_5

That's in a way what BrowserID is. Except all sites share one public key, and your browser holds the private key. (Thus replacing ssh-agent)

Will you and the website owner each verify the key fingerprints? What I'm getting at is it's a hard problem to solve, because users want it to be quick and easy. But that often works against the stated goal of security.

I don't see why the website would need to verify my key fingerprint. Verification is needed when you care who a key comes from. For typical websites, they don't need to know who I am. They only need to know enough to recognize on subsequent logins that I'm the same person who provided the key at account creation, and the key itself has all they need for that.

This... A million times this. Where do I signup?

This. Perhaps ssh+http is the solution.

Where is 'this.' coming from? Coding syntax?

I just don't get it. I've seen it in HN comments for a few days now, but I fail to understand how 'this.' relates any new information. Reply indenting already tells me you are referring to an antecedent post. (A specific post in fact.)

Am I missing something, or is this just a new web fad I'm not savvy too? (Second option is not entirely unlikely...)

It's just for added emphasis. It's the contraction of roughly "this is the correct answer".

Thanks for enlightening me =)

This is the new +1

It is popular on sites like reddit. It basically means "I agree".

if you're interested in ssh-like functionality and http, I just wired browserid into my shell server for in-browser logins: http://benctechnicalblog.blogspot.com/2011/07/browserid-in-b...

Reply on news.ycombinator.com