Category: Metal (Technical)

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.