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.
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?
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.
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.
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) 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.
I actually would say it's relatively good as hacks go. It does a pretty good job of keeping the end goals in mind while dealing with some really tough obstacles. For one, it's browser agnostic, which makes the system much more manageable for all involved. In addition, it doesn't rely on people using the same copy of the same browser each time they sign in for any significant part of its functionality, and minimizes security risks if multiple people use the same browser. There's no way a browser-based solution could address any of those problems in the foreseeable future, if ever, and that not only would create huge headaches for developers, but would also alienate significant portions of users who still use public systems for at least some of their internet access.
Completely aside from that, I'm not sure I see why you think browser support would be so much better of a solution, aside from having a more uniform interface. Combating phishing is primarily an issue of being intelligent about what sites you give your information to. Any decent form-based authentication system will send the data in an encrypted form, which will be as secure as data encrypted by the browser's built-in authentication system. Just having the browser as a middleman doesn't help if your data gets sent to or intercepted by the wrong people, and Firefox, at least, already has a good system for warning users about malicious sites.
Mainly, I hate the proliferation of passwords, and I hate typing those passwords in all the time. I'd rather consolidate those down into a handful of distinct purpose-specific identities that I have some ownership and control over.
Also, you wrote: "Just having the browser as a middleman doesn't help if your data gets sent to or intercepted by the wrong people".
Actually, having the browser more directly involved does help with this, because it can use strong authentication when negotiating a TLS session.
By "strong authentication", I mean the authentication protocol has security features which make it useful over an untrusted network in the presence of eavesdroppers or even active adversaries looking to pull off a man-in-the-middle attack.
Client certificates are a good example of this and are supported by today's browsers but there are UX problems there.
It's not that the forms-based system doesn't work. I just think it could be a lot better.
Just consider how much easier it is today to stay in a "walled garden" social network than to be an active commenter on a large number of independent blogs.
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.