Instead Of Blogging…

Things I’ve been doing instead of blogging, this last month, include:

  • Code Week: hacking Three Rings code in a converted hay loft of a Derbyshire farm, as mentioned on the Three Rings blog.
  • Hoghton Tower: as is traditional at this time of year (see blog posts from 2010, 2009, 2005, 2003, for example), went to Preston for the Hoghton Tower concert and fireworks display, accompanied by Ruth, and my sister’s 22nd birthday. My other sister has more to say about it.
  • Family Picnic: Joining Ruth and JTA at Ruth’s annual family picnic, among her billions of second-cousins and third-aunts.
  • New Earthwarming: Having a mini housewarming on New Earth, where I live with Ruth, JTA, and Paul. A surprising number of people came from surprisingly far away, and it was fascinating to see some really interesting networking being done by a mixture of local people (from our various different “circles” down here) and distant guests.
  • Bodleian Staff Summer Party: Yet another reason to love my new employer! The drinks and the hog roast (well, roast vegetable sandwiches and falafel wraps for me, but still delicious) would have won me over by themselves. The band was just a bonus. The ice cream van that turned up and started dispensing free 99s: that was all just icing on the already-fabulous cake.
  • TeachMeet: Giving a 2-minute nanopresentation at the first Oxford Libraries TeachMeet, entitled Your Password Sucks. A copy of my presentation (now with annotations to make up for the fact that you can’t hear me talking over it) has been uploaded to the website.
  • New Earth Games Night: Like Geek Night, but with folks local to us, here, some of whom might have been put off by being called “Geeks”, in that strange way that people sometimes do. Also, hanging out with the Oxford On Board folks, who do similar things on Monday nights in the pub nearest my office.
  • Meeting Oxford Nightline: Oxford University’s Nightline is just about the only Nightline in the British Isles to not be using Three Rings, and they’re right on my doorstep, so I’ve been meeting up with some of their folks in order to try to work out why. Maybe, some day, I’ll actually understand the answer to that question.
  • Alton Towers & Camping: Ruth and I decided to celebrate the 4th anniversary of us getting together with a trip to Alton Towers, where their new ride, Thirteen, is really quite good (but don’t read up on it: it’s best enjoyed spoiler-free!), and a camping trip in the Lake District, with an exhausting but fulfilling trek to the summit of Glaramara.
Setting up camp at Stonethwaite.

That’s quite a lot of stuff, even aside from the usual work/volunteering/etc. stuff that goes on in my life, so it’s little wonder that I’ve neglected to blog about it all. Of course, there’s a guilt-inspired downside to this approach, and that’s that one feels compelled to not blog about anything else until finishing writing about the first neglected thing, and so the problem snowballs.

So this quick summary, above? That’s sort-of a declaration of blogger-bankruptcy on these topics, so I can finally stop thinking “Hmm, can’t blog about X until I’ve written about Code Week!”

×

Deliciously Silly Password Restrictions

After hearing about the recent purchase of social bookmarking service del.icio.us by Chad Hurley and Steve Chen, I remembered that once, long ago, I had a del.icio.us account. I decided to check if my account was still alive, so I trekked over to del.icio.us and took a look.

Delicious as it appears today.

The site’s changed quite a bit since I last used it. It took a while for me to remember what my password was (it was an old, old one, since before I started using passwords the right way). It also appeared that the site still knew me by my former name (it really had been a while since I last logged in!), so I updated it with my new name.

The next step was to change the password. I generated a random password:

#AOOZ*Qs9xsj6^bT@MtN4rq1!0FK&2

But when I went to change my password, it was rejected. Apparently it didn’t meet their security rules. What? That 30-character, randomly-generated password, containing uppercase letters, lowercase letters, numbers, punctuation, and special characters… isn’t secure enough?

A little investigation (and some experimentation) later, it turns out there’s a reason: my password must be insecure, because it contains my surname!

I have a single-character surname. That means that a 30-character password will (assuming a dictionary of 26 letters, 10 digits, and let’s say 20 special characters) have about a 40% chance of being rejected on the grounds that it contains my surname. The longer my password is, the more likely it is to be rejected as insecure. My experiments show that “abcdefghijklmnop” is considered by delicious to be more secure for my account password than, say, “@Ubj#JeqPACrgmSQKn9qRYMBM9nPOj”, on account of the fact that the latter contains my surname.

Silly, silly, silly.

After delicious finally died a death, I retroactively imported all my delicious bookmarks into this blog.

× ×

Bank Security

Having found by coincidence a (minor, perhaps exploitable as part of a more-complex attack) security problem with the website of a major high street bank, one would think it would be easier than it evidently is to get it reported and fixed. Several phone calls over a couple of days, and the threat of making a complaint about a representative if they didn’t escalate me to somebody who’d actually understand what I was explaining, I’ve finally managed to get the message through to somebody. How hard was that? Too hard.

If this still doesn’t work, what’s the next step? I’m thinking (1) change banks; (2) explain why to the bank; (3) explain why to the world. Seriously, I expect better from the people looking after my money.

And on that note: time for bed.

Edit: Meanwhile, we see that the PlayStation Network hack may have resulted in the theft of personal information from users’ accounts. While most of the media seems to be up in arms about the fact that this might have included credit card information, I’m most pissed-off about the fact that it might have included unencrypted passwords. Passwords should be stored using irreversible encryption: there’s no legitimate excuse not to do this, these days (the short version for the uninterested: there is a technique which can be used to store passwords encrypted in a pretty-much irreversible format, even if the hacker steals your entire computer: it’s very easy to do, protects against all kinds of collateral damage risks, and Sony evidently don’t do it). If any of Sony’s users use the same password for their email account, social network accounts, online banks, etc. (and many of them will, despite strong recommendations to the contrary), the hackers are probably already getting started with social hacking attempts against their friends, identity theft attacks, etc. Sony: you are a fail.

Passwords

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

This repost was published in hindsight, on 11 March 2019.

Fiona wrote:

I have been uneasy for a while about my passwords, but being dyslexic and a bit lazy there was not an obvious solution to make it more secure and not lock me out. The problem that I have is anything that requires memorising a string of letters numbers and symbols just does not work in my brain. I have over come this for my normal passwords by having a small number (around 5) and adding a new one every so often and losing an old one. I take two to three words that I can spell (not a very long list) and then change them with substitution of some letters for numbers. On one occasion I managed to get punctuation in there also. However, they are used in many sites, and are easily broken in to.

Following Dan’s post on passwords combined with a visit to Dan we started looking at other solutions and settled on last pass. This looked like a good option for us. I very carefully set up the account paying close attention to where it said make sure you remember your password. The first password I chose was tolerably strong, I had not used it before and it followed the proven pattern of how I remember passwords. When I typed it in to change something it would not work. Knowing that lastpass will not let me do anything if I cant remember my password I made a word doc changing each part of the password to see where I went wrong and trying it in the filed, fourth time lucky I got the password. I then realised that this was not going to work as the bit I got wrong was an inconstancy of treating one letter as a number. So I reset my password using the old copied password.

I texted myself my new password and copied it from my phone, checked that it worked with a second sign in. Then I continued to set up my sites for last pass to sign in. When Kit came home we decided it was best if I had to write out my new password as often as possible to get it in to my head, this did not work. And after 20 min of trying every combination I could think of the same way I had before I called Kit through to see if he had any ideas. In the end the only option was the delete account and start again option. So we hit show password on the screen and copied each password in to a word doc, then we shut down the account.

This morning I have set up a new last pass account, and because my dyslexia has not gone away over night I have a new stratagie. I use SuperGenPass to change a simple password in to a more complicated password and the resulting password is used to sign in to Last Pass. This might seem convoluted, but in a world where things that I can remember are so insecure that polite coughing will open them up to anyone who chooses it is one of the few options that give security and will allow me to access my own accounts.

Anyway, I have to now go and change all my passwords again as the were made insecure in the rescue mission, but this time I have confidence of it working.

Passwords – The Least You Should Do

If you see me in person, you’ll know that this is something I rant about from time to time. But that’s only because people consistently put themselves and their friends at risk, needlessly, and sometimes those friends include me. So let me be abundantly clear:

If you’re reading this, there is at least a 95% chance that your passwords aren’t good enough. You should fix them. Today.

Let’s talk about what what we mean by “good enough”. A good password needs to be:

  • Long. Some of you are still using passwords that are shorter than 8 characters. The length of a password is important because it reduces the risk of a robot “brute forcing” it. Suppose a robot can guess 1000 passwords a second, and your password uses only single-case letters and numbers. If you have a 4-character password, it’ll be lucky to last quarter of an hour. A 6-character password might last a week and a half. At 8-characters, it might last a few decades. Probably less, if your password makes one of the other mistakes, below. And the robots used by crackers are getting faster and faster, so the longer, the better. My shortest password is around 12 characters long, these days.
  • Complex. Remember how long an 8-character password lasts against a “brute force” attack? If you’re only using single-case letters, you’re reducing that by almost a third. Mix it up a bit! Use upper and lower case letters, and numbers, as standard. Consider using punctuation, too. There’s no legitimate reason for a website to demand that you don’t have a long and complex password, so if one does seem to have unreasonable requirements: write to the owners and threaten to take your business elsewhere if they don’t get with the times.
  • Random. If your password is, is based on, or contains a dictionary word (in any language), a name or brand name, a date, a number plate or (heaven forbid) a national insurance number, it’s not good enough. “Brute force” attacks like those described above are usually the second line of attack against properly-stored passwords: first, a robot will try every word, name or date that it can think of, with and without capitalisation and with numbers before and afterwards. Many will also try common phrases like “iloveyou” and “letmein”. WikiHow has a great suggestion about how to make “random” passwords that are easy to remember.
  • Unique. Here’s the one that people keep getting wrong, time and time again. You should never, never, use the same password for multiple different services (and you should be very wary of using the same password for different accounts on the same service). This is because if a malicious hacker manages to get your password for one site, they can now start breaking into your accounts on other sites. Some people try to get around this by keeping two or three “levels” of passwords, for low-, medium-, and high-security uses. But even if a hacker gets access to all of your “low” security sites, that is (these days, frequently) still a huge amount of data they have with which to commit an identity theft.The other big reason to make sure your passwords are unique is that it makes it safer to share them, if the need arises. Suppose that for some reason you need to share a password with somebody else: it’s far safer for everybody involved if the password you share with them works only for the service you wanted to give them access to. Every person you trust is one more person who might (accidentally) expose it to a hacker by writing it down.Even if you have to memorise a complex “master” password and keep in your wallet a list of random “suffixes” that you append to this master password, different for each site, that’s a huge step forwards. It’s also a very basic level of two-factor authentication: to log in to your Twitter account, for example, you need your master password (which is in your head), plus the Twitter suffix to the password (which is written down in your wallet).

There’s been a wave of attacks recently against users of social networking websites: an attacker will break into an insecure web forum to get people’s email addresses and password, and then will try to log in to their webmail accounts and into social networking sites (Facebook, Twitter, etc.) using those same credentials. When they get a “hit”, they’ll explore the identity of the victim, learning about their language patterns, who their friends are, and so on. Then they’ll send messages or start chats with their victim’s friends, claiming to be their victim, and claim some kind of crisis. They’ll often ask to borrow money that needs to be wired to them promptly. And then they’ll disappear.

In this interconnected world, it’s important that your passwords are good not only for your benefit, but for your friends too. So if you’re guilty of any of the “password crimes” above – if you have passwords that are short (under 8 characters), simple (don’t use a mixture of cases and include numbers), predictable (using dictionary words, names, dates, etc.: even if they include a number), or re-used (used in more than one place or for more than one site) – change your passwords today.

Here’s some resources to help you do it:

  • WikiHow’s guide to choosing secure passwords.
  • PCTools’ great random password generator.
  • The top 500 worst passwords of all time – if yours is in here, it’s probably already been compromised.
  • SuperGenPass – a very good way to use a strong, unique password for every website without having to remember multiple passwords. Free.
  • KeePass – a great way to use a strong, unique password for every site and service without having to remember multiple passwords. Free.
  • LastPass – another great way to use a strong, unique password for every site and service without having to remember multiple passwords. Free (or cheap, for the premium version).

Mobile One-Time-Passwords in Ruby

I recently came across the Mobile One-Time-Passwords project, which aims to make a free, secure alternative to commercial two-factor authentication systems (like SecurID). The thinking is pretty simple: virtually everybody now carries a mobile phone capable of running basic applications, so there’s no reason that such an application couldn’t provide the processing power to generate one-time-passwords based on a shared secret, a PIN number known only to the authenticating party and to the server, and the current date and time stamp.
Great! But it turns out that despite there being libraries to produce server-side implementations of the technology in PHP, Perl, and C, nobody had yet bothered to write one in that most marvelous of programming languages, Ruby.

Well, now I have. So if anybody’s got the urge to add one-time-password based security to their Rails or Sinatra app, or would like to write an MOTP client for their Ruby-capable smartphone: well, now you can.

Copy-Pasting Passwords into Steam

Just want to know how to ‘fix’ Steam’s password field? Scroll down to “How to Fix It”

Steam & Security Theatre

You’re a smart guy. You’re not stupid about computer security. And that’s why you always make sure that you use a different password for every service you use, right? You might even use a different password for every account, even when you have different passwords on the same service. You know that there are really, really good reasons why it’s simply not good enough to, for example, have “high-security”, “general use” and “low security” passwords, and re-use each of them in several places. And if you don’t know that: well, take my word for it and I’ll explain it in detail later.

It’s no great hardship to have lots of long, complex, effectively-random passwords, these days. Tools like SuperGenPass, LastPass, and KeePass, among others, mean that nowadays it’s so easy to use a different password for every service that there’s no excuse not to. So you probably use one of those (or something similar), and everything’s great.
Except for that one application – Steam. I have Steam save my password on my desktop PC (by the time somebody steals my desktop PC and breaks into the encrypted partition on which my data files lie, I have bigger problems than somebody stealing my Just Cause 2 achievements), but it forgets the password every time that Ruth uses her Steam account on my computer. No problem, I think: I can easily copy-paste it from my password manager… nope: Steam won’t let you paste in to the password field.

What? If you ask Valve (Steam’s creators) about this, they’ll say that it’s a security feature, but that’s bullshit: it’s security theatre, at best. And at worst, it means that people like me are inclined to use less-secure passwords because it’s harder to memorize and to type out that a more-secure password would be.

How to Fix It

Well, obviously the best way to fix it would be to successfully persuade Valve that they’re being stupid: others are already trying that. But what would be nice in the meantime would be a workaround. So here is is:

  1. Edit Program FilesSteamPublicSteamLoginDialog.res (Program FilesSteamPublicSteamLoginDialog.res on 64-bit Windows, somewhere else entirely on a Mac) using your favourite text editor (or Notepad if you don’t have a favourite). Take a backup of the file if you’re worried you’ll break it.
  2. In the "PasswordEdit" section (starting at about line 42), you’ll see name/value pairs. Make sure that the following values are set thusly:
  • "tabPosition" "1"
  • "textHidden" "0"
  • style="TextEntry"

The next time you load Steam, you’ll be able to paste passwords into the password field. The passwords won’t be masked (i.e. you’ll see the actual passwords, rather than asterisks), but the dialog never loads with a password pre-populated anyway, so as long as you make sure that nobody’s looking over your shoulder while you type, you’re set!

Update: let’s face it, Valve’s security policies suck in other ways, too. Please read the tale of a friend-of-a-friend who’s desperate to change her Steam username.

The Worst Server Infection I’ve Ever Seen

With my day job at SmartData I’ve recently been doing some work for a client, transporting their data from the Microsoft SQL Server that back-ends their desktop application and converting it to a different schema on a different database for a new, web-based application. Because there’s quite a lot of data, the schema are quite different, and the data needs to be converted in a “smart” way: I’ve written a program to help with the task.

My program takes data from our client’s old server and moves it to their new server, making several alterations along the way.

Unfortunately, it’s  a slow process to move all of the data over. So, to test my program as I continue to develop it, I thought it might be useful if I could take a copy of the “live” database to somewhere more local (like my computer). This would remove the overhead of going through the Internet each time, and reduce the run time of the program significantly – an important consideration during its ongoing development.

Unfortunately, a quirk in the way that Microsoft SQL Server works is that the backup file I can make (ready to restore onto my computer) doesn’t appear on my computer, but appears on the old server. And I don’t have a means to get files off  the old server. Or do I? I have a username and password: I wonder if there are any other services running on the server to which I might have access. To find out, I use a program called Nmap to try to get a picture of what services are running on the server.

The results of running Nmap on the server. That’s a lot of open ports…

And that’s when I realised that something might be wrong. For those of you who aren’t inclined toward understanding the ins and outs of network security, the screenshot above should be considered to be more than a little alarming. There’s pretty obvious and clear signs that this computer is infected with Trinoo, NetBus, Back Orifice, and quite probably other malware. It’s almost certainly being used as part of denial of service attacks against other computers, and could well be stealing confidential information from our client’s server and the other computers on their network.

How have things gotten so out of control? I’m not sure. I’ve never seen such a rampant runaway set of infections on a server system before. Computers belonging to individuals, especially individuals inclined to installing BonziBuddy, Smiley Central/Cursor Mania, and so on, are often littered with malware, but one would hope that a server administrator might have a little more wisdom than to let unauthorised code run on a server for which they were responsible. At the very least, a Windows-based, Internet-accessible server ought to be running a strict firewall and antivirus software (virtually all antivirus software would have detected all three of the infections I’ve named above).

Just about  anybody can get onto the ‘net, these days, and I can just about forgive a regular Jo who says says, “I don’t know anything about computers; I just want to play FarmVille.” It’s disappointing when they end up inadvertently helping to send email advertising “$oft C1ALIS tabs” to the rest of us, and it’s upsetting when they get their credit card details stolen by a Nigerian, but it’s not so much their fault as the fault of the complexities they’re expected to understand in order to protect their new computer. But when somebody’s running a service (as our client is paying for, from a third-party company who’s “managing” their server for them), I’d really expect better.

The Bit for the “Regular Jo”

And if you are a “regular Jo” on a Windows PC and you care enough to want to check that you’re part of the solution and not part  of the problem, then you might be interested in a variety of free, trusted:

  • Anti-virus software (essential)
  • Adware/spyware removal tools (useful if you routinely install crap downloaded from the web), and
  • Firewall software (essential if you connect “directly” to the Internet, rather than via a “router”, or if you’re ever on networks on which you can’t trust the other network users – e.g. free wi-fi access points, shared Internet connections in student houses, etc.)

Edit: And don’t forget to regularly install your Windows Updates. Thanks to Gareth for the reminder that regular Jos should be encouraged to do this, too.

× ×

SuperGenPass In MicroB On The Nokia N900/Maemo

In the unlikely event that I’m not the only person who uses SuperGenPass to manage my passwords and MicroB on Maemo on my Nokia N900, here’s a few tips that I thought I’d share (they’re also valid on the N800 and N810 and “hacker edition” N770s, too, I expect):

  • You don’t have a Bookmarks Toolbar (where would you put it on a 3½ inch screen?), so once you’ve customised your SuperGenPass bookmarklet, you’ll need to click-and-hold on the generated link, and then select “Add bookmark” to save it to your bookmarks).
  • Use it as normal: either fill your master password into the form and click your Bookmarks menu and select the bookmarklet, or select the bookmarklet and give it your master password. Don’t forget when using complex forms or changing passwords that Maemo provides a full clipboard so you can copy/paste passwords around where the need arises (thankfully quite rarely).
  • If you’re irritated by the “You have requested an encrypted page that contains some unencrypted information” warnings that you see when logging into SSL-secured websites (and the fact that unlike desktop Firefox, you can’t turn it off from the settings), here’s how you disable it:
    • Enter the web address – about:config
    • Agree to the warning page, if you’re presented with one
    • Type “security.warn_viewing_mixed” into the search box, or browse the properties list for that option
    • Select it by clicking on it, and tap the Enter key to toggle it from true to false.
  • I don’t yet know the reason for the fleeting “Maximum number of characters reached” message, but it doesn’t seem to impact on functionality of SuperGenPass. Does anybody else know what it’s about or how it can be suppressed?

HttpOnly Session Cookies using ActiveRecordStore in Rails 2.2

If you’re using CookieStore to manage sessions in your Ruby on Rails application, Rails 2.2 provides the great feature that you’re now able to use HTTPOnly cookies. These are a great benefit because, for compatible web browsers, they dramatically reduce the risk of a Cross Site Scripting (XSS) attack being able to be used to hijack your users’ sessions, which is particularly important on sites displaying user-generated content. You simply have to adjust your environment.rb file with something like:

config.action_controller.session = {
:session_key => ‘_session_id’,
:session_http_only => true,
:secret      => ‘your-secret’
}
config.action_controller.session_store = :cookie_store

Unfortunately, the Rails developers didn’t see fit to extend HTTPOnly cookies to those of us using ActiveRecordStore, where the XSS risk is still just as real. To fill this gap, I’ve produced a very simple and only slightly-hackish plugin which overrides the functionality of Rails’ CGI::Cookie to force all cookies produced by Rails to be HTTPOnly, regardless of the session store being used.

To use it, download this file and extract it into your application’s vendor/plugins directory, and restart your application server. You can test that it’s working using Tamper Data, FireCookie, or whatever your favourite cookie sniffing tool is.

SSL Client Certificate Authentication In Ruby On Rails

I’ve been playing with using client-side SSL certificates (installed into your web browser) as a means to authenticate against a Ruby on Rails-powered application. This subject is geeky and of limited interest even to the people who read this blog (with the possible exception of Ruth, who may find herself doing exactly this as part of her Masters dissertation), so rather than write about it all here, I’ve written a howto/article: SSL Client Certificate Authentication In Ruby On Rails. If you’re at all interested in the topic, you’re welcome to have a read and give me any feedback.

LiveJournal Needs To Tighten Security

Hmm… as part of my ongoing work with Abnib v3.0, I’ve noticed a couple of interesting little quirks in the way that LiveJournal handles security for “friends only” and “private” posts. In fact, I’m pretty sure I’ve found a way to – for any given user – produce a list of the times, dates, and URLs of all posts made by anybody – even ones to which I don’t have access. Not terribly disturbing news, as I still can’t get access to the content of the posts or even the comments to them, but it’s an “opening” – a “way in” – which could potentially lead to a full-blown exploit.

For example, I can tell you that there is a post on Andy’s blog that I’m not allowed to read, that he wrote on the 17th of Januaryat about quarter past four in the afternoon (I hope you don’t mind me using you as my “guinea pig”, Andy – you’re the first person I came to who had a “recent” private post).

The numbers near the end of LiveJournal post URLs are supposed to be semi-random to prevent people from just “guessing” their way to posts, but it turns out this isn’t necessary. I’ve e-mailed LiveJournal to try to explain their flaw to them, but as I can’t be arsed to debug it myself (hey: not my weblog at risk, here), I don’t know yet how much of a priority they’ll make it.

Ho hum.

Edit: Further investigations have revealed that I can easily get the title (but not the content or the comments) of any LiveJournal post, including protected ones. For obvious reasons, I’ve now stopped using my friends’ weblogs as testbeds, and I’ve set up a couple of “play” accounts to try things out with. I wonder if I can get the content of posts? That’d be an interesting challenge.

scan.co.uk

This is a reply to a post published elsewhere. Its content might be duplicated as a traditional comment at the original source.

Ruth wrote:

We are in the process of ordering a new computer. Most of the bits are coming from Scan. Now, their range is lovely, and their postage policy is reasonably sensible, but they have a dumb policy on debit cards.

If you pay with a debit card (instead of a credit card), you can only have the goods delivered to your registered home address. Now, that might seem ok, because where else are you going to want stuff delivered, right? Wrong. You might want thehardware delivered to your place of work because you’re never home during the day. It might be something your buying for a technologically inept relative and you might want it to go to their home, not yours.

Or, like me, you might be a lazy student who uses their mother’s address in far-off North Yorkshire as their home address so they don’t have to change it twice a year.

Things like this which penalise people who don’t use credit cards make me cross. If anyone knows otherwise, please say, but to me it seems that it’s all just a big conspiracy by the banks to make us all use a really, really inferior product.

Anyway. Out of a desire not to have the computer bits go to Yorkshire, we’ve given the money to Dan who’ll be placing the prder with his credit card and getting it sent to our new house in PJM.
—-
On the subject of the post, my mother called me last night to ask for my new address so she could re-direct some letters from the university. So the items in question will have travelled from the campus to PJM (that is, over the road) via North Yorkshire. How very, very silly.

Anyhoo folks, I’ve got to go to work. Oh yeah, and house-warming party tonight, number 72 PJM. Punch and cake provided; if you want anything else, bring it with you.

Forcing people to have deliveries sent to their registered address cuts down on card fraud, which is moderately freqent at mail order computer hardware stores on account of the high value, discreetness, and availability of the goods. It’s not possible to accurately perform such checks on credit cards, but it’s easy to with debit cards.

Many banks give special dispensation on their student accounts; allowing them to – for example – submit two addresses which they will automatically switch between throughout the year – or allow two registered addresses to function for card checks (while still delivering the statements to one). Ask your bank if they can do this, and, if they can’t, write a letter to inform them that there are banks that can. If you’re not willing to let your feet do the talking, there’s no way to let these large organisations listen to you.

There’s no reason not to own a credit card unless you feel you cannot trust yourself to do so – or the banks won’t give you one! For many such cards, there is no interest if you pay them off immediately each month (which can be automated thanks to wonderful schemes like Direct Debit): this increases the flexibility of your purchasing power (particularly when purchasing from overseas) without costing you a penny. On a side note, owning one that you only ever use in this fashion increases your credit rating (which is checked when buying a contract mobile phone, getting a mortgage, applying for credit on a car, or whatever). Just for examples’ sake; if you owned an unused credit card, you could have ordered these computer parts and – odds are – immediately transferred the money from the bank account to the card, thereby giving you the bits sooner.

All of that said, I think I’ve quite aptly (and almost entirely) undermined the sense in preventing expensive goods being delivered only to the registered cardholder’s address, because as we’ve just seen there’s always a way to circumvent such checks by routing the money other ways: this leaves a longer paper-trail (banks and credit companies are, by law, required to keep better records for longer than companies that happen to process card transactions), but is otherwise a sensible way to commit fraud without triggering the little alarm bells that debit cards have hanging from them. So yeah; perhaps Scan should be a little less draconian.

Now Chip-And-PIN in the UK: there’s a flawed, insecure, badly-implemented system.