Impossible Dream

A student once told me, in all seriousness, that his password of “password” was secure because:

It’s a double bluff. No-one would believe I’m stupid enough to use that as a password

Yeah, right.

The trouble is that passwords are hard. One password is easy, two ok but most of us need tens, if not hundreds, of passwords for all our different services. Work password, personal email, facebook, Google, ebay, three banks, that random quiz site, phishme.com…. 

Then each of these sites will have a different password complexity/strength checker, work insists your password is changed every 30 days and on it goes.

In attempting to deal with this, most people work their way down this sequence:

1. I’ve thought of a good password. It’s “fred”.
2. Oh dear. It’s rejected as too short. Let’s try “fredfred”
3. Now it needs numbers. Try “fr3dfr3d”.
4. Accepted

And we’re all good to go until….

5. The next site comes along. Now we have to have a special character as well. So let’s use ‘fr3dfr3d!’. 
6. Now sign up to internet banking. Best use a different password. Ok. ‘G30rge!’. Done
7. Now what about the credit card? ebills? Oh dear.

The only way to deal with this and keep everything in a human brain is to have two or three basic passwords (say one for banking, one for login and one for other websites) and reuse them everywhere, with random variations to deal with different sites password policies. This way madness lies. The small variations cause endless problems and the sharing of password across sites means that one compromised site is a disaster.

The solution: write your passwords down. As prohibited in every security policy ever.

Use the paper, Luke

By ‘write it down’ I don’t suggest you physically write it down in any way, but rather than you stop trying to remember passwords and use a password manager to store them.

Password mangement (or “Password Safe”) software encrypts away all your passwords with one master password so that you now only have one password to remember, but your passwords are still safe from prying eyes. Unlike the ‘post-it-note under the keyboard’ approach.

Once you stop trying to remember passwords, all sorts of good things happen:

1. You can (and should) have a unique password for every single site or application. Even the silly ‘joke’ websites. Everything
2. You can stop trying to think up passwords. Just let the password manager generate a random one for you. It’ll be impossible to remember (e.g. mine has just generated ‘eRxz%b3gtV’ for me) but it doesn’t matter. You never need to remember it

And that’s it. Now you can have complex, unique passwords everywhere and also have less stuff cluttering up your brain and making you stupid. What’s not to like? Just do it.

The Details

That’s the basic principle, but like everything, the details matter.

1. You’ll still have to remember your login password and a master password for your password safe. That’s only two passwords. Not so bad
2. You may also want to remember your internet banking passwords.
3. Remember that the strength of this whole system depends on the strength of the master password you set for your password safe. Since you don’t have to type it very often I suggest just going for a very long phrase (30-50 characters).
4. Don’t use any random piece of software. Writing secure cryptographic products is hard and you want to be very sure that if you are putting all your passwords in one place that you haven’t just made it easy for them to be all stolen at once.

Finally, most of us use many different computers over the course of a day so need these passwords everywhere. There’s two basic approaches:

1. Let the software itself store the data in the cloud, or,
2. Store the encrypted file on a sync service like Dropbox

Either works. You’ll also want to have a copy of the program and your passwords on your phone for those times when you want to login into a site on a different computer/internet cafe etc. 

All of the recommended products below can be integrated into your web browser as well to allow for seemless logins to everything web based (which is going to be 95% of everything for most of us).

Recommended products

• KeePass: Works on Windows and Linux. Supposed to work on OS X but I gave up waiting for Mono to install. Also has version for most phone OSs. Open Source
• LastPass: nice, but costs to use on mobile. 
• 1Password: those that use it love it. Works on Windows, OS X, iOS and Android. Costs.

Edit: thanks to Max Spicer for prompting me to get off my arse, change my password management and actually write this up :) 

I’ve finally read the details in Travis Ormandy’s Sophail report. Oh dear.

Sophos’ response is a classic.

Tavis has questioned the performance of Sophos buffer overflow protection and made other statements questioning the quality of Sophos protection. Naturally Sophos is committed to continually improving performance and protection and regularly participates in independent third party tests. In fact, we consistently rank well in these tests.

Or, to translate:

We’re not going to comment on the details as they are too embarrassing and we don’t even come top compared to other a/v products

I highly recommend the full report. It’s a little less dry than the average security paper. e.g.

This guarantees that any attacker will simply give up writing their ret2libc payload, as they will be unable to concentrate due to uncontrollable laughter

Other gems include the packer protection being so out of date that it was hard to find an old enough version of the packer to test it and the pre-execution analysis that hard codes constants so it only really works on Windows Server 2003 SP1.

So what’s a defender to do? We knew already a targeted attack was likely to succeed. Sophos just makes it easier by allowing direct exploitation of the out-of-date embedded JavaScript engine.

Are other a/v engines better than Sophos? If so, which? And how could the average (enterprise) purchaser do a serious evaluation?

Over on Charlie Stross’ blog guest author Karl Schroeder introduces the concept of “wicked problems”. I recommend spending the time to read the whole article and the links in its first paragraph.

It’s not a concept I’d come across before:

But often, in the human sphere, there are what’re called “wicked” problems. In 1973, Horst Rittel and Melvin Webber defined a wicked problem this way:

1. There is no definitive formulation of a wicked problem (defining wicked problems is itself a wicked problem).
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not true-or-false, but better or worse.
4. There is no immediate and no ultimate test of a solution to a wicked problem.
5. Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial and error, every attempt counts significantly.
6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
7. Every wicked problem is essentially unique.
8. Every wicked problem can be considered to be a symptom of another problem.
9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem’s resolution.
10. The social planner who tackles a wicked problem has no right to be wrong (planners are liable for the consequences of the actions they generate).

The examples given are the obvious ones: fiscal policy, climate change etc, but it’s also a useful insight to bring to security problems. We can divide security issues into two groups (if not cleanly, then in a way that gains insight):

1. Non-wicked problems: does this patch crash my server? Does this exploit work? What’s the patch level of my server estate?
2. Wicked problems: how should we trade off privacy online for physical security?

Between these two, these a set of semi-wicked problems where much of the day-to-day difficulties in security policy come from e.g.

1. if we lock down all our client machines really hard, is that worth the trade off in innovation?

Problems in this class might not fit all the requirements above but will fit many of them E.g. 3, 9 and 10 seem very relevant here: often the person writing the security policy has no motivation other than to be as restrictive as possible, while the person doing the work wants to do the least possible.

A good counter when confronted with the more technological end of things.

Just in case anyone else gets this issue. The Samsung Galaxy S with Froyo can’t download apps bigger than 30Mb from the Market as /cache is only 30Mb. 

Here’s the fix:  get z4root, root phone, then use z4mod to change type of /data from rfs to ext2 (aka Lag Fix). You’ll want to do these anyway if you haven’t already lag fixed the phone.

Then in a terminal window:

mkdir /data/cache
umount /cache
mount -o rw,remount /
rmdir /cache
ln -s /cache /data/cache

Now install away from the Market.

To Undo

rm /cache
mkdir /cache
chmod 770 /cache

and reboot.

Important This fix will not persist across reboots and you will want revert this before rebooting. Once the app is installed it’ll run fine with /cache set back to normal

There was a wedding last week and it seems that lots and lots and lots of our users wanted to watch it…..

The graph below shows streaming video traffic for the last week. The time scale is a little confusing, but the low point of the traffic corresponds to the small hours of the morning.

Remember, this is on a 1Gb link. Since there is other traffic on the link, it’s fair to say that we’d have generated even more streaming traffic with a bigger link.

• iostat on Linux

Following the excellent guide from MNX Solution I’ve got two-factor auth working on my desktop.

There’s a couple of things I thought worth noting that aren’t mentioned there. 

1) You’ll need the pam headers installed and they aren’t by default.

$ sudo apt-get install libpam0g-dev

Then follow the instructions as given.

2) When you edit /etc/ssh/sshd_config you’ll need to set

RSAAuthentication no
PubkeyAuthentication no

to disable pub-key auth (at least for testing), since that will be tried before ChallengeResponse. For production use, enabling pub-key with a fallback to ChallengeResponse might be ideal.

There’s been plenty written on t’interwebs about the HBGary/Anonymous hack: ArsTechnica have the best write up on how it was done plus, using the hacked emails for details, some of the gory details on how HBGary wrote custom rootkits/backdoors for various US three-letter orgs. If you haven’t read the details of how it was done, do so. It’s both sophisticated (rainbow tables), cunning (social engineering) and aiming at low hanging fruit (a SQL injection on an externally facing website).

So what does this have do with with organisations in more mainstream fields? Well, after the UEA hack I was asked “Could this happen here?”. I’m sure the questioner was hoping for a reassuring “Of course not: we have a/v, firewalls, polices, procedures, dogs AND ponies. Nope, definately not”. But of course it could. 

HBGary brings that lesson into even sharper relief. This was a IT Security company, working on classified projects for the NSA. And they still got owned.

Now compare this to the situation in the average University:

• Q: Do we have any sql injection vulnerabilities? A: Not that I know of.

So far, so good. Now let’s keep going

• Q: Do you know which versions of applications are running for all externally facing servers? A: No

No, since in most older Universities, IT is decentralised and the centre doesn’t know exactly what the edges are doing or have any control over it except the big hammer marked “Firewall”. So…

• Q: How do you know you don’t have any SQL injection vulnerabilities in all the masses of custom code out there? A: Errrrr.

There’s no easy answer. It gets even worse in Universities where departmental IT can run up externally facing services with no oversight (*). Then we get to this situation:

• Q: Do we know how many webservers we have? A: Yes, Definitely. They all have to have holes in the firewall. Oh, except for those departments that have worked out mod_proxy. Oh.

 Still, like HBGary, we can rely on our security cleared, Infosec expert users. Can’t we? Did anyone mention students? Oh.

So what can we do?

One option is to lock down everything: remove autonomy from Departments, lock down the desktop, ban personal equipment etc. Which all seems good (and it’s what most auditors want) but it has the minor disadvantage for a research-led University of destroying research productivity, especially in fields where software is commonly written/modified/mashed together (e.g. most sciences, maths etc.) 

This leaves us with plan B. Segregate, firewall, least access. Don’t regard inside the outside as bad and the inside as good. It’s de-perimeterisation (as promoted by the Jericho group). It’s sometimes a hard sell, but it’s seems a very good match for the University environment. Which is ironic, since most of the founders of the Jericho group are banks :)

And if we’d reached this nirvana, would that make us immune to this type of attack? I know my answer.

(*) Of course, the centre never fecks up. Nope. Never.

• How debuggers work: Interesting series from Eli Bendersky on how debuggers work on Linux

Yesterday I went to Google User Group 2011 meetup in Loughborough. I was just about to start copying my notes in a more coherent form from yesterday, but Chris Sexton beat me to it 

Instead, here’s a dump of my notes in a pretty unstructed format. I’ve removed anything that Chris has already covered so you’ll want to read that blog as well.

General

• Google CloudConnect for MS Office to be released next week. Looks very nice. Allows storage of docs in Google Docs complete with versioning etc.
• Google Apps can do OCR on pdfs. I had no idea.
• There was a very nice demo of the translation facilities - live real-time translation in chat and demos of Google Sites being made available in any language via translation. They stressed it was machine translation so not perfect but good enough for people to understand.
• Nice ideas about using templates with Sites to give easy setups for projects etc
• Google also demoed the Chrome laptop. If we went with Apps this would be ideal for use as lending devices. Cheap, no local data, usable by anyone with a Google account. They are aiming for 99.99% uptime next year (including all downtime - any duration, planned + unplanned). No price or release date given.

The OU

• The OU are moving students to Google, but are still working through contractual issues with Google. In contrast, Sheffield ‘just signed it’ and didn’t get any legal look over at all. The OU reported a very low load on their help desk (~120 calls from first 10,000 users moved) almost all about privacy etc not the user experience. 270,000 students in total.
• Thinking about using Apps to store eportfolios via mashups. They mentioned that they found the google groups API not rich enough for their needs. No details were given, but they are working with Google to resolve this. Be good to have a chat with them about exactly what they had issues with.
• Looking at a Google Marketplace app called ( Aprigo Cloudlock ) to allow students to share files with examiners etc in a controlled way. Mentioned it might be a bit too pricy from them however.
• They are also looking at igoogle as a student homepage (the ‘P’ word wasn’t mentioned).

Misc

• bboogle looks interesting. It’s a open source Blackboard building block for Google integration http://projects.oscelot.org/gf/project/bboogle/