pssssh... don't tell.

Of all the projects I’ve posted this one is probably the most erratic. Usually I think of something interesting (or at least I think so), do it, and then post it. That hasn’t been the case with this project for two reasons. One, it’s really hard to program something that’s subjective, like a password that’s easy to type. Two, if you have an idea while you’re programming you usually have a bunch of code already written that will help you accomplish that idea… which leads to a cycle of taking tangents and pursuing random ideas. That said here was my thought process on this project:

Hey, my Andrew ID is one handed!…
I should make a one handed password…

Well this is easy. Here are some examples of what that program produced. That’s cool… but…

Those one handed passwords are hard to type…
I should make one that’s easy to type…

So… I set out to somehow evaluate ease of input. I thought about repetition, proximity, increasing pinky->index, and some other metrics. All this sounds good on paper, but it didn’t really pan out in the output. I ran around in circles trying to balance out those qualities without overpowering randomness. I started over so many times… idk. Passwords are such a personal item that I was never happy with the top result. I felt like it would be better to craft my one handed password. There’s got to be something to help me do this…

How about some one handed words…

I just grabbed a really big dictionary (172,822 words long!) and started looking through words… I started with aardvark. Nope. Here are the results: Left Hand, Right Hand. My current password is, and will continue to be, a derivative of one of these.

I wonder how long it would take to brute force a password!?!…
I wonder how much faster C is than Java…

Now I was all fired up. I thought it would be fun to make a program that would brute force crack a password. Of course I know there are better ways to crack passwords… people have put TONS of research into this. You can read about all that here: Wiki. I’m not attempting to do that, or even build a smart password cracker. I just wanted something that went brute force.

Answer:

A really long time, depending upon password length. The number of passwords it needs to check is charset^length. I’m just doing alphanumeric so the charset is 62… but that’s still growing pretty quick. I tested speeds by checking to see how long it took to crack “99999”… the last password checked for length 5. That said, my computer averaged 1.633 million passwords/second in Java and 2.438 million p/s in C. Seabass.ics.cs.cmu.edu averaged 8.462 million p/s on the same test. I made a spreadsheet with the exact times… but they are roughly as follows:

Update…

I had a bit of spare time today and I thought I’d revisit an old project I worked on. My new computer has a far more powerful processor than the one I originally used, 1.66GHz PowerPC 32bit vs. 2.4GHz Intel dual core 64bit.

I modified the Java and C program to print out the passes/second when they finish. This time I remembered to test with various levels of optimization.

And out of no where the Apple specific optimization sweeps. I was looking through the optimizations portion of gcc’s man and found this:

-fast
Optimize for maximum performance. -fast changes the overall optimization strategy of GCC in order to produce the fastest possible running code for PPC7450 and G5 architectures. By default, -fast optimizes for G5. Programs optimized for G5 will not run on PPC7450. To optimize for PPC7450, add -mcpu=7450 on command line.

On Intel target, -fast currently enables the following optimization flags:
-O3 -fomit-frame-pointer -fstrict-aliasing -momit-leaf-frame-pointer -fno-tree-pre -falign-loops

All choices of flags enabled by -fast are subject to change without notice.

Well that was fun… Fortunately (for my hacking of NASA) a third of the passwords on government computers are “password” or some variant thereof.