Tag Archives: fail

Posted on
by

failwhaleIt seems like just the other day when I had to change a whole bunch of my passwords thanks to LinkedIn having it’s password database stolen by crackers, and now I’m having to do it again. This time it was Twitter that dropped the ball, but I am at least grateful that they’ve publicised the incident so widely.

Username/Password systems suck, I’ve written about this before. We should, as an industry, aim to move past them as quickly as possible, and it’s nice to see some attempts at this (although, a lot of those attempts are attempts to centralise identity in one form or another).

Like most people, I did recycle passwords on a number of services, and yes I know this was bad, but I only have a limited space in my head and I don’t enjoy having to remember long strings of alphanumeric characters. The main issue I’m having with this latest breach, other than the hassle of having to go around and change a bunch of passwords again (which is largely my fault I admit), is that Twitter, like Facebook and Google, can be used as a way to log into other services via OAuth.

This is very handy, and means that you can quickly sign on to a 3rd party service without having to create yet another password to remember. However, the downside, is that this central identity MUST be secure. Facebook and Google both add extra security to their accounts by having 2-factor authentication systems in place, so, when you access your account via a new device, you have to go through an extra security challenge – typically, entering a code sent to your phone or from a key generator app.

Twitter, on the other hand, doesn’t have this extra level of security. This means that the crackers could have access to not only your twitter account, but also any 3rd party service you’ve used twitter to log in with.

This is a big deal.

Personally, I think that any service that provides OAuth logins to other services, but doesn’t provide 2-factor authentication, is being somewhat irresponsible, and I really hope that Twitter fixes this with the utmost urgency. I for one will be using my Google account more…

Posted on
by

WordPress, the popular blogging software written by Automattic, has a problem with SSL self signed certificates. Basically, they don’t work well in any of their newer software products or services.

In order to post an update, I must first log into my blog. This requires me entering a username and password into a login box in the usual way. By default, WordPress does not use the secure HTTPS protocol for this, instead it sends this password in the clear over HTTP.

This is not good, so I, like many others, force WordPress to carry out login and administration functions over HTTPS. This is relatively straightforward, and well documented in WordPress’ own documentation, but requires a SSL certificate.

You can obtain a SSL certificate in one of two ways. Either you pay for a third party issuer to give you one (which has the benefit of not triggering a warning in the browser), or you generate one yourself – a so called “Self Signed” certificate.

Self signed certificates are perfectly valid, but browsers will display a warning on sites which use them. A problem if you’re running a public facing service, but not if it’s just for your own private blog, and crucially the traffic is still encrypted.

The Problem

Unfortunately WordPress don’t seem to like self signed certificates.

The iOS WordPress client once worked fine with self signed certificates, but this functionality was removed in an update a few months ago. Attempts to connect now display an error about the certificate’s self signed status, but unlike all browsers, will not give you the option to proceed.

Jetpack, which is now replacing much of the functionality previously provided by separate WordPress plugins (most importantly WordPress stats), is completely broken.

When you attempt to activate the plugin, Jetpack complains about being unable to communicate with the site with the following error:

Error Details: The Jetpack server was unable to communicate with your site [IXR -32300: transport error: http_request_failed SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed]

There is no way to bypass this, since the cURL error originates on the Jetpack servers and would require a code change at their end to allow the self signed certificate.

WordPress remain tight-lipped

I am not alone in encountering these problems, but so far attempts to contact WordPress/Automattic for support by various mechanisms have all gone unanswered.

It is a legitimate point of view that certificate failures caused by self signed certificates should be a fatal. Personally, I think providing a mechanism to bypass these errors for those who know what they’re doing, is a better solution, but making it fatal is a legitimate point of view from a security standpoint.

I could resolve this issue by buying a certificate, although I have a number of good reasons, some financial and some technical, for why I have not yet done so. If Automattic were to point blank refuse to support self signed certificates in their products then I would have to find a way of making it work.

I also accept the possibility that I could have made a mistake in configuration, although I’m not sure what this could possibly be, and it is only Automattic products that are having issue.

I accept all this, however all requests for support in forum threads and direct, from myself and others, go unanswered. Bug reports for the iOS client are months old and are ignored. Similarly, direct support requests to Jetpack go unanswered.

Automattic: If self certified certificates are a feature that just won’t be supported, then please communicate with me and your other users, or at least update your FAQ. If you think I’ve made a configuration error then please say so. Please communicate, because this silence is infuriating!

Update 20/11/12: After much chasing around I’ve got a response, about JetPack at least. Seems that not allowing self signed certificates was originally a design decision (a clearer error message would have been nice!), however this decision has been re-thought and it is now seen as a bug. There is currently no time-scale as to when the issue will be addressed.

Posted on
by

Canonical has come in for a little bit of heat for the inclusion of the Unity Shopping Lens into the latest release of Ubuntu.

This new tool, installed and switched on by default (although you can turn it off if you want), extends desktop searches online. The upshot being that when looking for a file or application on your desktop, it will also perform an Amazon search for products with similar names and keywords. You then have the option to buy these products (of course netting Canonical a cut from the referral).

Many find this an objectionable direction for a free software platform to take, although Canonical have to pay their developers somehow, and the service model has its limitations. A number of people in Europe have questioned its legality, given the stringent EU data protection laws.

However, I think Canonical may get bit by the law of unintended consequences just simplistically piping a search string through a third party engine.

Check out what happened when I looked for the Terminal application:

Ooops!

I think being offered Playboy DVDs from within the desktop may get people’s backs up, even if the choice to ad fund development of the operating system doesn’t!