Robin Jones revisits the data security issue.
Readers may remember an article I wrote in VSJ for March 2008, in which I outlined a set of safeguards that might be employed to eliminate – or at least minimise – the steady drip of embarrassing revelations about the loss of sensitive Government-held personal data.
That article was, to all intents and purposes, a first draft for an IAP Panel presentation to the Civil Service Web site and (as you may have noticed) an extended version also appeared in the IAP Year Book. So that’s all right, then; problem solved. What’s that you say, Skippy? Records on all prisoners in the UK have gone walkabout? How can this be? After all we told them!
No, I don’t have delusions of adequacy. I wasn’t really expecting instant Government action to implement all our recommendations. (And, even as I write the last sentence, I hear that the disappearance of yet more prison data – this time containing personal details of prison officers – has been reported.)
So let’s start again. Actually, the prisoner data loss is instructive. We’re told that the data were encrypted before being passed to an external contractor. A member of staff there copied the data set to a USB memory stick, which was then lost. The data were being held, unencrypted, on the memory stick “for processing purposes”, the Home Office said. The quotation marks are mine. Their contents demonstrate a lack of understanding (if I’m being charitable) or a deliberate obfuscation (if I’m in cynic mode). “After all”, Joe Public might be expected to think, “you can’t manipulate encrypted data. So you’d have to decrypt the file to work on it.”
“Yes”, replies every reader of this magazine, “But only while the file is open. Any halfway decent encryption package would re-encrypt it as soon as it was closed.”
Which leads me to wonder if this is what happened. The data were indeed encrypted before transmission, using EFS under, say, Windows XP Pro. That was fine, because the receiving system was, like the sender, an NTFS volume. But (again, as every VSJ reader knows) if data encrypted this way are copied to a FAT volume, Windows helpfully decrypts them automatically and without warning the user what’s going on. And, of course, a USB stick is, by default, formatted as a FAT volume. That would account for the data having been unencrypted and, of course, has nothing to do with its being processed.
Now, that’s just my guess and it could be entirely wrong. But, even if it is, you would have to allow that something like it could easily happen. What’s more, we really can’t expect the average user to have the depth of knowledge necessary to avoid it. And that means that, for the foreseeable future, we simply can’t rely on Government – or businesses – to protect our personal data. As Sun’s Scott McNealy said, almost a decade ago, now, “You have zero privacy anyway. Get over it.” How, then, do individuals go about getting over it – that is, protecting themselves – as far as that’s possible?
Let’s think about a specific example. Suppose that your bank advises you that an employee has mislaid a file containing records, one of which is yours, whose fields are Family name, Given names, Address, Date of birth, Email address, Current account number and Current account balance as at 4 June 2008, for example. There’s likely to be a reference, somewhere in the file, to the bank in question, as well. We might start by asking, “Just how much otherwise unavailable information does this represent?” In other words, what does a criminal stealing these data get that he or she couldn’t have got elsewhere? Interestingly the answer is “Not much”. Your name and address are published in the Electoral Register. Your date of birth is at www.ancestry.co.uk although the miscreant will have to pay a small sum to find it. You lost control of your email address the first time you used it because you can’t know how well locked down the recipient’s machine is. Your current account balance is no use because you and your bank know the date for which that information is public. That just leaves your account number and the bank name itself. Getting the bank name feloniously isn’t a huge problem. At least two methods have been described. The first entails an attacking server trying to fetch a bank’s login URL through a target machine. The time taken to do this will depend on whether the URL is in the browser’s cache. The attacker can use a quick response to deduce that the target machine belongs to a customer of the bank. The second method is tidier. It uses the :visited CSS pseudo-class to compare a given bank login URL to the entries in the browser’s history. Either way, it would be prudent to assume that where you bank isn’t private information.
You’ll probably be pleased to learn that I haven’t found a legal way to elicit someone’s current account number. On the other hand, it’s not immediately useful. I don’t know of any bank that uses it as part of its on-line login sequence. And, in any case, it’s not exactly private. You release it to anybody to whom you write a cheque, from whom you receive electronically transferred funds or with whom you have a direct debit agreement.
So, to summarise, all this private information with which your bank has been so cavalier, isn’t. Private, that is. Which, in a cack-handed way, is good news, because it means that we should be behaving as though data such as these had been made public, whether we know that to be the case or not.
To see what that means, let’s examine how our mythical cyber-criminal is likely to try to use the information that’s fallen in his lap. He’s got your email address and your bank account number, so he could try a quite sophisticated spear phishing attack. That is, he can email you using a convincing layout, mimicking your bank logo and style. He quotes just the last four digits of your account number to give you confidence that he is ‘the bank’ and that they are taking your security seriously. There’s a link to the bank’s log-in page only, of course, it’s his version not theirs. He’s hoping you’ll try to log in and so reveal your passwords.
Or he could try another approach. The Achilles Heel of password-based systems is the password recovery mechanism. A user who forgets his password is usually required to provide a string of personal information to confirm his identity. If the system is happy, it will send the reminder to a prearranged email address. Of course, the attacker needs access to that too but the same procedure applies. And the necessary information can often be mined from blogs, CVs, social networking sites and so on. See www.sciam.com/article.cfm?id=anatomy-of-a-social-hack for a case study.
All this leads us to a list of dos and don’ts:
- Don’t use ‘real’ memorable material. If your birth certificate shows you as having been born in Birmingham, choose Handsworth or Sutton Coldfield. That’s close enough to keep it in your memory but impossible to guess so long as you can guarantee never to have said, “I was born in Handsworth”, because it isn’t true.
- Never assume that a correspondent is bona fide just because they have some information about you that can only have come from a legitimate source. Which, in the context of our example, means never click a link in an email.
- Choose passwords that are at once obscure and memorable. That’s easier than it sounds. Choose a base password for memorability, your wife’s name, Caroline, say. Now apply an algorithm to it. This might have several components. ‘All vowels are upper case and followed by a hash symbol’ would give cA#rO#lI#nE#. Now add that the first and last consonants are followed by the current month and year to give (for September 2008) c09A#rO#lI#n08E#. Why include date information? Because:
- Change your passwords regularly. For October, the above password becomes c10A#rO#lI#n08E# and you don’t have to remember anything new.
Now, I guess that most readers are muttering darkly that they do this sort of thing already. But I’m not targeting you. One of the IAP’s stated aims is to help members of the public seeking technical assistance. And everyone should understand how to protect themselves in this context. So we’re asking for your help in adding to the list above. Doubtless you’ve come across other examples of insecurity that you’ve developed wrinkles to solve. Let us know about them (eo@iap.org.uk). We’ll collate them and publish a full list for the general public in early 2009.
[Interesting project or development? Let us know at eo@iap.org.uk!]
