6 ms·

I posted this on the StackOverflow page. I'll put it here too. Apologies if it is too long. I think BrowserID[1] (or perhaps more precisely, the Verified Email

I posted this on the StackOverflow page. I'll put it here too. Apologies if it is too long. I think BrowserID[1] (or perhaps more precisely, the Verified Email Protocol[2]), the recent effort by Mozilla's Identity Team[3], deserves a mention here. I'll summarize it this way: 1. Mozilla is a nonprofit with values[4] that align well with finding good solutions to this problem. 2. The reality today is that most websites use form-based authentication 3. Form-based authentication has a big drawback, which is increased risk of phishing. Users are asked to enter sensitive information into an area controlled by a remote entity, rather than an area controlled by their User Agent (browser). 4. Since browsers are implicitly trusted (the whole idea of a User Agent is to act on behalf of the User), they can help improve this situation. 5. The primary force holding back progress here is deployment deadlock[5]. Solutions must be decomposed into steps which provide some incremental benefit on their own. 6. The simplest decentralized method for expressing identity that is built into the internet infrastructure is the domain name. 7. As a second level of expressing identity, each domain manages its own set of accounts. 8. The form account@domain is concise and supported by a wide range of protocols and uri schemes. Such an identifier is, of course, most universally recognized as an email address. 9. Email providers are already the de-facto primary identity providers online. Current password reset flows usually let you take control of an account if you can prove that you control that account's associated email address. 10. The Verified Email Protocol was proposed to provide a secure method, based on public key cryptography, for streamlining the process of proving to domain B that you have an account on domain A. 11. For browsers that don't support the Verified Email Protocol (currently all of them), mozilla provides a shim which implements the protocol in client-side javascript. 12. For email services that don't support the Verified Email Protocol, the protocol allows third parties to act as a trusted intermediary, asserting that they've verified a user's ownership of an account. It is not desirable to have a large number of such third parties; this capability is intended only to allow an upgrade path, and it is much preferred that email services provide these assertions themselves. 13. Mozilla offers their own service to act as such a trusted third party. Service Providers (ie Relying Parties) implementing the Verified Email Protocol may choose to trust Mozilla's assertions or not. Mozilla's service verifies users' account ownership using the conventional means of sending an email with a confirmation link. 14. Service Providers may, of course, offer this protocol as an option in addition to any other method(s) of authentication they might wish to offer. 15. A big user interface benefit being sought here is the "identity selector". When a user visits a site and chooses to authenticate, their browser shows them a selection of email addresses ("personal", "work", "political activism" etc) they may use to identify themselves to the site. 16. Another big user interface benefit being sought as part of this effort is helping the browser know more about the user's session[6] -- who they're signed in as currently, primarily -- so it may display that in the browser chrome. 17. Because of the distributed nature of this system, it avoids lock-in to major sites like facebook, twitter, google etc. Any individual can own their own domain and therefore act as their own identity provider. This is not strictly "form based authentication for websites". But it is an effort to transition from the current norm of form based authentication to something more secure: browser supported authentication. [1]: https://browserid.org/ [2]: https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest [3]: http://identity.mozilla.com/ [4]: http://www.mozilla.org/about/manifesto.en.html [5]: http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_10.pdf [6]: https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest-Session

tptacek 15y ago
It is a little frustrating that, when the Stack Overflow community attempts to come up with a "definitive guide to website authentication", people inside and outside the community see the attempt more as a coatrack for their own blue sky proposals than as an opportunity to codify best practices. The fact is that BrowserID, like SRP (which the SO community itself inexplicably waded into), is not an authentication best practice. It's a proposal that doesn't even have widespread support in the deployed software of its sponsor. Even without getting into the pro's and con's of BrowserID, the simple fact is that if absolutely everything broke Mozilla's way, it would still be many years before a significant number of users would be using it securely. I really don't want to debate BrowserID here, most particularly because I don't have a strong opinion about it. But isn't it weird how even the Stack Overflow people themselves can't look at a challenge like this without spinning off into deep space on sky-pie crypto answers?
- charlieok 15y ago
  I've been frustrated for a long time by the lack of browser support for strong authentication with a good user experience. Form-based authentication always felt like a terrible hack. That's the only dog I have in this fight. I certainly didn't want to frustrate anybody by posting what I did. If you like, I will delete what I posted on the StackOverflow page. Just say the word.
  - tptacek 15y ago
    No, I'm just ranting, because HN is where I rant. It's good that you care about this stuff. If anything, it's the crazy SRP stuff in the original proposal that really sets me off. It is, in the end, frustrating that nobody (myself included!) wants to buckle down and write up all the boring details of how to do secure authentication today.
    - charlieok 15y ago
      SRP is cool stuff, but if we're going to do SRP I would be more interested in doing it right. I think that would mean having browsers support a standard SRP protocol binding (eg http://www.ietf.org/rfc/rfc5054.txt http://www.ietf.org/rfc/rfc5054.txt) and then really nailing the browser user interface. I could see using SRP as an alternative to private keys, or as a strong "something you know" factor in addition to private keys (a "something you have" factor) in order to establish ownership of an account. However, this doesn't strike me as a credible first step in getting through the aforementioned "deployment deadlock" issue.

tptacek 15y ago

It is a little frustrating that, when the Stack Overflow community attempts to come up with a "definitive guide to website authentication", people inside and outside the community see the attempt more as a coatrack for their own blue sky proposals than as an opportunity to codify best practices. The fact is that BrowserID, like SRP (which the SO community itself inexplicably waded into), is not an authentication best practice. It's a proposal that doesn't even have widespread support in the deployed software of its sponsor. Even without getting into the pro's and con's of BrowserID, the simple fact is that if absolutely everything broke Mozilla's way, it would still be many years before a significant number of users would be using it securely. I really don't want to debate BrowserID here, most particularly because I don't have a strong opinion about it. But isn't it weird how even the Stack Overflow people themselves can't look at a challenge like this without spinning off into deep space on sky-pie crypto answers?

charlieok 15y ago
I've been frustrated for a long time by the lack of browser support for strong authentication with a good user experience. Form-based authentication always felt like a terrible hack. That's the only dog I have in this fight. I certainly didn't want to frustrate anybody by posting what I did. If you like, I will delete what I posted on the StackOverflow page. Just say the word.
- tptacek 15y ago
  No, I'm just ranting, because HN is where I rant. It's good that you care about this stuff. If anything, it's the crazy SRP stuff in the original proposal that really sets me off. It is, in the end, frustrating that nobody (myself included!) wants to buckle down and write up all the boring details of how to do secure authentication today.
  - charlieok 15y ago
    SRP is cool stuff, but if we're going to do SRP I would be more interested in doing it right. I think that would mean having browsers support a standard SRP protocol binding (eg http://www.ietf.org/rfc/rfc5054.txt http://www.ietf.org/rfc/rfc5054.txt) and then really nailing the browser user interface. I could see using SRP as an alternative to private keys, or as a strong "something you know" factor in addition to private keys (a "something you have" factor) in order to establish ownership of an account. However, this doesn't strike me as a credible first step in getting through the aforementioned "deployment deadlock" issue.