Something’s stinky in Denmark.
Update 1 below.
Update 2: Looks like one of (the?) author(s) over at Sociable! is here, commenting. Cool! Based on his comments, I’m updating the post. Essentially, the login is now in a URI-showing pop-up window (good), but without SSL (still not sure why).
Update 3: I’ve been doing some reading on Facebook’s developer API and have learned that Facebook says that login/token passing transactions are always submitted with SSL but… it’s better to be as sure as possible. I’ve offered in e-mail to the author to hack the Sociable! code to make the calls to login to Facebook’s SSL resources, and I think I’ll create another test WordPress blog and try hacking it myself anyhow.
As you know, I’m a pretty avid adopter of some of the new third party ID functionality that folks are offering these days. I didn’t integrate this blog with MySpace because I don’t have a MySpace account (but I suppose I could be convinced), but I did adopt the Google Friend Connect functionality on the day it was offered, and I’ve thought about doing the same with FaceBook Connect, but I won’t do it yet until there’s a better third party plugin to use or I can hack my own (or maybe the Sociable! folks will fix their issue themselves (I’ll keep checking in).
The issue is both verifiability and connection security. With the Google Friend Connect that I’ve implemented, when you click “Sign In” while logged out of Google’s supported identity services (Google itself, Yahoo, AIM or OpenID), a browser window pops up (URL visible, but no SSL) asking you to login to your preferred identity service, and then at least in the case of Google’s identity service, the connection changes to SSL (URL visible) and you login to a familiar-looking login prompt. This is the right way if you’re going to do this at all because it assures the person who’s logging in that they’re both connecting to the right authentication provider and that they have some measure of security protecting those authentication credentials.
The problem with the Sociable WordPress FaceBook Connect plugin (the updated version as of this writing is here) is that the version of the Sociable! plugin I’ve seen, and that’s recorded in their demo video has a gaping hole a mile wide with respect to spoofing. When the login prompt pops up it’s in an identity-less floating frame with no URI, so you have no way of knowing whether you’re actually logging into www.connect.facebook.com or just giving your credentails away to somebody else. You also have no idea whether the prompt is protected with SSL.
NOTE (Update 2): The URI-less anonymous pop-up window was from and older (but still something I’ve seen in the wild) version of the plug-in. No idea why the URI that pops up does not use SSL, though, as it’s available at the destination Facebook challenge URI.
Contrast with the implementation the folks at Red Bull conceivably hand-coded or derived from the FaceBook developer wiki’s sample code. THAT implementation pops up a browser window, which, while uglier, has the benefits of showing you connection information like the URI you’re connecting to or potentially also SSL information. But Red Bull’s still doesn’t use SSL.
These two things (URI of the place you are submitting your login credentials to AND SSL protection for that interaction) really are needed before we can be assured that our logins are safe while we connect to the WordPress blog via FaceBook Connect.
I note that SSL is available at https://www.connect.facebook.com/, but both Red Bull and Sociable’s plugin seem to use the non-SSL form of the URI. (I wonder, but don’t know, if it’s part of Facebooks terms and conditions for developers.)
Anyway, I recommend against using the Sociable! plugin until it implements an SSL-connected popup window (unless someone tells me or I can find out why that won’t work) as well as the URI you can see for that moment where you actually type in your Facebook username and password and click the Connect button.
And in general I recommend checking the login site’s credentials, or using a browser that’ll help do that for you (Google’s Chrome, for instance, can help with this and I think there are settings and Plugins in Firefox that’ll do it too). Because otherwise you could just be giving your login credentials away to, well, anyone.
Finally, it may be possible to use GreaseMonkey (for Firefox) or some other extension on your browser client to force URIs to use SSL (rewrite http to https), but I am not going to stick my neck out and say that it’ll actually work to protect your login credentials.
Update 1: I should note that otherwise the implementation of Sociable!’s plugin looks good, and it looks like it wouldn’t, for instance, interfere with the Disclose-Secret plugin I use to have security-groups for certain private blog posts. So the integration looks fine and it’s just the security I’m worried about.