Opera 12 has been released, and brought with it a handful of new features. But there’s also been a feature removed – a little-known feature that allowed power users to have the
web address appear in the title bar of the browser. I guess that the development team decided that, because the title bar is rarely seen nowadays (the space in which a title once
occupied has for a long while now been used as a tab strip, in the style that Google Chrome and Mozilla Firefox eventually copied), this feature wasn’t needed.
But for users of the KeePass Password Safe, this has the knock-on effect of crippling
the ability for this security tool to automatically type passwords and other form data into web pages, forcing users to take the long-winded route of manually copy-pasting them each
time.
KeePass for Opera Plugin
To fix this problem, I’ve released the KeePass for Opera browser extension. It’s
ludicrously simple: it injects a bit of Javascript (originally by Jean François) into every page you visit, which then appends the URL of the page to the title bar. This allows
KeePass to detect what site you’re on, so the usual Global Auto-Type command (typically Left Ctrl + Alt + A) will work as normal.
[button link=”https://addons.opera.com/en-gb/extensions/details/keepass-auto-type/” align=”right” size=”medium” caption=”KeePass for Opera”]Install[/button]
The mobile app presents you with a special six-digit code that is used to withdraw the cash.
RBS Group this week
rolled out a service to all of
its customers, allowing them to withdraw cash from an ATM without using their bank card. The service is based upon the same technologies that’s used to provide emergency access to
cash by people who’ve had their cards stolen, but integrates directly into the mobile banking apps of the group’s constituent banks. I decided to give it a go.
The first step is to use the mobile app to request a withdrawal. There’s an icon for this, but it’s a bit of a mystery that it’s there unless you already know what you’re looking for.
You can’t make a request from online banking without using the mobile app, which seems to be an oversight (in case you can’t think of a reason that you’d want to do this, read on:
there’s one at the end). I opted to withdraw £50.
Next, it’s off to find a cash machine. I struck out, without my wallet, to try to find the nearest Royal Bank of Scotland, NatWest, or Tesco cashpoint. The mobile app features a GPS
tool to help you find these, although it didn’t seem to think that my local Tesco cashpoint existed, walking me on to a branch of NatWest.
The readout of the cash machine demonstrates that the roots of the “Get Cash” system lie in the older “Emergency Cash” feature: the two are functionally the same thing.
As instructed by the app, I pressed the Enter key on the keypad of the cash machine. This bypasses the usual “Insert card” prompt and asks, “Do you wish to carry out a
Get Cash or Emergency Cash transaction?” I pressed Yes.
The number displayed upon the screen is entered into the cash machine.
The ATM asked for the PIN I’d been given by the mobile app: a 6-digit code. Each code is only valid for a window of 3 hours and can only be used once.
The cash machine asks for the PIN a second time, and then asks for the sum of money to be withdrawn.
I’m not sure why, but the ATM asks that the PIN is confirmed by being entered a second time. This doesn’t make a lot of sense to me – if it was mistyped, it’d surely fail anyway (unless
I happened to guess another valid code, within its window), and I’d simply be able to try again. And if I were an attacker, trying to guess numbers, then there’s no difficulty in typing
the same number twice.
It’s possible that this is an attempt at human-tarpitting,
but that wouldn’t be the best way to do it. If the aim is to stop a hacker from attempting many codes in quick succession, simply imposing a delay would be far more effective (this is
commonplace with cash machines anyway: ever notice that you can’t put a card in right after the last transaction has finished?). Strange.
Finally, the ATM asks what value of cash was agreed to be withdrawn. I haven’t tried putting in an incorrect value, but I assume that it would refuse to dispense any cash if the wrong
number was entered – this is presumably a final check that you really are who you claim to be.
It feels strange taking money and a receipt from a cashpoint without first having to retrieve my card. I spent a few minutes after the experience with a feeling that I’d forgotten
something.
It worked. I got my money. The mobile app quickly updated to reflect the change to my balance and invalidated the code: the system was a success.
The banks claim that this will be useful for times that you’ve not got your card with you. Personally, I don’t think I ever take my phone outdoors without also taking my wallet with me,
so the chance of that it pretty slim. If my card were stolen, I’d be phoning the bank to cancel the card anyway, so it wouldn’t save me a call, either, if I needed emergency cash. But
there are a couple of situations in which I’d consider using this neat little feature:
If I was suspicious of a possible card-skimming device on a cash machine, but I needed to withdraw money and there wasn’t an un-tampered ATM in the vicinity. It’d be nice to know
that you can avoid having your card scanned by some kid with a skimmer just by using your phone to do the authentication rather than a valuable piece of plastic.
To send money to somebody else. Using this tool is cheaper than a money order and faster than a bank transfer: it’s an instantaneous way to get small sums of cash
directly into the hands of a distant friend. “Sure, I’ll lend you £50: just go to a cash machine and type in this code.” I’m not sure whether or not this is a legitimate
use of the service, but I can almost guarantee that it’ll be the most-popular. It’ll probably be reassuring to parents of teenagers, for example, who know that they can help their
offspring get a taxi home when they’ve got themselves stranded somewhere.
What do you think? If you’re with RBS, NatWest or Tesco, have you tried this new mobile banking feature? Do you think there’s mileage in it as an idea, or is it a solution in need of a
problem?
This blog post is about password security. If you don’t run a website and you just want to know what you should do to protect yourself, jump to the
end.
I’d like to tell you a story about a place called Internetland. Internetland is a little bit like the town or country that you live in, but there’s one really important difference: in
Internetland, everybody is afflicted with an unusual disorder called prosopagnosia, or “face-blindness”. This means that, no matter how hard they try, the inhabitants of Internetland
can’t recognise each other by looking at one another: it’s almost as if everybody was wearing masks, all the time.
Denied the ability to recognise one another on sight, the people of Internetland have to say out loud who they are when they want to be identified. As I’m sure you can imagine, it’d be
very easy for people to pretend to be one another, if they wanted. There are a few different ways that the inhabitants get around that problem, but the most-common way is that people
agree on and remember passwords to show that they really are who they claim to be.
Alice’s Antiques
Alice runs an antiques store in Internetland. She likes to be able to give each customer a personalised service, so she invites her visitors to identify themselves, if they like, when
they come up to the checkout. Having them on file means that she can contact them about special offers that might interest them, and she can keep a record of their address so that the
customer doesn’t have to tell her every time that they want a piece of furniture delivered to their house.
Some of Alice’s Antiques’ antiques.
One day, Bob came by. He found a nice desk and went to the checkout to pay for it.
“Hi,” said Alice, “Have you shopped here before?” Remember that even if he’d visited just yesterday, she wouldn’t remember him, so crippling is her face-blindness.
“No,” replied Bob, “First time.”
“Okay then,” Alice went on, “Would you like to check out ‘as a guest’, or would you like to set up an account so that I’ll remember you next time?”
Bob opted to set up an account: it’d only take a few minutes, Alice promised, and would allow him to check out faster in future. Alice gave Bob a form to fill in:
Bob filled in the form with his name, a password, and his address. He ticked the box to agree that Alice could send him a copy of her catalogue.
Alice took the form and put it into her filing cabinet.
The following week, Bob came by Alice’s Antiques again. When he got to the checkout, Alice again asked him if he’d shopped there before.
“Yes, I’ve been here before,” said Bob, “It’s me: Bob!”
Alice turned to her filing cabinet and pulled out Bob’s file. This might sound like a lot of work, but the people of Internetland are very fast at sorting through filing cabinets, and
can usually find what they’re looking for in less than a second. Alice found Bob’s file and, looking at it, challenged Bob to prove his identity:
“If you’re really Bob – tell me your password!”
“It’s swordfish1,” came the reply.
Alice checked the form and, sure, that was the password that Bob chose when he registered, so now she knew that it really was him. When he asked for a set of
chairs he’d found to be delivered, Alice was able to simply ask, “You want that delivered to 1 Fisherman’s Wharf, right?”, and Bob just nodded. Simple!
Evil Eve
That night, a burglar called Eve broke into Alice’s shop by picking the lock on the door (Alice never left money in the till, so she didn’t think it was worthwhile buying a very good
lock). Creeping through the shadows, Eve opened up the filing cabinet and copied out all of the information on all of the files. Then, she slipped back out, locking the door behind her.
Alice’s shop has CCTV – virtually all shops in Internetland do – but because it wasn’t obvious that there had been a break-in, Alice didn’t bother to check the recording.
Alice has CCTV, but she only checks the recording if it’s obvious that something has happened.
Now Eve has lots of names and passwords, so it’s easy for her to pretend to be other Internetlanders. You see: most people living in Internetland use the same password at most or all of
the places they visit. So Eve can go to any of the other shops that Bob buys from, or the clubs he’s part of, or even to his bank… and they’ll believe that she’s really him.
One of Eve’s favourite tricks is to impersonate her victim and send letters to their friends. Eve might pretend to be Bob, for example, and send a letter to his friend Charlie. The
letter might say that Bob’s short on cash, and ask if Charlie can lend him some: and if Charlie follows the instructions (after all, Charlie trusts Bob!), he’ll end up having his money
stolen by Eve! That dirty little rotter.
So it’s not just Bob who suffers for Alice’s break-in, but Charlie, too.
Bob Thinks He’s Clever
Bob thinks he’s cleverer than most people, though. Rather than use the same password everywhere he goes, he has three different passwords. The first one is his “really secure” one: it’s
a good password, and he’s proud of it. He only uses it when he talks to his bank, the tax man, and his credit card company – the stuff he thinks is really important. Then
he’s got a second password that he uses when he goes shopping, and for the clubs he joins. A third password, which he’s been using for years, he reserves for places that demand that he
chooses a password, but where he doesn’t expect to go back to: sometimes he joins in with Internetland debates and uses this password to identify himself.
Bob’s password list. Don’t tell anybody I showed you it: Bob’ll kill me.
Bob’s approach was cleverer than most of the inhabitants of Internetland, but it wasn’t as clever as he thought. Eve had gotten his medium-security password, and this was enough to
persuade the Post Office to let her read Bob’s mail. Once she was able to do this, she went on to tell Bob’s credit card company that Bob had forgotten his password, so they sent him a
new one… which she was able to read. She was then able to use this new password to tell the credit card company that Bob had moved house, and that he’d lost his card. The credit card
company promptly sent out a new card… to Eve’s address. Now Eve was able to steal all of Bob’s money. “Muhahaha!” chortled Eve, evilly.
But even if Bob hadn’t made the mistake of using his “medium-security” password at the Post Office, Eve could have tried a different approach: Eve would have pretended to be Alice, and
asked Bob for his password. Bob would of course have responded, saying “It’s ‘swordfish1’.”
Then Eve would have done something sneaky: she’d have lied and said that was wrong. Bob would be confused, but he’d probably just think to himself, “Oh, I must have given Alice a
different password.”
“It must be ‘haddock’, then,” Bob would say.
“Nope; wrong again,” Eve would say, all the while pretending to be Alice.
“Surely it’s not ‘h@mm3rHead!’, is it?” Bob would try, one last time. And now Eve would have all of Bob’s passwords, and Bob would just be left confused.
Good Versus Eve
What went wrong in Internetland this week? Well, a few things did:
Alice didn’t look after her filing cabinet
For starters, Alice should have realised that the value of the information in her filing cabinet was worth at least as much as money would be, to the right kind of burglar. It was easy
for her to be complacent, because it wasn’t her identity that was most at risk, but that of her customers. Alice should have planned her security in line with that realisation:
there’s no 100% certain way of stopping Eve from breaking in, but Alice should have done more to make it harder for Eve (a proper lock, and perhaps a separate, second lock on the filing
cabinet), and should have made it so that Eve’s break-in was likely to be noticed (perhaps skimming through the security tapes every morning, or installing motion sensors).
But the bigger mistake that Alice made was that she kept Bob’s password in a format that Eve could read. Alice knew perfectly well that Bob would probably be using the same password in
other places, and so to protect him she ought to have kept his password encrypted in a way that would make it virtually impossible for Eve to read it. This, in combination with an
effort to insist that her customers used good, strong passwords, could have completely foiled Eve’s efforts, even if she had managed to get past the locks and CCTV un-noticed.
Here in the real world: Some of Alice’s mistakes are not too dissimilar to the recently-publicised mistakes made by LinkedIn, eHarmony, and LastFM. While
these three giants did encrypt the passwords of their users, they did so inadequately (using mechanisms not designed for passwords, by using outdated
and insecure mechanisms, and by failing to protect stolen passwords from bulk-decryption). By the way: if you have an account with any
of these providers, you ought to change your password, and also change your password anywhere else that uses the same password… and if this includes your email, change it everywhere
else, too.
Bob should have used different passwords everywhere he went
Good passwords should be long (8 characters should be an absolute minimum, now, and Bob really ought to start leaning towards 12), complex (not based on a word in any dictionary, and
made of a mixture of numbers, letters, and other characters), and not related to you (dates of birth, names of children, and the like are way out). Bob had probably heard
all of that a hundred times.
But good passwords should also be unique. You shouldn’t ever use the same password in two different places. This was Bob’s mistake, and it’s the mistake of almost everybody
else in Internetland, too. What Bob probably didn’t know was that there are tools that could have helped him to have a different password for everybody he talked to, yet still
been easier than remembering the three passwords he already remembered.
Here in the real world: There are some really useful tools to help you, too. Here are some of them:
LastPass helps you generate secure passwords, then stores encrypted versions of them on the Internet so that you can get at them
from anywhere. After a short learning curve, it’s ludicrously easy to use. It’s free for most users, or there are advanced options for paid subscribers.
KeePass does a similar thing, but it’s open source. However, it doesn’t store your encrypted passwords online (which you might
consider to be an advantage), so you have to carry a pen drive around or use a plugin to add this functionality.
SuperGenPass provides a super-lightweight approach to web browser password generation/storing. It’s easy to understand and
makes it simple to generate different passwords for every site you use, without having to remember all of those different passwords!
One approach for folks who like to “roll their own” is simply to put a spreadsheet or a text file into a TrueCrypt (or
similar) encrypted volume, which you can carry around on your pendrive. Just decrypt and read, wherever you are.
Another “manual” approach is simply to use a “master password” everywhere, prefixed or suffixed with a (say) 4-5 character modifier, that you vary from site to site. Keep your
modifiers on a Post-It note in your wallet, and back it up by taking a picture of it with your mobile phone. So maybe your Skype suffix is “8Am2%”, so when you log into Skype you type
in your master password, plus that suffix. Easy enough that you can do it even without a computer, and secure enough for most people.
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!”
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.
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.
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.
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.
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).
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.
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:
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.
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.
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:
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.
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:
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?
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:
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.
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.
![Cash machine: "Do you wish to carry out a Get Cash or Emergency Cash transaction? [No] [Yes]"](/_q23u/2012/06/IMG_5833-300x200.jpg "Cash machine: \"Do you wish to carry out a Get Cash or Emergency Cash transaction? [No] [Yes]\"")
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.
