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.
A really long time, depending upon password length. The number of passwords it needs to check is charsetlength. 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:
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.
|code - optimization||million pass/sec|
|old - javac||1.63|
|old - gcc -O0||2.43|
|gcc -fast (APPLE ONLY)||8.07|
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.