Archive for the ‘Uncategorized’ Category

Personal password security that actually works

I’ve been thinking a lot about password security recently. Not because I’m paranoid, but because I’m a geek, and geeks love to optimize their lives.

Passwords are interesting, because they’re absolutely essential in the 21st century world, and almost all of us are doing it wrong. I’m not even talking about the fact that 91% of people use the 1000 most common passwords. Savvier folks using common substitutions like “MyP4ssw0rd1” are vulnerable too. And don’t even get me started on how parents always choose their kids’ names as their password. (I’m looking at you, Mom!)

As pointed out in this Wired article, even strong passwords can be insecure, because all an attacker needs is access to your email, and then they can use password recovery systems to get everything else – bank accounts, photos, blogs, you name it. It’s a scary prospect.

However, I disagree with the author’s conclusion, that passwords themselves are inherently flawed. There is always a tension between security and accessibility, and his alternatives are too impractical to ever actually gain currency. (Have the web site snap a photo of me, email the photo to three friends, and then ask at least one of them to confirm my identity? Excuse my editorial laugh.)

The inherent vulnerability in most people’s password systems is just that they use the same password everywhere. Which is understandable, because unless you’ve got a superhuman memory, you can’t remember your user name and password for the dozens of sites you use on a regular basis. Hence the convention of providing your email address as your universal login, and using the same password everywhere, which gives an attacker who cracks any rinky-dink site immediate access to your email. And thus, everything.

Think about that for a second. When you sign up with, say, the Buffalo Youth Hockey Association, you give them your email and probably the same password to access that email. And then you do the same thing for dozens of other sites. Does that make you feel secure?

Buffalo Youth Hockey Association site.  Totally secure.

The Buffalo Youth Hockey Association. No doubt a fine organization, but what about all the other ones?

My solution

So here’s my method, which I think is a nice compromise between security and convenience. It’s based on Joel Spolsky’s approach, although I use GitHub instead of DropBox.

Essentially, I keep a PasswdSafe database file with one strong master password stored in GitHub, and my GitHub account is protected with another strong password. I don’t use either of these two passwords anywhere else, and I haven’t written them down or anything. They only exist in my head.

I sync the database file across my Linux laptop, MacBook, and Android phone using Git, and then I use PasswordGorilla and PasswdSafe for Android to read and edit the file. That way I can keep all my devices up to date as I add and change passwords.

My password file.

My password file.

All of my passwords are in this single file. I use a different password across each of the sites I commonly access (email, shopping, banking, etc.), and each one is a random 16-character alphanumeric string generated by PasswordGorilla. When I need a password, I just open PasswordGorilla, enter my master password, double-click the password I want to copy, and then paste it into the web site.

Of course, this creates a single point of failure, which may seem insecure at first glance. But let’s see what a potential attacker would actually have to do to gain access to these passwords.

Smart method (unlikely)

First off, an attacker would need to get their hands on my database file. And to do this, they’d have to hack into my GitHub account.

This is just basic password guessing, and although I’m using what I consider a strong password (based on the “correct horse battery staple” system), let’s assume for the sake of argument that the attacker manages to guess it, and that they manage to guess it before GitHub starts locking them out.

Now that they have my database file, they’d have to guess my second, equally strong master password. In this case, they won’t ever be locked out, and since the file is local, they can use whatever hardware they want. So a brute-force attack seems like a good approach.

But considering that PasswordGorilla uses key stretching, this means that a brute-force attacker would have to patiently wait one or two seconds to test each password in sequence. And according to HowSecureIsMyPassword, even a weak password like “MyPassword” would take 4 billion years to crack this way (assuming 1 calculation per second).

So even if our attacker somehow made it to my second gated entrance, it’s unlikely they would ever get past it.

Dumb method (more likely)

Unfortunately, the blind spot in all this is that there’s a much easier way for an attacker to get my passwords: just get my computer. An attacker doesn’t need access to my GitHub account if the files are already on all my laptops and smartphone. They just need to steal one of those devices.

As for the master password, once they have physical access to my computer, they can simply install a keylogger. Then, as soon as I type out my master password in PasswordGorilla, all my secrets are as good as cracked.

Permit me to postulate that this second scenario is much more likely than the first. It’s easy, it’s simple, and it doesn’t require much technical knowledge – only physical access to my devices.

Extra security measures

So in truth, the weakest link in this entire password system is just my devices themselves. Upon realizing this, I took some extra measures to ensure that my laptops and phone were sufficiently secured.

For my laptops, it was as easy as choosing a strong password and setting a timeout lock on the screensaver. OS X didn’t do this by default, but Ubuntu did.

As for my Android phone, I switched from a pattern-based lock screen to a pin-based lock screen. This is because, as we now know, patterns can easily be cracked by just holding a phone up to the light and looking at the smudges.

You may think it's safe, but your oily thumbs betray you.

You may think it’s safe, but your oily thumbs betray you.

I now use a 6-digit numeric code, with lock-out after 5 tries. At first, it was quite a bit slower than my pattern-based lock screen, but once I got used to it, I could punch in the code almost as fast as before. And now my phone is much more secure.

What’s the point?

At the end of the day, password security is only as important as the stuff you’re securing. Unlike the author of the Wired article above, I’m a pretty unknown small-time developer, so my WordPress and Twitter accounts are not terribly interesting. And as a fresh-out-of-debt college grad, there’s not a whole lot in my bank accounts, either. So my convoluted security system is protecting a largely empty treasure chest.

But passwords are essential to Internet services, and increasingly our lives are lived online in the cloud. In twenty years, I can’t imagine how many hundreds more passwords I’ll have, and what kinds of stuff they’ll be protecting. The habits I build now could really help me out in the future.

Plus, I find that my new system is actually easier to use than the old one. How could I remember whether my user name was “nlawson” or “nolanlawson” or “NolanLawson” on all the forums where I was signed up? I’d inevitably have to try a few different combinations, or use the password recovery system, which took time.

Now I just open up PasswordGorilla, double-click, and paste. Nothing could be simpler. This is a system that even Mom could use. (And you should, Mom!)

Most importantly, now I can sleep soundly knowing that I’ve done the utmost to protect my online identity. Because I would hate to imagine that my account at the Buffalo Youth Hockey Association could ever compromise my account at the bank.

Note: sorry to pick on Buffalo hockey fans. You guys are all right.

Make your workplace more fun with a Jenkins alarm system

At every development team I’ve worked with, we’ve used Jenkins to notify us when the build broke. (Or Hudson, as it was called before Kohsuke Kawaguchi nailed a proclamation to the church wall.) Everyone on the team would receive an email when a unit test failed, or when someone forgot to commit a file, or when some other random blunder occurred.

Jenkins is really invaluable for finding problems early. And of course, publicly shaming the guilty party is always a great source of fun. The Continuous Integration Game plugin is even better for this.

But at my current employer, my colleague Alexandre Masselot had a singularly brilliant idea: instead of just firing off an email, why not add a visual cue as well? So he set up a physical flag system, attached to a USB servo device, with a cron script that would raise the flag whenever a Jenkins build failed. It looked like this:

Everyone on the dev team loved it. If the flag was raised when we walked into the office in the morning, the first question at the scrum meeting would be, “Who broke the build?” And as soon as the flag started to rise, you could hear the servo cranking, and the guilty developer would announce, “That was me!” A good time was had by all.

But could we do better?

The developers on the far side of the room couldn’t always hear the cranking sound, so they often didn’t notice when the flag was raised. So we decided to add an audio cue as well. Every time the build was broken, the machine would play the Star Wars “Imperial March” (aka Darth Vader’s theme), using the Unix beep command, since this particular machine had no speakers. It sounded like this:

And every time the build was fixed, it would play the main theme of Star Wars, to celebrate the joyous occasion:

This solved the immediate problem. The cacophonous beeping that signaled a build failure could be heard on the far side of the room. And beyond, where even the non-devs in the office could enjoy the sweet sound of pure geekiness.

But could we do better?

Whenever Darth Vader thundered his beeping fanfare, all the developers would immediately stop and check Jenkins to see which component broke. We didn’t have a quick way to know “whodunnit.”

So we added a new feature: an Android phone attached via USB, plus a simple text-to-speech app that would announce the name of the guilty party and the component that he or she broke.

The end result is that whenever the build is broken: the following events occur:

  1. The flag goes up
  2. The dreaded “Imperial March” sounds
  3. A robotic voice says “So-and-so broke the build, in the project such-and-such.”

The final system looks like this:

 

Then, when the build is back to normal, the system announces who fixed it, and all is forgiven:

 

So nowadays, whenever we start to hear the infernal beeping from our Jenkins machine, everyone takes off their headphones and patiently waits to hear who broke the build. Possibly with some apologies/excuses/complaints from the accused individual. (“It’s because the downstream project built before I was ready!”)

In any case, it makes our office much more melodious and much more fun. And luckily, the nearest non-dev is a Star Wars geek, so she doesn’t mind our antics.

Do it yourself

If you’d like to recreate our setup, it will only cost you about 40 bucks and a little bit of development time. You’ll need:

  1. A Yocto-Servo device ($25)
  2. A micro USB cable to connect it ($6)
  3. A micro servo to work the flag ($8)
  4. The flag itself (we used a Canadian flag, because it’s what I had, eh)
  5. The cron script to call Jenkins and raise the alarm
  6. The SimpleTalker app, if you have an Android device available. We use an old HTC Magic.

Bonus features

We also experimented with a few other features. If you use this excellent Python script to convert MIDI files into beep format, for instance, you can find any MIDI you like and make it into euphonious beep music. Here’s what this Super Mario Bros. theme from VGMusic.com sounds like:

And you could use the Mario “game over” theme for a build failure:

Alternatively, the Android app I wrote supports specifying an MP3 file on the device’s storage, in addition to the text-to-speech. Maybe each of your developers prefers a personalized “failure” and “success” theme? The sky’s the limit.

And if the beeping sound isn’t annoying enough, I will humbly point out that Yoctopuce also offers USB modules to operate an emergency rotating light. I take no responsibility for the mental health of your office-mates if you actually install such a device.

Summary

Programming is fun. And in our office, we’ve found that turning programming into an audiovisual experience makes it even more fun. I hope you’ll get a kick out of the code we’ve written, and that your boss won’t think it’s a waste of time. (Ours didn’t, although she keeps the door to her office firmly closed now.)