Facebook launched a platform that lets third-party developers add Facebook applications. This is visionary, and it’s very very cool (though I’m not sure it’s the revolution everyone is talking about.) The problem, of course, is authentication. Take a look at the Zoho Facebook application. Zoho is a separate company. They have their own accounts. So now they have to associate an existing Facebook account with an existing Zoho account. The only way they can do this currently is to ask for the Zoho password from within the Zoho Facebook application, which is served from facebook.com. So now verifying the URL before you enter a password doesn’t mean anything. You have to trust facebook, and by that token all of its third-party developers, with all of your passwords. Great!
People have been saying this for years, but now the rubber meets the road for real: we need some kind of authentication infrastructure. And guess what… OpenID won’t cut it here, because the issue is to find some way to provide Facebook with a token that it can forward to Zoho that will let Zoho authenticate the user, and since OpenID only supports direct authentication rather than cryptographic-token-mediated authentication, it won’t work. I’m guessing CardSpace won’t work either, although I don’t know it well enough to say for sure.
No, what’s positively fascinating about this is that there’s a need for some fairly complex authentication mechanism, where the user is specifically asked to associate two different accounts on two different systems. The right solution almost certainly requires cryptographic tokens. I’m not sure what it will take, but we’d better think fast, because this kind of application is precipitating the end of the password authentication concept.
Benlog 
Comments
5 responses to “Facebook Platform: bad login practices, OpenID doesn’t work”
Interesting point Ben. You need a variant of Internet Kerberos that allows you to authenticate with other services w/o revealing your actual credentials.
However, the issue with facebook is the fact that it proxies all of the traffic through it so be it OpenID, iKerberos or whatever you will still have this problem.
If you were authenticated with Zoho already and FB could just pass Zoho cookies through that would achieve your “crypto token” goal. However, if FB was compromised anyone could just “borrow” my Zoho cookies and impersonate me.
Eugene,
So Facebook proxying the content is not great for privacy, but at least we should find a way to secure the authentication tokens, even if the content is not secured. You can’t send the Zoho cookies to FB, since they’re on a different domain…. It’s an interesting challenge to do this generically.
quote: “where the user is specifically asked to associate two different accounts on two different systems”
I can think of more that one way to solve this, but the first thing that comes to mind is the SAML specification. Isn’t federation just about using assertions to connect different user accounts on different systems?
Leon: I’m sure there are plenty of protocols that do this nicely, assuming everyone talks SAML… but Firefox doesn’t talk SAML, right? So how do we do this *on the web*? Do we need new infrastructure in the browser? Can it be done with passwords (i think likely not)? It’s not an issue of whether it can be done theoretically, it’s an issue of whether it can be done with the software we have deployed today or in the near future.
[…] Facebook’s. Even though they are not apparently abusing the credentials, they’re still getting users accustomed to the concept of entering one site’s password on a different site. But if you look at it from the LinkedIn point of view, what choice do they have? How can they […]