This worked acceptably well, but I frequently had to ask myself: “which password did I use when I signed up for this service?” In response to having to guess my own passwords, I made two decisions: I would start writing my passwords down, and I would make them all unique and randomly generated. Four years later, I am using a totally different system, and I’ll explain all of my reasoning.

To facilitate my random password approach, I started using 3×5 index cards and a card filer. I added A-Z tabs, and I generally filed cards according to the domain name of the service (e.g. paypal.com is filed under P). I wrote a quick perl script to make 10 random passwords at a time, and I would pick one from the list and write it down on the index card. I really liked the concept of a purely non-digital password storage system, because it would be essentially unhackable without physical access. Essentially unhackable – more on this later.

There were several drawbacks to the index card system. For brevity, I’ll just list them:

• writing some characters by hand is ambiguous. I confused capital I, lowercase L, and numeral 1 all the time. Capital O and numeral 0 are also a trick.
• it’s possible to copy the password incorrectly
• it is extremely difficult to create a backup copy, so catastrophic loss is a possibility
• if someone has physical access to the index cards, they have access to your accounts
• it’s tedious to type in a random password every time you log in
• it doesn’t scale well after about 400 accounts

The scaling problems were the real killer. For example, did I file sandbox.paypal.com under P for paypal or S for sandbox? I don’t remember, so I need to perform a linear search through both letters. Or, since a disproportionate number of words start with S, then it became a more tedious task to flip through all the S cards in order to find an S site, whereas a site that started with Y would be pretty quick to look up since there were fewer. Eventually, it got to the point that I knew it was too much of a chore to look up cards, and on that basis, I became too lazy to log in to my accounts! Total failure.

The solution for me is to use Apple Keychain. If you’re a GTD adherent, then you’ll understand what I mean when I say this is my trusted system for account information. How did I reconcile a digital password storage with my original goal of keeping my passwords offline in order to make it unhackable? It was when I realized that both offline passwords and the keychain can be successfully attacked with a keystroke logger. If someone went to those lengths to get a password, then it wouldn’t matter how it was originally stored; the password could be intercepted regardless.

Why use Apple Keychain? Based on my list of drawbacks for the index cards, here’s a list of pro-Keychain points:

• built-in random password generator
• keyword search
• simple cut-and-paste workflow makes it very easy to enter passwords without typing
• keychain itself is password protected
• passwords are Triple DES encrypted (which should be acceptable until the year 2030)
• simple to back up keychain file
• slick integration with many applications, including Mail.app, subversion, and Safari/Chrome.

I’m currently at about 900 accounts (yes – this is deserving of a separate post unto itself) and the system is working great. I think this scales to meet my requirements, and probably beyond. In practical terms, a password that used to take 30 second to retrieve is now instant. I probably save 5 minutes per day by switching away from index cards, and I am avoiding untold frustrations. In all, I recommend Apple Keychain highly.   

Network Topology: equal distrust for the Internet as for wireless

A series of events brought me to the point where this became realistic, the most important of which is that I got an extra router for the LAN.  Let me briefly explain the current network topology I use, which allows me to equally distrust public Internet traffic as much as I distrust my wireless router.

- We connect to the internet via DSL and a router, which uses NAT to provide a private address space behind the router (10.0.50.x)

- The “wired” router connects to the DSL+router, which uses NAT to create a separate private address space (10.0.51.x)

- The wireless router also connects to the DSL+router, and as you might have guessed, there is yet another private address space behind this router (10.0.52.x)

So, if you’re using an ethernet cable, your connection cannot be routed to a machine connected via wireless, and vise versa.  Barring an attack against the wired router, the address space is simply not routable.  I’ll eventually provide a VPN into the wired network, so I can print using a wireless connection (since the printer is only connected to the wired network).

At this point, I was pretty happy about running a wireless access point, because I was really no worse off if someone attacked the wired LAN via wireless or via the public Internet.  Basically, both vectors are equally untrusted.

Digging into WPA2

Still, I was uneasy about actually using my wireless network, and I hoped that wireless security had advanced beyond the famous WEP debacle, which made it downright trivial to attack older wireless access points.  The solution is to use WPA2, which is a better protocol that only runs on newer hardware.  This is not without its pitfalls, and some impressive work has been undertaken to attack WPA2.  Notably, the pyrit project has made great progress using 3d acceleration hardware to create downright feasible attacks against WPA2 with a pre-shared key (WPA2-PSK).

An alternative to using a pre-shared key with WPA2 is to use a key server technology called Radius, but because I didn’t wish to run another server, I needed to learn more about the pyrit approach so that I could still use WPA2-PSK.

The Pyrit Approach

Pyrit can make use of multiple 3d accelerator cards, and now can even cluster machines for parallel processing, in order to pre-calculate values that are useful in attacking a wireless network.  In other words, it is plausible for anyone with enough friends (or perhaps a government budget) to get the raw computing power required to crunch the numbers.  After saving these computed values to disk (a process that takes hours or days), they can be rapidly transmitted to the access point in a few minutes, and the attack will have been executed.

The key here comes down to disk storage, instead of processor power, because we might as well assume that processor power isn’t realistically limited anymore.  From the pyrit blog itself, it appears PSK values longer than 10 ASCII characters cannot affordably be stored on current hard drives, even though it is definitely possible to perform the necessary calculations.

The pyrit attack is further thwarted by the incorporation of the wireless access point’s SSID in the WPA2 calculations, so while it is possible to pre-calculate an attack for common SSIDs (like “linksys” or “default”) it is only possible to attack a novel SSID after some reconnaissance to determine that value of the target SSID.  Most impromptu pyrit attacks will probably involve common SSIDs that ship as the default setting for wireless access points.

Other considerations

There is also the issue of traffic over the air, where the question is to either use TKIP or AES.  This one is easy: there is a weakness in TKIP, so don’t use it.

If you know ahead of time which machines will exclusively use your access point, then MAC address filtering will be an extra security measure.  While MAC addresses can be spoofed, it takes extra time to do so and can be a hassle to brute force your way through the address space.  MAC address filtering is an option on my wireless router, so I have chosen to disallow all network access except for the few wireless devices that I know the MAC address of.

So you know, it can become a hassle to keep your MAC address whitelist up to date if you keep adding new wireless devices, like if you have friends who drop by with their laptops.  It’s probably worth the 60 seconds it takes to add a new device, but YMMV.

Recommendations

After all is said and done, it looks like it’s possible to create a relatively secure wireless access point.  Here are my recommendations:

- Use WPA2-PSK

- Use a PSK that is the maximum allowable length (probably around 63.)  Use a completely random method that includes all allowable ASCII characters (mixed case, numbers, and symbols).  Your wireless access point will probably call this a “password” or something, but just know that this is the “pre-shared key” (PSK).

- Encrypt all traffic with AES instead of TKIP

- Use a randomly generated SSID to name your access point

- tell your access point to NOT broadcast its SSID.  This will prevent it from showing up in the list of available access points when someone clicks on their wireless network card to scan.  This won’t deter the most determined attackers, but do this if it’s an option.

- Use MAC address filtering.  Disallow all by default, and whitelist the devices you want to explicitly allow.

This should be a pretty good starting point, and it works with my $32 wireless router.  There may be new attacks in the future, and hard drive space will obviously get cheaper, but I feel pretty comfortable at this precise moment.