A couple months ago I got my first Apple since the Mac Classic I had in college. It's a MacBook Pro and so far I really like it. I've managed to get it to do almost everything my Linux laptop could do, but now I've got access to iTunes and Adobe's Creative Suite (although it's slow under Rosetta). If Apple would allow me to change the focus behavior, and implement the X11 cut and paste, it'd be the perfect system for a laptop.

On campus I have access to the iTunes playlists of all the people on the wireless network that are sharing their music library. And I have mine shared so other people can check out the artists I enjoy. Unfortunately, iTunes doesn't tell you what songs connected users are listening to or who is actually connected.

Since OS X is Unix, it's easy enough to examine the process tree and discover what network and filesystem connections iTunes is making. Running:

ps -axo 'pid command' | grep -v grep | grep 'iTunes ' | awk '{print $1}'

will show the process ID for iTunes. Once you have this number, you can use lsof -p [pid] to show all the files (and network connections, which are treated like files in Unix) that iTunes is using. Filtering the results by your iTunes library (grep /Users/$USER/Music/iTunes/iTunes Music/) yields the songs that are being played, both locally and over the network. And searching for ESTABLISHED shows the network connections. The last part of these lines show the IP addresses of the computers connected to you, and if there are two lines with the same destination IP address, that means they are actually playing from your music library.

To automate this, I wrote a Python script watch_itunes.py that automates this process. Note that this is a command-line tool, running from a terminal window. There are Dashboard widgets that are supposed to do this, but the one I tried didn't work, perhaps because I have an Intel mac.

To use the script: ./watch_itunes.py

By default, it will examine the process tree every 15 seconds, showing what's playing and who is connected or playing from your music library. Run it with -h to see a list of command line options.

Here's what it shows right now:

192.168.1.101 is connected but not listening to music
Portastatic                Bright Ideas               05 Little Fern.m4a

192.168.1.101 is listening to music
Arcade Fire                Funeral                    09 Rebellion (Lies).m4a
Portastatic                Bright Ideas               05 Little Fern.m4a

In the first two lines, I'm listening to Little Fern, and another computer is connected to my library, but isn't playing anything. In the second set of lines, they started listeing to Rebellion (Lies). The program will keep printing lines like these until you exit the program with Control-C.

For many years I've used the Unix calendar program to send me an email reminder of upcoming events and holidays. Unix calendar files are very simple text files with one event per line like this:

Apr 22  We bring Koidern home, 2006

Google recently added a calendar to their set of web programs, and like most things Google does, it offers a clean and elegant implementation. Best of all, it's on the web, so you can access the same calendar information from anywhere there's an Internet connection.

These days, calendar files are typically in iCal format. I wanted to convert my Unix calendar file over to iCal so I could import the data into Google calendar. Python to the rescue!

Download the script: calendar_to_ics.py

To use it: cat ~/.calendar/calendar | ./calendar_to_ics.py > /tmp/calendar.ics

Import the file you created into your Google calendar by clicking on the Manage Calendars link, and going to the Import Calendar tab. The script is only designed to handle simple events that take place once a year, on the same day, and it only accepts dates in MMM DD format. But Python is easy to read and hack, so if you have improvements, please email them to me and I'll incorporate them into the script.

Following up on yesterday's discussion of making passwords that look random to the computer, but contain some pattern that's easily remembered, I wrote a little password generator in Python. It requires the 'fortune' program (fortune-mod, fortunes packages in Debian), as well as Python. The script takes two optional arguments, the number of passwords to generate, and if the script should create "difficult" passwords.

The output looks like this:

    $ ./fortune_password.py 1
    16422 : 4Dcfpnsfe#
    Don't compare floating point numbers solely for equality.

or if you've chosen the "difficult" version:

    $ ./fortune_password.py 1 d
    55424 : ya8=Ithotmk
    You are in the hall of the mountain king.

The difficult version puts the number, symbol and upper case letter in the middle of the string of letters, rather than at the beginning and end with the simpler version. I suppose the difficult version is slightly more "random" and is better as a result, but there's probably not much difference when it comes to how long it would take to crack it.

Of course, despite the way the passwords look, they're not actually random. So if the cracker knows that you've used a password generator based on the fortune command, they can generate a wordlist based on fortunes and use that in a dictionary attack instead of having to use a brute force attack.

The University has been requring certain departments to sit through a 15 minute presentation on using good passwords. One of the handouts had a chart showing how long it takes to crack passwords by how long they are and how many types of characters they've got in them. I'm interested in the subject because I typically assign passwords to my users when they start work. I wrote a simple program that takes words from the dictionary that are between 9 and 15 letters long, and which don't end in 'ing', 's', or 'ed'. The program then splits the word in the middle somewhere, inserts a random number, a random symbol, and capitalizes one of the following letters in the word.

For example, the script gets the word 'misdirection', inserts a '1' and a '%', and then capitalizes one of the letters in the word. The resulting password is 'misdi1%recTion'.

That password is composed of the letters [a-zA-Z], symbols [!@#$%^&*+=;:?], and numbers [0-9], so the set of characters to search for is 26 + 26 + 13 + 10 = 75. The password is 14 characters long, so the space a brute force attack has to search is 75¹⁴ = 1.8 x 10²⁸ which is a huge number.

I did a few experiments with my workstation, which has an AMD Opteron 246 processor inside. Performing a brute force attack requires encrypting all these possible combinations until a match is found. So the type of encryption used is important. My computer can perform about 450,000 encryptions per second if the encryption is the old style DES encryption used on most proprietary Unix platforms. But all of my servers are running Linux, which uses md5 style passwords, and my computer can only do about 3,500 encryptions per second. So 1.8 x 10²⁸ possible passwords / 3,500 encryptions / second means it'll take about 1.6 quadrillion years on my computer to crack it (or half that time on average).

Unfortunately, most passwords aren't cracked using brute force, they're cracked by using a dictionary attack, and since my passwords are generated using a dictionary, that means they're considerably more vulnerable. The question is, does my method of randomly inserting a number and symbol in the middle of a dictionary word (as well as randomly upper casing a letter) defeat a dictionary attack?

I don't know the answer. But I've done some experiments with pathologically bad passwords to see what might happen. On my computer a simple dictionary word is cracked within seconds. And a simple dictionary word with numbers appended (I tried 'barf51') is cracked in two and a half hours. So the jury is still out on my method. But I'll bet that my method isn't as safe as I thought it was at first. It's certainly better than the user that uses her husband's name, the name of the dog, or their license plate number for a password. Most cracking software has information about the typical behavior of users built into it, so it will start by searching the space defined by their username, their domain name, and common names. 'cswingle11' would be a pretty poor choice for me. 'misdi1%recTion' would undoubtably be better.

The only way to really generate passwords is to do it in such a way that there isn't a pattern (like a dictionary word) that the computer can identify and use to reduce the number of combinations the cracking program needs to test. So a better approach to passwords is probably to use a database of common phrases, and pull the first letters from the phrase, insert some random cases, symbols and numbers, and use that. Perhaps the 'fortune' command offers som possibilities here:

    $ fortune -n 80 | head -1
    There is no distinctly native American criminal class except Congress.

So: 'tindnaccec' --> TindnAcceC --> TindnA7#cceC

That's 75¹² = 3 x 10²² and because it's effectively random (unless cracking tools learn about the 'fortune' database and how it might be manipulated. . .), it'll take 286 billion years for a computer equivalent to mine to crack this.

Sounds like a Python script in the making.