Argh, Passwords!

In the last 24 hours I've received data breach notifications from two different companies I have accounts with - Apple and Canonical (the company behind Ubuntu Linux). Prior to those, I've had my data leaked from Sony, the ABC (Australian Broadcasting Corporation), and others. Even worse, these are just the organisations that have both realised they've lost data and been good enough to inform their customers about it. I have absolutely no doubt that my data has been leaked from other companies and they either don't realise or are too afraid to admit to it.

Usually the leaked info is "nothing more" than a username, email, and hashed password. How bad the situation depends on whether I've ever used that username/email/password combination on any other site.

I will admit to password reuse, at least in the past. And I bet if you're honest, you will too. Remembering passwords is a pain so the less you have to keep track of the better. I get that, but it's time to grow up.

We can talk all day about how bad passwords are as an authentication mechanism, and how everything will be fantastic just as soon as everyone starts using 2-factor auth and all the rest. That's all true, but it's not here today. What we're stuck with today is passwords and attackers who are able to discover them. We can accept that reality and deal with it or continue playing Russian Roulette with the really valuable data that's still secured by not much more than a password - the same one that's already been leaked.

Let's start with a simple assumption to guide our thinking: every site we have an account on will eventually be compromised and the attacker will learn our username/email and password. Maybe they'll only get a password hash, maybe plaintext.

With that in mind, we have two tactics available to protect ourselves. First, use long, complicated passwords for every site. Forget the idea of simple 'throwaway' passwords or any of that. Every password is long and complex, the end. My preference is 16 characters or longer using alphanumeric characters and symbols. Every additional character you add to a password dramatically increases the effort required to brute force it. So pick passwords that are completely impractical to precompute. If someone wants your password, make them work for it.

The second tactic is to never use the same password twice. When someone does finally compromise your wonderful 20+ character password, what leverage does it get them? None whatsoever. If they want your other passwords, they have to start from scratch. Unlucky for those guys.

Our third tactic (Suprprise! Bonus Tactics for the Win!) is to occasionally change our passwords. This one is our third tactic simply because I'm going to assume most people will never get around to it - that's why we're picking passwords that will take a few millennia (at current computation rates) to break. But hey, if you change your passwords every now and again it reduces the value of any hashes that do get leaked. That can't hurt - but we won't rely on it. We're only human after all.

So the plan is to have lots of really long passwords that in all honesty, we have no chance of remembering. How's that going to work? Using a password manager. I'm a big fan of 1Password by Agilebits, but there are plenty of other options. The general idea is to pick a single, high quality password that you will remember, and use that to encrypt the database of usernames and passwords for all of your sites. There's browser extensions baked in to make filling in login forms a snap. It's other great feature is the ability to generate passwords for when I need to sign up to a new site or change a password. I can specify length, character sets and whether I want the password to be pronounceable. It's pretty neat.

Moving to a password manager takes concentrated effort. Technically it's not hard, just different, and we all experience resistance when changing habits and workflow. Dropping in your throwaway password will always be there as a temptation. Resist! A small amount of effort on your part now will protect your interests in the long term, at least until something better than passwords comes along.

DNS amplification attacks back in the spotlight

US CERT re-issued today their March 29 2013 technical advisory reminding organisations to check their networks for open DNS resolvers, which can easily be used in a Distributed Denial of Service (DDoS) attack. See https://www.us-cert.gov/ncas/alerts/TA13-088A. An open DNS resolver is where the DNS server will accept and answer recursive DNS query requests from hosts that are not part of the IP address range under control of the organisation i.e. recursive DNS server functionality should be restricted to only those host IP addresses that belong to the enterprise or ISP.

Want to check if your DNS's are part of the purported 28 million open resolvers (as of May 2013 - see http://openresolverproject.org), then a useful tool is http://dns.measurement-factory.com/cgi-bin/openresolverquery.pl  If you are the technical contact for the IP address range as reported by whois then this tool will send you the current resolver status of your DNS's.

Another great resource is the  site www.dnsinspect.com. This site provides you with a detailed report on the status of your DNS. A great place to check on possible security vulnerabilities for your domain.

The CERT amplification reference cited above provides an excellence reference, however if you need up-skilling on aspects of DNS then please contact us. We do provide training in all aspects of DNS, IP, Deep Packet Analysis and Cyber Security.

LEGO and the IP packet header

At IIT Training we strive for an inclusive pedagogy. So, we are always looking at new and innovative ways to engage adult learners with complex technical matters in a fun way. One of our senior technical trainers, Geoff, has asked for buckets of lego for a new  hands-on session for our IPv4 and IPv6 courses. We thought it was for Open Systems Interconnection (OSI) model layering, but we were wrong, it was a whole lot better than that!....it was for the packet headers themselves, have a look what he'd come across: http://righteousit.wordpress.com/2010/06/27/practical-visual-three-dimensional-pedagogy-for-internet-protocol-packet-header-control-fields/