Simon on: App security

Ask any organiser whether they would mind a competitor getting hold of a full list of their registrants in order to promote a competing event and most would probably object. 

Yet, according to recent reports, that’s what’s happening at some events. In some cases, the organiser has apparently been told that it’s possible and has ignored the warning.

The situation has arisen because some conference apps (not all by any means) allow any user to download a full list of registrants, in some cases, along with all their personal information.

A competitor doesn’t even need to attend the event. All they do is download the app to get free access to the registrant database.

The fact that some organisers have been told that this is possible with their event app and have done nothing to prevent it suggests that they don’t care about the security of their data. 

Unfortunately this seems to be a common attitude these days. A recent conference session on Internet security attracted only a handful of delegates while another promoting the wonders of social media was a sell-out.

Perhaps it’s time for organisers to learn how to safeguard their assets before being swept up by the latest bandwagon.

Originally published in Conference News

Data security is a deadly serious issue

My recent blog post said that programmers who stored passwords in plain text should be beaten to death with a house brick. That caused someone to email me saying that they thought it was a bit extreme and that perhaps I should consider changing it.

So the first thing I'd like to say is that my comment was not meant to be taken literally but I seriously believe that was obvious. I did have a think about it and I believe the sentiment was justified as a way to highlight the seriousness of the situation and I'd like to explain why starting with some examples.

The first example is the British Pregnancy Advice Service. They have a website which amongst other functions, allows people wanting advice on pregnancy, abortion and contraception to request contact from the charity.

Unfortunately, the charity didn't manage their website development well and didn't know that their website was storing highly sensitive personal information about people who contacted them. Their website was also vulnerable to hacking and someone broke into the site and stole a lot of sensitive personal information.

The charity was fined £200,000 by the Information Commissioner's Office in the UK – something that will certainly hurt badly for them but it was less than the maximum possible fine of £500,000. The charity said they were "horrified at the scale of the fine" but the ICO's Deputy Commissioner said "ignorance is no excuse".

At this point I need to say that I have no idea whether there were unprotected passwords in the BPAS website but at the same time, most attacks by hacking exploit lazy or bad programming that doesn’t adequately protect the data in question.

Then there's the case of Cupid Media who operate a variety of dating sites. In 2013 they were hacked and 42 million user account details were stolen from their server. Sadly these details did include plain text passwords and unfortunately, many people regularly use the same password for every website meaning lots of other sites that they are registered with could also be hacked.

Rather disturbingly I also saw a website recently which had almost no security – the admin elements of the site could be reached if you knew the right URL with no login at all and this website stored both passwords AND credit card details in plain text. Honestly, this is probably the most scary example of bad programming I have EVER seen in my life.

Even the general standard of programming was truly shockingly bad. Unfortunately, the person who wrote that website allegedly does this stuff for a living but honestly shouldn’t.

My point is that if a programmer doesn't understand that storing passwords in plain text is one of the worst possible things they can do then there is realistically no chance that they will understand all of the other security threats or how to keep your data safe.

As the UK Government "Cyber Essentials" scheme puts it "Compromise of information assets
can damage companies" and I completely agree.

So when I said you should "beat them to death with a house brick" I was doing so purely for effect. Don’t do that – just fire them and get someone else!

How should passwords be stored on the internet

As I posted yesterday, eBay has been hacked and has lost a lot of data containing usernames and passwords and that got me thinking about how they're storing the passwords. 

In their post about what had happened they said "Because your password is encrypted (even we don't know what it is) we believe your eBay account is secure" and that puzzled me because encryption is a two way thing - if something is encrypted it can be decrypted (providing the relevant encryption keys and/or passphrase is available).

Now what they might have meant is "Because your password is salted and hashed" and that would explain why they don't know what it is but as a description to the general public - it probably means nothing.

So I thought it would be a good idea to explain what that means as it would help anyone who has a website that stores passwords understand what they should be doing.

Let's deal with hashing first. A hash is a "one way function" which means we can put a word through the hash and it will turn into something else but there is no way to reverse the hash and get the word back. Equally, a hash function will always output a fixed length string so it wouldn't matter how long your password is.

There are a few common hash functions by far the most common is MD5 so taking the dictionary word "password" and running it through an MD5 function will return 5f4dcc3b5aa765d61d8327deb882cf99 but changing the letter "p" to a capital so that we use "Password" gives us a totally different hash of dc647eb65e6711e155375218212b3964.

The problem here is that if I Google for either of those hashes I will immediately find a website that has a list of millions of MD5 hashes and they know which words caused that hash to be generated so as a security mechanism that's no good as a way to protect passwords.

This is where salts come in. A cryptographic salt is where we add some random data to the password we want to hash. Each password should have a different salt and that means that the resulting hash will be different. So, if we added the users first name to the password it might be that we then have "Simonpassword" and "Clarepassword" which would result in completely different hashes even if the two users had the same password.

By combining these two simple techniques it is possible to make passwords a lot safer even in the event that the database is compromised. I'd like to say at this point that we don't use the user's first name as a salt and we go quite a lot further in terms of protecting the passwords but this is the minimum that anyone should be doing.

So if you're talking to a web developer about your website that stores passwords you should ask them if it uses salted and hashed passwords. If they say "no, it stores the passwords in plain text" you should beat them to death with a house brick!

Simon on: M&IT - iBeacons

With so many gizmos and gadgets continuously hailed as the latest game-changer, it's hard to know what is useful and what is useless.

The most recent piece of tech to be crowned the golden egg of the meetings industry is iBeacons - but what's the truth? And more importantly, what are the benefits?

Find out by reading the whole article featured on M&IT, by clicking here.

eBay's hack highlights a short sighted password policy

For me, yesterday's big news was that yet another big website has fallen victim to hackers. This time it's eBay and so I dutifully logged in to change my password only to be confronted with a pathetic situation.

However I discovered that eBay's passwords can only be between 6 and 20 characters long. They don't tell you the upper limit any more but it's still there! 

This really annoys me massively because from a technical perspective, there's no reason they can't allow you to have any length password you want. The best current password advice is to use 4 unrelated words together as a password, allowing much longer passwords is dramatically safer and my passwords are routinely over 20 characters long.

eBay's page about the security breach says "We take security on eBay very seriously" and "our team is committed to making eBay as safe and secure as possible" - I'm thinking longer passwords would increase the security.

Simon on: Complaints on social media

A few people have argued against spending time on promoting conferences through social media because there is no evidence that it works. The difficulty lies in the claim that social media can be used to attract more delegates to attend a meeting.

It’s true that hobby events can generate huge activity. It’s also true that, in spite of determined efforts by some, this isn’t the case for professional conferences.

Look at the feeds for most conferences and they’ll be mainly made up of promotional posts from the organiser, notes from the organiser’s friends saying they’re excited to be going and posts from commercial organisations trying to get attendees to go to see them.

But one feature of social media is starting to play a role: it is increasingly becoming the first stop for anybody who wants to complain. 

And this is where a meeting planner can use it to advantage. If somebody is monitoring the feeds, these complaints can be spotted, acted upon and, most important, a response posted before the complaint gets out of hand.

The difficulty then becomes one of resisting the temptation to post a message reading ‘Did you bother to read the joining instructions?’. But that’s a different issue.

Originally published in Conference News