Tuesday 29 November 2011

Password Restraints

Most operating systems weren't developed with security as top priority. Indeed, password-based accounts should be all the security required on a time sharing system. As we have seen, however, too frequently passwords are chosen that are easy to guess. The UNIX operating system does restrain password selection by suggesting that passwords contain no less than five lower case characters, or only four characters if at least one of those is nonalphabetic or uppercase. However, if a user insists on a shorter password, disregarding the plea that security be maintained, that shorter password will be allowed.

Sysops know that most passwords aren't secure, so many have installed programs which disallow obvious passwords from being generated. Passwords are then forced to conform to certain characteristics, such as:
• Passwords must be of a certain length.
• Passwords must include a mixture of upper and lower cases.
• Passwords must include one or more numerals.
• Passwords must include a non-alphanumeric symbol.

One or more of these constraints might be en-forced. The program may also test the user's password against a list of known "bad" passwords, which are not allowed to be used.

Not allowing single-case passwords or strictly alphabetical passwords does add some difficulty to a guess-attack, but not much. One time I had some-one in mind who I felt certain had "popeye" for a password, due to his large collection of classic comic books and the big deal he always made about Popeye. The system software required a mix-ture of cases (which helpfully informs you, by the way, that upper and lower case are distinguished by the system), so instead of just trying "popeye",
I tried:

Popeye          PoPeYe             popeyE
PopEye          popEYE            popEyE
PopeyE         PopEYE             PoPeye

and also tried each of these with cases reversed, such that PopeyE became pOPEYe (in case the user thought of capital letters as normal for computer keyboards, and lower case the exception). It was highly unlikely that this particular Popeye lover would try anything so bizarre as capitalizing in the middle of a syllable, or without
some pattern to it. Indeed, when forced to capitalize, who in their right mind would?

As it turned out, his password was "OliveOyl."

If not capital letters, numbers might be forced into one's password upon first login. Again, you can hardly expect Joe User to break up syllables with a number, and the numbers that are used you should expect to be not more than one or two dig-its. After all, the user thinks of it as a password. The number will generally be slapped on as a necessary afterthought.

Thus, what you will normally find are passwords in the following forms:

password #
pass # word
# password

Numbers will be those which are easy to remember, or easy to type, like 1 or 0. Numbers from one through 31 should be most common, along with numbers either repeating, ending in zero or nine, such as "888," "500" or "1999." It is reasonable to expect typists to use the numeral "1" substituted in for the letter "I" (lowercase
"L"), in passwords which contain that letter. Cyberspace devotees might do likewise, as well as using zero for their required number, putting it in place of the letter "O." This means that if you ever suspect a word that contains the letters "L" or "O," instead of finding something like "cool," "computer," "lucifer," "lemon," or
"colts," you may find `c001," "cOmputer," "lucifer," "Iern0n," and 'Wlts," where the digits 1 and 0 have replaced the appropriate letters. (Actually, "c001" is usually spelled 'k001.")


Computer Generated Passwords: Fakery and Analysis of Machine-Generated Passwords

Many passwords that the computer generates on its own will have some flavor of randomness to them. For instance, look at this bit of imaginary program segment:

5 Randomize Timer

100 For i = 1 to 6
110 Char = Int (Rnd * 91)
120 If Char < 65 Then Goto 110
130 Password = Password + Chr$ (Char)
140 Next i
200 Print "Your new password is: "; Password

Here, six uppercase letters are selected inde-pendently and concatenated to form the password. The way the letters are selected is that a random number between 65 and 90 is chosen - this corre-lates with the ASCII code for the letters of the uppercase alphabet. The randomness of the numbers chosen is based upon the
randomizer function being used. In this case, pseudo-random numbers are generated based upon the exact time of the computer's internal clock, although randomization could also have been based on a practically infinite, hardwaredependent range of inputs. I said pseudo" random numbers because no matter how random these numbers may appear to us, to the computer they are just values plugged into a formula.

If the password-making program could be altered in the right way, then all randomly-generated passwords after the time of alteration may be yours for the taking (or deducing). If you have the ability to change the program and save the changes to disk, or the ability to reroute the password-making subroutine, then
here are some further items to consider.

The easiest thing to do would be to change the program by getting rid of the randomization factor entirely and simply inserting a "Let Password$ = "EVBIDCL8.... statement. Then every new user would be given the same seemingly random password. The problem is this is not going to go unnoticed by the system
administrators (although you might be able to restore the original program before your change is noticed).

A more logical choice is to have the program generate a random-looking password based on some information about the user that you can eas-ily determine from publicly available sources, such as the user's birth date or Social Security number.

Then you can simply plug that piece of information into your copy of the code on your home computer and reproduce the new user's password. One encoding algorithm that works well is to take the sine of the ASCII value of the first six or eight characters of the user's name, then take the second-to-last two values of the
sine, convert them to fall within a suitable range, then concatenate the corresponding ASCII characters to form a "word." Thus you have a random-seeming password that can be easily constructed, even by hand. If the username is less than six characters, the remainder could be filled in by a predetermined set.


A sample username is encoded into an obscure password using the method
outlined in the text. On inspection the password seems random and secure, but
a hacker can determine a user's password using publicly available information
about that user (in this case, the user's last name).


This is just a simple example; your password would have to comply with case mingling, length, or digit sprinkling requirements where appropri-ate. Forcing a password in this way can help if you run an electronic messaging or bulletin board system: users may get so comfortable with their new, secure passwords (wouldn't you think "rueavz" was secure?) that they transfer them over to other accounts elsewhere.

Another possibility, again requiring the ability to covertly change the password generator, is to al-ter the randomizer's seed to a constant value, thus causing the program to produce the same series of random numbers each time it is run (as long as the computer stays on and the program is not reset). This is risky though, and unwanted side effects may result.

One method utilizing the flaws in pseudo-random number generators was actually accomplished, and reported on by UNIX co-creator Dennis M. Ritchie in a 1986 security bulletin en-titled "On the Security of UNIX." To increase security at a computer installation, the administrat-ors decided to provide safe, computer
generated passwords. Each password would be a string of lower case letters and digits, eight characters long. This calculates to 2,821,109,900,000 passwords which, according to Ritchie, on a PDP-11/70 would take 112 years to brute force through all those combinations. But the hacker knew that the random number
generator could only take 32,768 seeds, and so only that many possible outcomes needed to be looked at. "The bad guy did, in fact, generate and test each of these strings and found every one of the system-generated passwords using a total of only about one minute of machine time." [Emphasis added.]

Clearly, sixty seconds plus some programming time is worth spending to have access to every ac-count on a system!

If you can't insert code to generate machine-made passwords, you might be able to analyze them after they've been produced. This requires having access to a minimum of one password, preferably two or more, from a given system. If you have a legitimate account, there's your first password. If it's a local BBS you're hacking, or some other sort of system where multiple anonymous logons are possible, try calling back a few more
times and collect new passwords under different names. Or get ahold of the BBS software or the password-generating routine, and work that to collect various passwords.

Once I was going through some new BBSs that had started up and I came across an ad for a system that was a couple states over but still seemed worth a try. I called up, logged in as a new user, and found it wasn't all that interesting after all - run by a factory supervisor mainly to let site agents or-der inventory stock. I used the
made-up name and address Roger Eichner, 13 Stem Court, North Coast, WA 64203 to log on. The password that was generated was "roghner24." I was astounded! Obviously the program had simply taken the first three letters from my first name, the last four letters of my last name, and stuck a number at the end!

Or had it? I called back a second time, logging in as a new user with a different name. This time there seemed to be no correlation at all with any of the personal information I had given. Now I was not only astounded " but confused as well! Had the first password been simply a fluke? Was the second a fluke? Was it
programmed to only sometimes use parts of the username? I called back a third time and again logged on as a new user. Again the password was unrelated to anything I had entered. Now I was pretty positive the first password had just been an unbelievable coincidence. I wrote a message to the system operator, saying he
could delete these three new users of his (I supplied their personal info so he would not think I was playing a joke) and I didn't call back until a few weeks later.

Even though my second two passwords were unrelated to both each other and my personal data, I thought that perhaps I had missed something that first encounter, since some of the characters were repeated from one password to the next. Could these characters refer to my baud rate or computer type, or some other parameter that had stayed the same from one login to the next? Or was it possible that what was random about the passwords was which pieces of data it selected to insert into the password? This would account for my name in the first case, and one of the items (which I didn't recognize as relating to me) being repeated in the third call password.

Logging on with the same name, address, terminal characteristics and everything else as I had originally done, I received, to my disappointment,

not a computer-generated password but the following astonishing message:
Dear Member:
Sorry about having to go through this again but we've had a problem the last few days. I will have to ask that you be patient with the low access level you will receive until I get a chance to validate you. Please note, when asked to supply a password do not give the one you were previously assigned. Make up a new and totally unconnected password.

See General Posting #1 for explanation.

StRaPmAsTeR === wllLiE ===> (sysop)
Input Password ==>?

General Posting #1 said that a certain (relatively new) user of the BBS, whose handle was Mr. Joke, had kicked into action a "feature" of the BBS soft-ware that produced less-than-secure passwords. The previous year the system had "crashed, appar-ently as a result of a rogue program that was uploaded to file section by Mr. Joke." No further de-tails were given on the cause or nature of the crash, because apparently regular callers of the system al-ready knew the story.

Anyway, you can see how it's possible to occa-sionally get some good information by analyzing of random" passwords. Even if there doesn't seem to be any discernible pattern, that doesn't mean there isn't one hidden somewhere. There might be some subtlety to the pattern or, if not a pattern, a bug or strangeness that you might be able to spot. For example, in the first version of one BBS program -a program that was so godawful the board folded after about a month - the random password generator would never produce a password with the letter A or the digit 0 in it. Knowing this does help a little: for a seven character password of the form WXYZ123, where WXYZ are letters of one case and 123 are numbers, there are only 284,765,630 possible combinations of letters and numbers, instead of 456,976,000 - a difference of 172,210,370 passwords! This software was riddled with bugs, many of which have become famous as the worst blunders in the history of horrible programming.