Posts Tagged ‘security’

Virtual Backpack

Tuesday, April 6th, 2010

Virtual BackpackLast week I met with the company behind Virtual Backpack – a new service which offers safe, secure online storage of vital info such as passport details, national insurance numbers and medical history.

“Virtual Backpack is a stroke of genius…”

John Bird, founder of the Big Issue

The service is aimed at young homeless and vulnerable people, who run a high risk of losing such details (for example, due to theft or loss), although it could easily have wider applications. The service allows quick and easy access to these details, and also offers a platform for recording other personal details, previous addresses, work experience and useful contacts. Through integration with Microsoft’s Live Services, users can also access email, photo and document storage facilities.

“Virtual Backpack is a safe and secure place to store vital information and is a huge asset for any young person facing homelessness”

Lord Mayor of Birmingham

The potential of such a service is obvious, and although I can see a few possible issues, it’s a great idea. The developers are now hoping that local authorities will pay a licence fee to get access for their citizens, although I’d be interested to see a more centralised approach given the potentially transient nature of some of the target audience. Either way, this is a product to watch out for.

Hard lessons in social media: Online polls

Monday, October 26th, 2009
Biased results are a risk of online polls

Biased results are a risk of online polls

I’ve just updated my list of social media lessons learned the hard way with details of an online poll which appears to have backfired.

In summary, part of a multi-million pound advertising campaign by Christian charity Alpha International has potentially backfired when an online poll on their website, asking whether people believed in God, showed an abnormally high 98% saying ‘No’ (source: The Register).

More about how online polls can backfire

Back in business

Thursday, September 3rd, 2009

Some of you may have noticed that my blog and portfolio sites were down yesterday following an attack by hackers. I was delighted to find out today that the attack was actually on my host company, Namesco, rather than specific to me, and they have now restored all affected sites using recent backups. You can read a statement about the attack on their site.

Read more about the attack

Twitter adds account verification

Friday, June 12th, 2009

Just days after my post on the risks of cybersquatting in Social Media, Twitter have annouced that they are beta-testing account verification.

According to the official statement, to “prevent identity confusion, Twitter is experimenting with a ‘Verified Account’ feature [...] working to establish authenticity with people who deal with impersonation or identity confusion on a regular basis.”

A verified account

An example of a verified Twitter account

Read more about Twitter Account Verification

Cybersquatting 2.0 – protecting your name in Social Media

Monday, June 8th, 2009

The rise and rise of Social Networking Sites has brought about new risks to an organisation’s online brand, but whilst my last post explored Web 2.0 mistakes which organisation could make themselves, another type of risk is what others may do with your brand if you don’t get there first, through Social Media Cybersquatting. The risks of cybersquatters in a Web 2.0 world

Google Docs and security

Friday, April 3rd, 2009

A colleague recently asked me about Google Docs, wanting to know if it would be suitable to share documents within the organisation. She had heard that other Council’s were using it, and Google Docs certainly ticks many of the boxes:

  • Free and easy to set up
  • Possible to allow multiple users to access and contribute to documents
  • Available (not blocked by our corporate filters and excellent uptime)

But the major question I wanted an answer to was around security. As soon as information leaves our internal corporate network, there are security issues which need to be considered.
(more…)

The benefits of a false identity

Thursday, March 5th, 2009

I’m not saying that we should all be using false identities all the time, but my practice of occasionally giving a fake name, date of birth and address seems to have paid off.

The BBC today reports that Spotify has been hacked and users’ details stolen. When I signed up for the service a few weeks ago I was a little annoyed that they were insisting that I give them not only a name and e-mail address (probably fair enough) but also an address and date of birth. Why!? There is a premium account option, for which you must pay, so I understand why they need certain details for that. But if I’m just registering for the free account, they really don’t need these details.

So I did what I often do in these situations; I gave a false name (or just initials if the site accepts them), a false date of birth (I usually make a note of this for each account so that I can recall it if I ever need to) and a false postcode (taken from a famous landmark or nearby public building, and again noted down). True, this is probably in breach of most sites’ acceptable use terms, but then again letting hackers steal my details is against my ‘acceptable website behaviour’ terms.

Actually, the attack on Spotify occurred in late 2008, before I’d signed up, so I wouldn’t have been affected on this occasion. Nevertheless, I hate giving out personal details at the best of times, and especially when I can see no reason for it.

Lessons for the day

  • Website owners – always ask for the barest minimum of user details, where required, or at least make those details optional where possible. Then store them securely.
  • Website users – protect your personal details. The security of those details is only as good as the weakest site which holds them.

Survey Monkey useful features

Thursday, December 18th, 2008

I’ve been using Survey Monkey within my organisation for two months now (see my original post about its accessibility, which I’m still looking into). I must say I’ve been very impressed by the customer service – I’ve had a few questions which the (generally excellent) help section has been unable to help me with (mainly because contact with a person was necessary), and they’ve always been quick to respond.

I thought I’d mention a couple of things I’ve done since taking over the account. The lessons learned apply to any similar function, not just Survey Monkey.

SSL enabled

Firstly, I was surprised to see that the account did not have SSL enabled. This costs just $100 extra a year which, for a organisation such as mine, is peanuts. Compare that with the disasters that could await if not using a secure protocol and it’s a no-brainer. Sadly this only really came to my attention when I heard about a survey we’d run to gather parent’s opinions on school buildings. A local parent council blog had flagged up the potential security risk, and quite rightly so. We were asking for a few personal details, although to be fair these were not mandatory. Even so, those unaware of the difference between http and https may not have appreciated the risks (however small) and that’s not really on. Needless to say we’ve now upgraded, so people’s response are collected securely at their end and the results are downloaded securely at this end.

Friendly URLs

Secondly, a nice “courtesy feature”* is the ability to request friendly URLs. So instead of the usual string of alpha-numeric characters you can get something that actually makes sense (e.g. www.surveymonkey.com/mysurvey). This is really useful, especially if there’s a chance that people may need to type in the address, or if you want to refer to it in print. To underline the great customer service, I requested one to be set up and it took just a couple of hours.

Something to be aware of, if also using SSL, is that your users will need to include the https:// at the start of the URL. If they just type in from the www… they’ll get directed to the insecure version. Survey Monkey does not offer the ability to always redirect to the secure version, which they say is for the benefit of any systems that can not access the secure pages.

*Presumably a “courtesy feature” is something they’ll probably do, but aren’t obligated to. Hopefully, then, they’ll continue to offer this (and for free).

Loop to start

You’ve got various options for where to direct the user on completion of the survey (i.e. to a thank you page, another website, or even close the window). Another option, though, is to loop the user back to the start of the survey. This function has proved useful recently when we used Survey Monkey as the basis for an audit. Each auditor would typically be looking at 5 or more things, each requiring a unique response, so once one audit was complete they’d be going straight back into the survey to do another. The ‘loop to start’ function was, obviously, the perfect solution for this.

Invitations by e-mail

A tremendously useful feature is the ability to set up Survey Monkey to e-mail a list of recipients with an invitation to complete your survey. Each recipient gets a unique URL, enabling the system to track who has and hasn’t responded. This then means that you can easily send reminders targeted only at those who are yet to respond.

I thought it worth mentioning this function in the privacy statement that I am developing to accompany any surveys, and accordingly included this on the front page of the survey:

If you arrived at this survey via an e-mail invitation, it will be possible for us to link your answers with your e-mail address. Any information you provide will be kept secure and only used for evaluating the results of the survey.

Google Analytics – the risks of 3rd party script

Monday, November 24th, 2008

The Register has recently reported on the potential security vulnerability of using Google Analytics, and as we use this for various sites I thought it worth exploring a little further, especially as there are wider implications around linking to any third party javascript code.

The essence of the Register’s article, Google Analytics – Yes, it is a security risk, is that any third party javascript you include on your pages could open you up to vulnerabilities. You are essentially at the mercy of the owners of that code, trusting them not to do anything malicious. And there are plenty of things they could do, including stealing session cookies and form data, or even executing a ‘cross site script proxy’ attack, which could surrender control of a user’s login session.

So how big is the risk? There are a couple of factors to consider:

Firstly, how well can the script owner be trusted? A company such as Google can probably be trusted quite a bit, although we’re not just talking about the integrity of the company’s ethics. We also need to consider how seriously they take security themselves – how stringent are their own practices? Again, we can be fairly sure that Google is pretty hot on best security practices, so the risk is relatively low. The same might not be true of other third party sites.

Secondly, how big a target is your site? The case referred to in the Register’s story was Barrack Obama’s website. That site is obviously going to be a huge target for potential hackers, with security an immensely important subject. Sites with a lower profile can reasonably be assumed to be less of a target, although the risks can still not be discounted entirely.

In a recent forum post discussing this issue, the following advice was given:

if you must use external JScript, make sure it is a trusted source, and by trusted, I don’t just mean the company and their reputation, but also their own security practises, and do not under any circumstances link 3rd party JScript to a “secured” or sensitive area of a site

This seems to be pretty sensible, and is something we will need to consider from now on, not just in relation to Google Analytics, but when looking at linking to any third party script. Better safe than sorry…