“When Ants Look As Big As Cars…”

Posted Saturday, 13 January 2007, 7:22 pm

Much to my surprise, the article I published yesterday—regarding a nifty, simple trick for adding a measure of security to passwords that have been written down—was submitted to digg.com, and even more surprisingly, it turned out to be very popular. Or rather I should say, it was very popular on digg.com,  but was a nightmare for me, scrambling to keep my server going under the crushing load.

The ‘fun’ began shortly after 7am, Pacific time. I got a text message from a script I run on an offsite system, probing my server every few minutes. After the second page, I dragged my ass out of bed and had a look. Yikes. I still had four SSH session open on my PC’s desktop from the night before, but none of them were responsive when I typed in them. Ouch.

I ran down to the garage (yep,  the server’s in my garage) to check it out. The server was up, but the disks were going absolutely crazy. This past night, we had had record low temperatures for our area, so one thing that crossed my mind was that the disks had simply gotten too cold, and were unable to recalibrate to compensate. Maybe. Since I didn’t have a serial console handy and this is a headless server, I power-cycled her. I use a logging filesystem, so the risks of a power-cycle even while doing busy disk seeks are minimal—I’ve yanked the plug from the wall during tests, over and over, and never had a problem. No problem this time either—server came back up, I headed upstairs to have a look.

Yikes! Server load was off the charts. All httpd processes. I quickly took a look at the logs, and there I could see that Digg had descended upon my little server.

I’ve been running the anastrophe.com server for something like eight years now. It started out as a Sun Sparc 20, and now it’s a Sun Netra T1. 440Mhz UltraSPARC IIi CPU, one gig of ram, and a pair of disks, mirrored. I provide email and webhosting and shell and other services for a few dozen friends and family. It’s a light load, and the hardware has held up just dandy. Until today.

The problem more than anything else was lack of ram. The Netra T1 can only hold 1G, so there were no quick fixes there. I did the usual things to try to tame the tiger—reduced the maximum number of concurrent httpd processes, fine tuned KeepAlive, etc.. But the reality was, I was caught utterly unprepared. I think I can be forgiven for not having anticipated that an article about passwords of all things would be a hit on digg. It’s no excuse though. I really should have had at least a backup plan, just in case. Maybe set up a secondary server, mounting the apache directories NFS, so the load could be split. I’ll be looking into that later tonight. One thing I did at one point was to attach an external disk array, and move swap onto it. That helped some—but by that point, the load on the server had already begun dropping, so it was too little, too late.

So what does the title of this article have to do with any of this? There’s an old skydiving rule of thumb:

When cars look as big as ants, it’s time to open the parachute.
When ants look as big as cars, you’ve waited too long.

 I’ve been picking ants from my teeth all day long.

Passwords On Post-its? You Bet!

Posted Friday, 12 January 2007, 3:36 pm

A not-uncommon IT-to-user conversation: 

IT Dude:  "The password to log in to your new PC is r4eo1ss89"
User: "Um. Okay. But how will I remember that?"
IT Dude: "Not my problem."
User: "Okay, but there’s no way I can remember that. I’ll have to write it down"
IT Dude: "If you write it down, it’s no longer secure – if someone finds it, they’ll have access to your machine. Do not write it down!"
User: "But…but if I can’t write it down, and I can’t remember it, what can I do?"
IT Dude:  "Not my problem."

At this point, IT walks away, and the user will likely change the password for their PC to "letmein". Or "abc123". And tell security ‘Goodbye’.

But there is a way to keep that impossible to remember password always at the ready, in plain view even—and yet foil anyone who tries to use it. I came up with this idea about a year ago, and to my knowledge, nobody has ever suggested the idea. So I claim inventor status!

So, IT stuck you with r4eo1ss89 as your password. You’re a smart cookie, but you know that if you try to memorize it, you’ll forever be transposing the ‘eo’ to ‘oe’ or running out of memorized characters after the ‘1’. So, the reality of that secure password is, you have to write it down.

Well, don’t hesitate, write it down! Use a bold Sharpie® on a Post-it® , write it in big letters—if you’re feeling particularly cheeky, write "Password for my computer" right above it.

The secret—and there’s a pun in there, I promise—is to ‘password protect your password’. How? It’s absurdely easy, mind-numbingly simple, and you’ll wonder why you didn’t think of it yourself first!

Drum-roll, please: Choose a letter or number that will be your "personal" password. One single character. Add that character to whatever password you have, anywhere in the password. The only caveat is that you must ensure that any password you use does not already contain that letter or number.

Here’s an example. I decide that—for every password I will ever write down—my ‘personal password’ character—my ‘secret key’ so to speak—is a lowercase ‘w’. IT gave me the password r4eo1ss89 . so I write down my password like this:

Good Luck, HaX0R!

This is, for all practical purposes, completely uncrackable. The only way someone could ever get in with that is if they already know that you are using a bogus character in the password, and already know what the character is. You’re presenting them with a password that cannot work unless they know your secret—and it’s a secret that’s exceedingly easy for you to remember and keep secret—just a solitary character! Obviously, it’s a good idea to not use one of the initials of your name. But again, for someone to even put it to use, they have to know that you’re doing this to the password in the first place. If you want to get even more clever, pick a position and designate that your ‘personal position’ along with your ‘personal character’. With that, you can then have passwords that do contain your secret character – just so long as it’s not in your chosen position. So if I chose the letter ‘w’, and always in the fifth position, I could have a password of

a9are4wp2w1 and simply modify it to


Arguably, this positional technique could be slightly less secure—if for example you were to print out your passwords in a cheatsheet, and have them all aligned to the left—then the pattern of a ‘w’ in the fifth position might become apparent. For the serious IT person who has to maintain his/her own list of many complex passwords, it’s probably best to not use a position parameter.

With this exceedingly simple technique, you can hide your passwords in plain sight. People will wonder why it is that you can get in with your password all the time, but when they try to take a sneak-peek into your computer after you’ve gone home for the day, they can never get in.

Share and enjoy!

Followup: It just occurred to me that there’s another variation on this that can work well: Secret character removal. This one does work best with positional parameters: select a character that you will always have in your password, in a particular position, then remove that character from what you write down. So, for example, your secret character is ‘f’, and your secret position is two. You create and use a password of:


But you write it down as


Since you know there will always be an ‘f’ in that second position, it’s just as easy to remember as the ‘extra’ character method. And since you are not writing down the character, it’s potentially even more secure than the already very secure ‘add a character’ method!

Update: Please read my followup article, which addresses some of the concerns that have been expressed regarding these methods.

But what I really meant to write was…


Grabbing Status In A Script

Posted Thursday, 11 January 2007, 11:48 am

Continuing my earlier theme of Things Unixly, here’s another mildly novel technique that I don’t think many folks are too familiar with.

I’ve written a lot of shell scripts over the years. Back in 1999, I needed to write a script to back up my servers to a DLT jukebox. Sure—there’s commercial apps out there that’ll take care of all the nitty-gritty, but I’m the kind of guy who prefers to get the nitty-gritty under my nails. So I did it myself.

The details of the script are really immaterial. I had a small program that could issue control commands to the jukebox, and the script would step through each of the servers I needed to back up, and step through the DLT tapes along with it.

One of the first problems I ran across was, ‘how can I tell whether the backup was successful’—which went hand in hand with ‘if the backup wasn’t successful, I still need to have the jukebox move to the next tape’. But beyond that, I needed to know whether the tape actually—really and truly—had been moved into the slot it was supposed to move into after a backup was complete. If the control software had failed to move a just-written-to tape out of the recorder, I definitely did not want it to just continue merrily on its way, overwriting the backup it just made!

So how do you check the status of a command that’s been issued within a shell script? With the little-known


Looks kind of silly, all alone on a line like that, doesn’t it? It’ll make more sense if I reproduce a small chunk of the script:

movejb.bin /dev/jb0 240 ${TAPE} > /dev/null 2>&1
  if [ ${STAT} -ne 0 ] ;then
   echo "${ABORT}\
   \n\nUnload tape ${TAPE} failed exitcode ${STAT}"\
   | mail -t ${PAGER}
   exit 1

‘movejb.bin’ is the jukebox controller program. Redirecting standard out and standard error is, uh, a standard practice so that your script doesn’t spill out text on the console while it’s running. But what we care about is the line immediately after that—


That line ‘grabs’ the status output of the command that just ran, and sets it within the variable ‘STAT’. We can then test the variable to see what that output code actually was. This works for almost any Unix command you throw at it. You can do the same with grep, to test whether it did or did not find the string you were looking for in its output.

The rest of the script should be reasonably self-explanatory to any Unix jock. In this portion of the script, if the status indicated that the tape had not been moved out of the recorder and back into its space in the jukebox, we knew a pretty critical error had occurred—the jukebox possibly locked up—so it was best to completely exit the backup script, and alert the poor sap on pager duty, usually me!

Beware though, there is no genuine standard for exit codes. As well, not all manpages even list what the expected exit codes might be after the command is run. Always check the manpage, but if you can’t, write a standalone snippet and test the output yourself—easily enough done for example with

echo $STAT

Make sense? I hope so. If not, please let me know—it’s easy for me to gloss over critical parts of things like this, since it’s all practically hardwired in my brain.

Bad Form, Old Boy

Posted Tuesday, 09 January 2007, 10:39 pm

So, it seems I buggered-up the RSS feeds here yesterday, while playing with the Feedburner Feed Replacement plugin. Which means my massive audience of one or two missed out on the delicious ‘Apple’ post of earlier this evening. Heavens to Betsy! So, in truly bad form, I’m posting a throwaway entry here, to get the pipes unclogged, so to speak.


To much fanfare, Apple Computer today released the iPhone. To be sure, it’s a sexy, innovative device—that’s what Apple does. But a quick look at the device and I, for one, can see that its boldest feature will also be its biggest shortcoming. That being? The touch-screen. Or as I like to call it, "That great, big, constantly smudged magnet for the business end of car keys, pens, eyeglass frames, pocket change, and in general anything sharper than your Aunt Tillie’s wit".

Certainly, those who fork over what promises to be a fatted-calf or two to own one of these little delights is going to be very, very careful with it. So, deprecate the potential scratching/gouging of the screen, since owners will keep likely it in a velvet-lined titanium case. Still—it’s a touch-screen. You operate the device by touching the screen, sliding your finger around on screen.

Just as a for-example, here’s a photo of the screen of my Treo 650, after using my finger to operate the touchscreen for a while (which should properly be operated with the included stylus):

You get the idea…


Made with WordPress and the Semiologic CMS | Design by Antonella Pavese