Tuesday, June 27, 2006
I was trying to register on a web site this morning. It didn't like the password I had chosen. The site complained:
Password length must be at least 5, and it may not contain any spaces or non-printable characters
Well, my password was definitely more than five characters long. It did contain a space, however. Why is that so problemmatic? I cannot, for the life of me, fathom why there are so many programmers out there who refuse to allow people to enter good passwords for things. To make their own programming tasks easier, they arbitrarily restrict the character set of passwords to the easy characters (letters, numbers, and a few non-controversial puctuation characters). Characters that seem to be particularly challenging for these programmers to deal with include spaces and quotation marks of various sorts. Of course, exactly which characters are problemmatic differs from site to site depending on the laziness of the programmer and the peculiarities of the web site back-end.
Rather than coding up a routine to detect all these problemmatic characters, why not spend that time writing a routine to properly escape them whenever they cause problems?
To put some numbers around this, let's just consider random passwords for a minute. By my count, there are 95 printable characters in US-ASCII (non-control characters). Using a 5-character password, that gives approximately 7.74 billion combinations (= 955). If you eliminate space and anything "quote-like" (double quotes, apostrophe, and backquote), that's 91 characters, giving you 6.24 billion combinations, or a reduction of 19.3%. That's a significant reduction of the search space to break a password, all because a programmer was lazy.
"Aha!" I hear you cry. "Just add another character to your password and it's far stronger anyway. After all, 916 = 568 billion combinations." Yes, that's true, longer is definitely better. But it turns out that for the same password length, the percentage reduction in the search space increases as the length gets larger. Thus, at five characters, the reduction is 19.3%. At 10 characters, it's almost 35%.
So, please, if you're coding a login/registration system, do everybody a favor and just write some escape routines. Don't take the easy way out and throw out a large percentage of your security just because you're lazy.
Wednesday, June 21, 2006
It has long been a popular pastime in the Lisp community to reminisce about "the good ol' days" when Symbolics and LMI were healthy, growing companies and Lisp machines were a growth industry. Indeed, from every one of the Lisp machine videos I have ever seen, the development environment was super.
Recently, I decided to start work on a new test tool for Vyatta. After considering the alternatives, I decided to write this tool in Emacs Lisp, using Emacs as a UI for the program. While Emacs Lisp is not Common Lisp and suffers from a number of deficiencies (no lexical closures!), it's still Lisp and there are some advantages to developing an application this way:
- You get a fairly-good full-screen text UI almost for free. Emacs takes care of redrawing the screen, handling keystrokes, and all that. Yes, it's a little bit clunky working with buffers of linear text, but once you get over that, things work great.
- There are a lot of Emacs Lisp libraries to choose from. In my case, I hacked something on top of Emacs' terminal mode. Rather simple and it works well.
- The code is portable. Because Emacs runs on just about everything, so does all the Elisp code I'm writing. There are some problems when it comes to interfacing with the underlying OS, but as long as you write higher-level code that doesn't expect much from the OS, things will work fine. In my particular case, I use some Unix/Linux OS utilities and so my program isn't portable to Windows, but it is portable to any environment that has those utilities available (which should be everything from Linux to BSD to OS-X).
- Finally, the development environment is great. When your editor, your Lisp system, and your application are all the same thing, work goes quickly and easily. You can be hacking your source in one Emacs window, running it in another window, and things just work. With Eldoc Mode providing parameter prompts for me as I learn the backwaters of Emacs Lisp, and Emacs Info right at my fingertips, I have all the assistance I can ask for.
That last point should not be skimmed over quickly. Having everything integrated, editor, Lisp system, and application, is powerful. While it can't quite match up to the power of a full Lisp machine, you can begin to realize some of the potential.
So, the next time you're wanting to reminisce about the days gone by of Lisp machines, remember that you probably have a pretty powerful Lisp machine already sitting on your desktop PC: Emacs.