After seeing someone’s Facebook security horror story about a local credit card (not one of the banks listed below), I was inspired to re-run the tests I previously ran on the South African banks, using SSL Lab’s SSL Server Test.

The results last time were awful, with Standard Bank and Absa falling way below the acceptable standard. This time, I was pleasantly surprised (previous results in brackets).

All of the banks have improved their scores. Capitec, which has dropped from first to third, still does not support Forward Secrecy, but has improved its key exchange ranking from 80% to 90%.

FNB, which jumped from second to first, has deployed HTTP Strict Transport Security (HSTS) with long duration. FNB gets the only A+ ranking.

Nedbank, which jumped from third to second, has improved from a B to an A, improving its protocol support and cipher strength rankings.

Absa and Standard Bank have both improved from F’s to A-‘s, and are joint third with Capitec. To put things in perspective, their rankings would have put them top during the previous test. So all banks are doing better than the best bank in May 2016. With no-one talking of a big four anymore (Capitec now outrank Nedbank in some metrics), perhaps little bit of competition is helping after all.

Related Posts:

• South African Banks SSL Security
• Standard Bank – not inspired, motivated and whatever the other one was
• Standard Bank and the Chinese crackdown
• Dear Standard Bank staff
• Spambank at it again
• FNB’s great new site

A friend told me today about an experience of attempting to book a flight on kulula.com. His credit card wasn’t working, but there was an option for bank transfer (EFT), so he chose that.

The EFT option used SID, a payment option promising secure EFT transactions. All good so far, so he followed the link.

The SID window asked him to enter his bank account login details… You know, the kind you’re constantly warned about to never give to anyone and never to enter on any other site except your banks.

I couldn’t believe that this is actually what happened (perhaps the friend had missed his morning coffee), so I checked it for myself. Looking into SID’s documentation, they claim to be externally verified, not to store the login details, and to use the bank’s own security system. But yes, you are asked to enter your bank account login details in their window.

I’ve got no reason to doubt that SID does what it says, but the methodology seems hopelessly flawed.

Let’s say I start a new payment system called SAD. At the same time I launch my casino website, relying on trusted SAD security. I state clearly that SAD uses the bank’s own security systems, and doesn’t store any of the login credentials. Totally secure!

The transaction succeeds, and the customer has a credit to spend on my casino site. They spend many happy hours on my casino website, winning up a storm, and dreaming of their new Tesla. For some reason the cashout option isn’t working today, but check back soon…

Some time later, they decide to check their bank balance, and find, to their horror, it’s all gone. They immediately phone their bank. Perhaps the conversation goes something like this:

HORRIFIED CUSTOMER: There’s a transaction clearing out my entire balance! It wasn’t me! The transaction needs to be reversed!

BANK: Hmm, our records indicate you logged in from internet banking, and transferred the money out. When was the last time you remember logging in?

HC: Er, I logged in to winbigbillionscasino.com and made a R50 transfer to their account from my bank account, using the safe and secure SAD system.

BANK: OK, no problem, we’re refunding the money now, apologies for the mistake.

Or perhaps not…

Perhaps the bank, in their charming and professional manner, laughs you off the phone and tells you you’re and idiot for giving your login details to another site.

Merchants asking customers to trust them, assuring them that their bank details are secure, is a recipe for disaster. Just don’t do it.

Related posts:

• South African Banks SSL Security

Image from Wikimedia Commons

After coming across an article testing the security of the SSL implementations of Australian banks, I decided to run the same tests on the South African banks, using SSL Lab’s SSL Server Test. I have a little bit of inside info into some of the banks systems, so was not too surprised how bad the results were.

None of the banks score an A (they all fail with Forward Secrecy), but pick of the bunch was Capitec, whose only only other failing was using a relatively weak signature.

FNB is limited to a B by accepting the weak RC4 cipher, and Nedbank adds supporting only older protocols to the list of failings.

You’d hope for better security from banks, but the failings of Capitec, FNB and Nedbank are not too serious. On to the others…

Absa has all of the above failings, does not support secure renegotiation, uses the obsolete SSL3, and most dismally of all, is vulnerable to the POODLE attack against TLS servers.

Although Standard Bank also gets an F, it stands alone in the number of criteria it failed. It uses the even more old and insecure SSL 2, supports insecure Diffie-Hellman (DH) key exchange parameters, supports 512-bit export suites and might be vulnerable to the FREAK attack as well as being vulnerable to POODLE.

It’s quite astounding that Standard Bank may still be still vulnerable to the FREAK attack, which has been known about for over two months, and which is extremely serious.

These results match the banks scores in other areas as well, such as bank fees and customer satisfaction. So Standard Bank clients will be happy to know they’re not only with the least secure bank, but also with the most expensive and the one with the worst customer service.

Related Posts:

• Standard Bank – not inspired, motivated and whatever the other one was
• Standard Bank and the Chinese crackdown
• Dear Standard Bank staff
• Spambank at it again
• FNB’s great new site

Recently I’ve seen quite a few postings of the article The Insidiousness of Facebook Messenger’s Mobile App Terms of Service , claiming you should remove your Facebook Messenger because of the control the app has over your Android device. Many have suggested Telegram instead, which I’ve been using a while. “Using”, I should add, in the same sense I would use a carrier pigeon. It’s nice to have, but there aren’t many others to share the fun with.

So how bad is the Facebook app compared to others? Here’s a comparison between the permissions demanded by Facebook Messenger, Telegram and Whatsapp on Android:

The permissions that have got most people worried, with visions of their phone starting to video them and record their conversations, “Take pictures and videos” and “Record audio”, are shared by all the apps. In Android’s permission system, they’re required to function. So if you want to use the chat functionality, you have to give the app these permissions. If the software is proprietary (Facebook and Whatsapp), you’ll need trust the company behind the app (Facebook owns Whatsapp as well). Telegram is open source, and therefore anyone can (and does) check the code. If you’re worried about security, you should be as concerned about what happens to your messages and data in transit, and here the best option I know of right now is Telegram, which is designed with a focus on privacy.

Now if only more people would use it…

This weekend I did some unseasonal spring cleaning. I closed down my chess website, my rugby website, the Wikipedia template translation tool, the free and open source feeds list, and some now rather dated software that I hosted.

So, if you’ve been redirected here looking for any of those, sorry to disappoint you! It’s time to simplify and none of the projects were particularly active or interesting anymore, so it was time to so some tidying.

This blog gets about 1 spam comment a second.

Not bad for an obscure blog with, as I write this, only one post open for comments.

Akismet, the spam plugin does a great job of keeping the spam out, although recently a few more spam posts have been sneaking through for moderation, perhaps two a week. Still considering I get about 600 000 spam comments in that week, a miss ratio of 1 in 300 000 is rather exceptional.

The volume of spam shot up markedly after this post, which in retrospect, isn’t so surprising, since it contains every about spam phrase out there.

A feature I’d like to see in WordPress is the ability to automatically delete spam after a certain period. Apparently this is automatically set to one month, but since in that month I’d get about 2.5 million posts, and have to up the space on my backup server, I prefer to delete spam posts manually a little more often than that.

Deleting spam posts isn’t entirely smooth. If the number is too large, the script times out and I have to re-run a number of times. Since the spam arrives so quickly, I never have an empty spam folder, as by the time the deletion has happened, but before the page reloads, there’s normally a couple more posts.

After coming back from the weekend to 40 000 spam posts, I decided to look for a solution. It’d be easy enough to adjust the period in the code manually, but since I’d have to re-implement the change each time I upgraded, I prefer to look for an existing solution.

Enter Cookies for Comments. The solution is simple – the plugin sets a random cookie, which, if it doesn’t exist when a comment is posted, is almost a sure sign that the comment is being placed by a bot.

You can set the plugin to either automatically mark the comment as spam (effectively catching the two or so comments a week Akismet misses, but not solving my problem), or automatically delete the comment.

I set it automatically delete comments. Boom! Blissful silence with my recently-cleared spam folder now not moving from 247 comments.

You can play further and use an Apache rewrite rule to block the requests from even reaching WordPress, which I haven’t implemented yet, but looks hopeful in reducing unnecessary load further.

What’s that? You’re suspicious of cookies and have disabled them, and now you can’t comment on my blog? I doubt you can do much else on the internet either…

Related posts:

• You like my blog?
• An attractive honeypot
• Defeat
• Cleaning up spam referers in b2evolution

I’ve noticed that each time I’ve visited IOL recently my browser takes a noticeable performance knock. Trying to browse it by opening lots of tabs, as I do with most sites I visit, is out of the question, and it’s probably the worst-performing site I have visited recently.

I decided to run speed tests of the major South African news sites, and a few well-known international ones, to see how the performance shapes up.

I ran Yslow, which, along with Google’s PageSpeed alternative, is one of the more well-known speed tests. YSlow is a Firebug addon, both addons for Mozilla Firefox.

Here are the results. Higher scores are better – I only visited the front pages of each.

It’s no surprise that IOL comes in last, close behind the nearly-as-clunky News24, while at the other end of the scale, the Daily Maverick comes top, closely followed by the Mail & Guardian. The South African news websites are generally slower than the most popular international alternatives, ironic in a country with relatively slow and expensive bandwidth. Although Facebook and Twitter aren’t news sites, I’ve added them as two of the most popular sites for comparison. Twitter is unsurprisingly light, with it’s minimal interface, but Facebook comes out well, probably due to the hefty resources it devotes. It can by no means be called a light site, and the front page is filled with content, but it performs far better that any of the local sites.

With my regularly updated blog jam-packed full of brilliant content, naturally it receives more compliments than Lady Gaga’s Twitter account.

Happy New Year by the way. And Christmas.

One fan went a bit overboard, submitting what seems to be every one of the compliments spammers regularly use to deceiver bloggers. Here’s the heartfelt comment:

Thanks for ones marvelous posting! I truly enjoyed reading it, you can be a great author.
I will be sure to bookmark your blog and definitely will come back in the future.

I’ll check back later and see if the problem still exists.
Hi there! I’m at work browsing your blog from my new iphone!
Just wanted to say I love reading through your blog and look forward to all your posts!
Keep up the fantastic work!
Wow that was strange. I just wrote an very long comment but after I clicked submit my comment didn’t appear. Grrrr… well I’m not writing all that over again.
Anyhow, just wanted to say fantastic blog!

Recently, the server hosting the Ethical Co-op website died, and needed to be replaced. It launched in 2005, running on a standard LAMP system.

Since it was written in the days of PHP4, and was working well, I’d never upgraded it to PHP5. Everything was running smoothly on PHP4, but this had reached end of life, and running PHP4 on the server was proving more and more of an obstacle when trying to install other, newer code.

So, when the server died late on Saturday night, and with the weekend usually being a very quiet time, I decided to use the opportunity to finally move to PHP5.

The server has needed to be replaced or reinstalled perhaps three times since 2005. I’m not a natural system administrator – I have a programming and database background, and have never done system administration professionally, so the first few times were a bit shaky. However, I’ve improved as I’ve gone along, and the installation went very smoothly this time.

I have everything carefully documented. There are a lot of tweaks to the vanilla system, various extra PEAR libraries installed, and all are carefully documented, so setting up from scratch is a breeze.

I upgraded the code from PHP4 to PHP5 which (considering my coding style carefully honed from its roots in ZX-81 BASIC) was trivial. Everything was back in good time by the end of the weekend, my tests reported no problems, and I went to bed.

Monday the problem reports started.

It didn’t take long to identify the problem. POST variables were being chopped off. Consistently nothing more than around product 200 was being returned. I’d never encountered a problem like this before, but after Googling I identified a culprit. Suhosin, the Hardened PHP project, has a post.max_vars setting which defaults to 200. A quick look at my config and I see This server is protected with the Suhosin Patch.

A perfect fit. This must be the cause of the problem!

Cursing the paranoid security, I spent much of the day investigating Suhosin. A Twitter search returned “Fuck Suhosin!” as the first result, making me more sure I’d identified the culprit.

None of the Suhosin settings were appearing in my phpinfo() output, which apparently is normal behaviour for the defaults, and explicitly setting them in php.ini, which seemed to solve the problem for most people out there, had no effect.

The server by default had the Suhosin patch installed, and in my attempts to get come control over the configuration I installed the Extension, which finally gave me control.

At this point I realised my first mistake. There may have been 200 products, but each product has five variables, so the cutoff was actually happening at 1000, not at 200.

And so I made my second mistake. If suhosin.post.max_vars is by default set to 200, it couldn’t be the cause of the problem. Still, there was no way to know that the setting was 200 on my system, and in the default configuration file that appeared after I installed the extension, this line appeared

;suhosin.post.max_vars = 1000

Commented out, but indicative that the default was 1000, not 200 as the documentation indicated. By now I really was convinced that Suhosin was the spawn of all evil.

However, no matter what changes I made to these and other possible Suhosin settings, nothing made a difference.

Eventually I had to accept it wasn’t Suhosin, and I had wasted most of the day. It had been unclear to me from Suhosin’s documentation exactly the difference between the patch and extension was, and I had also been misled by some posts claiming that the patch was responsible for the POST var limit, when it appears after all it isn’t, and this is only implemented if the extension is installed.

By that stage there was such a mess from the day’s errors and the downtime that I was ready to cancel the week’s deliveries (the Ethical Co-op delivers once a week, with most of the orders arriving on Monday and Tuesday).

Bernhard of Meglakor had been helping me, and was much quicker than me to realise Suhosin was not the cause. I was convinced it was the cause; after all, it had seemed a perfect match, and it was the only thing I could find that limited POST variables.

But it wasn’t.

Earlier this year, PHP 5.3.9 was released. One of the minor changes made during that release was the following:

Added max_input_vars directive to prevent attacks based on hash collisions.

There it was! PHP now limits any input variables to 1000 by default! After all my worrying about upgrading the code, it was a minor configuration change in a minor version that caused all the problems.

A classic case of being led astray by mis-identifying the problem, and then being less open to alternatives because of the investment in the identification!

A simple change, and everything was working again.

Thanks Bernhard for clearing Suhosin’s name, and then identifying max_input_vars.

Related Posts:

• Is PHP following in Perl’s footsteps?
• The P in LAMP is booming in Cape Town