An Ever Changing Password|
By Thiravudh Khoman
Ten years ago, before I started using local area networking, the company I worked for owned a handful of standalone PC's. As the PC administrator, I tried to make these computers easier to use by employing a DOS-based menu shell. Using such a menu allowed all of the computers to have an identical interface and saved me from having to inform everyone in the company what batch files ran what programs.
Being somewhat security consicous, I also made sure that users could ONLY use the programs I provided on the menus. This meant preventing them from going to DOS where they could perform "mischief". Despite this, I had to create a backdoor which allowed me and my assistants to go to DOS when necessary. The menu shell had an optional feature whereby a command or batch file must be password checked before proceeding. But since the menu script was not encrypted, anyone with access to a word processor (which was available on the menu) could read the password.
In the end, it was necessary for me to write my own password routine. Writing such a routine using a compilable language would allow me to hide the password, but it was rather inflexible since changing the password involved redistributing the program. It was possible that one day someone could make out the password by looking over my shoulder or I would be forced to give out the password in emergencies. In such circumstances, I would have to replace the password program on ALL of the computers in the company. Not fun.
What I wanted was NOT a single password but a password which changed frequently all on its own. The easiest way to do this was to choose a system which generated a password based on the calendar date. The algorithm I used was an incredibly simple one. If today is Monday 28 February, the password for today would be M28. Tomorrow, M28 would no longer work and the password for the day would be T29 (i.e. Tuesday 29 February). And then, W01, T02, etc. (Of course, all this depends on your system clock being reasonably accurate!)
Because my routine did a case insensitive substring search for M28, I could add junk characters to the beginning or the end of the string and the input would still be validated. Thus M28, sd09m28 and T34M28EL ALL work. If no one was looking over my shoulder, I could enter a short and sweet M28. If someone was nearby, I would add a few junk characters. But actually, even if they saw me entering M28, the password would no longer work the next day and they would assume they had the wrong password. Besides being immune to eavesdroppers, I could also give temporary passwords to people in emergencies; for example, the T34M28EL password above. They could use it on that day only.
All this of course depended on people on not being able to figure out the algorithm, which despite its utter simplicity wasn't so simple to guess. Who would even think the password wasn't fixed? Eventually, I wrote a "version 2" of the routine that accepted a slightly different password: MM28, TT29, WW01 (i.e. the first letter was doubled which made it easier to type vis-a-vis the old password). With both versions of the routines scattered throughout the company, I could always get "in" by typing the newer password since MM28 would "match" on both versions of the program.
Bottom line: It's easy to make a very minor change to the routine that makes the algorithm difficult if not impossible to guess. For example, I could move put the M or MM to the end of the string (28MM), I could add the M/MM in front AND in back (M28M), or I could use M?28 where ? is a dummy character (i.e. the password is a 1 letter string PLUS a 2 letter string separated by a dummy character). The possibilities are numerous.
The purpose of this article ISN'T to provide readers with a way to password protect a DOS menu shell - of course, that day and age is over. Rather, if you have a situation where an administrative password needs to be embedded in your application (this doesn't work for user passwords by the way), rather than using a single, fixed password, you might consider a more flexible password routine.
("All God's children got algorithm" - Newton F. Walker, 1972)