A day in the life II » security

Sociable! Facebook Connect WordPress plugin

Malcolm — Sat, 06 Dec 2008 14:59:53 +0000

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.

Security/Privacy – Disk/File wiping not nearly as rigorous as I was led to believe

Malcolm — Wed, 27 Aug 2008 13:25:45 +0000

Just a short update.

It turns out that even the venerable Peter Guttman (who proposed in 1996 or so that we use a 35-pass wipe according to a strict algorithm to protect our old/deleted data) thinks that with today’s storage and recovery technologies, only a few passes are now needed to protect us from snooping.

I used to advocate the 35-pass wipe algorithm but now I think you only need to do that if you don’t know what types of passes should be used for the type of modern drive you have.

A private Wiki article.

The Guttman article with the Epilogue about the actually required passes versus the 35-pass algorithm.

“Identify yourself, no?”

Malcolm — Sun, 18 May 2008 18:00:15 +0000

“Pinky Carruthuers. Blue-Blaze Irregular.”

I apologize, but it’s been a long time since I created this blog – long enough that I’ve forgotten who y’all are. If you came over from LJ, Welcome! and I’ve already added you to appropriate viewing groups based on your username. But if you created a user name that’s not obviously linked to an LJ name or some other name I’m familiar with, then I apologize, but I have definitely forgotten who you are.

So if you’d like to enjoy privileges you’ve already earned (by being such a good buddy!), then please let me know who you are on this blog so I can make sure you see all appropriate posts.

Feel free to let me know here in comments or in e-mail at malcolm.gin@gmail.com.

Thanks!

Started posting protected content on my WordPress blog

Malcolm — Sun, 18 May 2008 12:25:00 +0000

So if you’re reading and interested, you’ll need to register or login to read those posts on the site.

Not entirely sure I like the post locking tech that is User Permissions for my purposes

Malcolm — Tue, 04 Dec 2007 01:14:29 +0000

This is about the WordPress plug-in User Permissions, which works great from the point of view of organizing users so they can all collaborate at different permissions levels on the same blog, but is clearly not written or designed to facilitate different users’ varying access levels to a single blog/journal that is written by a single author. So like, I’d say if you were going to run a WordPress-driven LJ-like community, User Permissions would be your bag, baby, but for my purposes, I think the other one I was looking at (that is still being ported to WordPress 2.3) is probably better. So I will wait with bated breath for that one (Disclose-Secret) to be ported/made available for WordPress 2.3 instead.

So in the field of battle, it works. It allows for different individual posts to have different audiences. Unfortunately, you can’t change the naming of the audiences, and some of them automatically have rights to, for instance, edit your posts (and the ability to change different post settings).

But for my purposes, I think I will just continue to make only unlocked posts and wait for something better to come along.

Also, I had earlier mentioned WordPress Group Restriction. That one, according to my further reading, only really does similar things to User Permissions, but for WordPress Pages, which are non-post publishing entities people normally use for permanent/semi-permanent pages like about pages. They’d map more closely to your LiveJournal Profile page or Userpics page or so on. So that’s not a good choice for me either.

I’ll certainly let ya’ll know, though, if I find a good alternative.

Meanwhile, it should be known that I installed/activated Google Analytics Plugin for WordPress 2.0 (recently updated), as well as LJ4WP (which activates the tag within WordPress, which I shall largely use to refer to misia in my posts – and which does not appear to work, so screw that.).

P.S. Something screwed with the outgoing URLs on this post. Fixed.