dave@utcsrgv.UUCP (Dave Sherman) (06/13/83)
Back in the days of v6, login would only prompt for a password if a valid login was given. Then people realized that that gave away valid login names and made breaking in easier. So now login prompts for a password whether or not the login name is valid. But nowadays, all kinds of login names are freely available from the net, so this protection is a little less useful. Admittedly, most would-be break-in-ers aren't on the net, and the net doesn't give anything approaching a complete list of logins at a given site, but it's a thought.... Dave Sherman Toronto
rcj@burl.UUCP (06/15/83)
And how many of you out there have logins like: games help teach guest and the like with easy-to-figure-out passwords? A fellow at Bell Labs Whippany wrote a piece of software that took as input information about a person -- spouse's name, relatives' and pets' names, hobbies, schools, etc. and took that as a working base for figuring out passwords. You would be surprised to find out how many passwords he found out with that program!! Think about that before you make your password from your anniversary date, your spouse's birthdate, or your initials followed by the last four digits of your telephone number. -- The MAD Programmer -- 919-228-3814 (Cornet 291) alias: Curtis Jackson ...![ floyd sb1 mhuxv ]!burl!rcj
chris@umcp-cs.UUCP (06/16/83)
I usually go for the random-word-from-a-dictionary approach. I find
some large book near at hand, open and point ``at random'', and pick
a word that way. Has anyone tried password-analysis with real words?
Is it a ridiculous idea in the first place?
- Chris
--
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs
ARPA: chris.umcp-cs@UDel-Relaysmk@linus.UUCP (Steven M. Kramer) (06/16/83)
Very good. security!ehb did just that. He used the spelling dictionary
to compare against passwords. He also compared the encrypted login name
against them. Amazing what he found. (He caught me in it too. I thought
I was cleaver in picking my passwd, but it was the same as someone's login
name.)
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!smk (UUCP)
linus!smk@mitre-bedford (ARPA)z@cca.UUCP (06/16/83)
Since some people will always pick passwords that are easy to guess, and since a system is only as strong as its weakest password, one obvious solution is to make the password program more restrictive. Here at CCA, all passwords must be at least five characters, and at least one character must be nonalphabetic. Passwords which are all numeric are not allowed, either. Steve Zimmerman
budd@arizona.UUCP (06/16/83)
for a long time i have used geometric passwords. These are formed by taking some pattern, such as three keys from one row followed by three keys from the row below, or a square, or an L shape, or some such pattern on the keyboard. This makes "word searches" much more difficult, although if someone knows this is what you are doing and they wsee your fingers typing in the passoword they may be able to deduce the pattern.
swatt@ittvax.UUCP (06/16/83)
One method I've used to pick passwords is to take the first letter from each word in some random phrase in a magazine advertisement. This has the advantage that it almost never looks like an english word, and hence cannot be produced by pseudo-english generators. It has the disadvantage that advertisements tend to generate short (5-6 word) slogans, so the resulting password is subject to exhaustive search. To cure this, take the first letter from each word in a line of your favorite poem: "I must go down to the sea again": imgdttsa "Fog creeps in on little cat feet": fciolcf "There was a young man from Nantucket": twaymfn and so on. Another method is take trade names backwards: "Coca-Cola" becomes "alocacoc". A friend of mine once wrote a filter which read standard input, and only passed to standard output words with successive letters on opposite sides of the standard keyboard (so you could type it faster). He called it "baf" for "Back And Forth". - Alan S. Watt
nrf@whuxlb.UUCP (06/17/83)
Our system administrator selects root passwords by selecting an arbitrary printout and using whatever letters appear in a given column of the listing. (These are subject to evaluation based on the mix of upper, lower, and special characters). the resulting passwds are totally nonensical, though, and I suspect that super-users have a tendency to write them down.... Neal Fildes, BTL Whippany
rcj@burl.UUCP (06/17/83)
A system for choosing passwords only works if the range of
that system is incredibly large and cannot be whittled down
in some manner. For example, a required seven-character password
provides a sufficient range itself, if you do not start using
your dog's name or some geometric pattern on the keyboard.
If everyone picked truly random passwords of some minimum length,
there would be no password problem. Unfortunately, us mere mortals
have to remember them. I think that the idea of using some mnemonic,
(the first line of a poem, ad campaigns, the funny thing your daughter
said yesterday, etc.) as the basis for a password may be OK, if you
are suitably circumspect. Who is going to have the data space and/or
time to put enough stuff into a data base to try out "tnpgnq" ("Take
no prisoners, give no quarter.")?
--
The MAD Programmer -- 919-228-3814 (Cornet 291)
alias: Curtis Jackson ...![ floyd sb1 mhuxv ]!burl!rcjhugh%hel-ace@sri-unix.UUCP (06/17/83)
From: Hugh A. L. Dempsey <hugh@hel-ace> Even more deadly is the "who" command; a person can usually type who at the login prompt and get all of the login names of the current users. hugh
satz%sri-tsc@sri-unix.UUCP (06/17/83)
We have a similar program that beats up the passwd file looking for "easy" passwords. But instead of attacking the problem from a defensive standpoint, we took an offensive one. We modified the passwd program to do some more checking before allowing users to set there passwords. If we get a hit, we don't let the user use that particular password and ask for another one: 1) check his username forwards and backwards 2) check his personel name forwards and backwards, first and last 3) a list of common phrases (and nonwords) forwards and backwards 4) the entire dictionary forwards and backwards Believe it or not, it doesn't take more then 2-3 minutes to change your password (on an 11/44) since it uses clear text in its testing. This is pretty paraniod, I realize, but it is effective. It can be rather frustrating to choose a new password, however. The only real "hole" left in passwd is that we will still allow small passwords to persistant users.
dan@idis.UUCP (06/17/83)
I have become attached to my current password over the years. Every once in a while, when I worry about password security, I consider protecting myself by editing /usr/dict/words.
pdl@root44.UUCP (06/17/83)
I thought all passwds checked the given passwd to make sure it was complicated enough for their liking. (The V7 passwd would allow you to give an easy one if you insisted, the System III passwd just plain refuses to change it to an easy one). Dave (``it's all been done before'') Lukes ...!vax135!ukc!root44!pdl
edhall%rand-unix@sri-unix.UUCP (06/18/83)
As the former system manager of a campus UNIX system, I am well aware of many of UNIX's security holes. Students (and sometimes others) seem to have a knack for discovering these, and often exploit them when they do. Some of these people of dubious morals read UNIX-WIZARDS. They might see a paper copy of it circulated around the computer center, or even have a legitimate entry on the mailing list. I'm certain that at a half-dozen places across the country someone is now creating a program to search the UNIX word list for a password. Maybe they'll get caught, or their program will be killed when its discovered using up so much CPU. But a weekend would be all it takes, and perhaps on a `borrowed' account. I hope the message is clear. As much as I'd like to be able to discuss security issues on UNIX-WIZARDS, I'm afraid doing so can do as much harm as good. But everyone who reads UNIX-WIZARDS knows better than to use a trivial password, right? Especially system administrators... Let's hope that chance that everyone has realized that an 8-letter password can easily be less secure than 3 random characters. Excuse the flame; there have been several chances for me to comment on this in the past. Some recent sad events on my `old' system inspired me to write now. -Ed
bormanp@stolaf.UUCP (06/18/83)
Some thoughts on passwords: 1) Never use the number row (1234567890) 2) Keep use of the "qwerty" row to a minimum 3) Enjoy the home row and the row below 4) Get a healthy rythm to it so it can be typed fast 5) Make sure it makes you alternate hands often 6) NEVER use a real word or anything that appears in a dictionary. 7) NEVER write it down or otherwise have it appear. I feel this is much better than just picking some random letters. One possible way to create one is to take a word from the dictionary which has a nice feel and then mung it. transpose a couple characters, delete letters or add them. For memory, it is nice if it has some sence of sound though, this helps out in #7 above. -Paul R Borman St. Olaf College ihnp4!stolaf!agnes!paul
gwyn%brl-vld@sri-unix.UUCP (06/18/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> The "passwd" program simply ought to refuse to let one choose a password that is in the on-line word list (or spelled backward, etc.), or one that is too short, or in the list of login names, etc. The "salt" characters help somewhat, and the time it takes to encrypt a password is comfortably large. On BRL UNIX, the encrypted passwords are stored in a protected file to force all accesses to go through trusted system code. Three invalid login attempts and you're disconnected. By a combination of tricks like the above, it should be quite hard to break into a system. If guest accounts (anonymous logins etc.) set up a "restricted" environment then such accounts should pose little danger since the passwords for other accounts would be inaccessible. Unfortunately Berkeley has stolen the name "rsh" to mean something other than the "restricted shell" but that is easy to work around.
rcj@burl.UUCP (06/20/83)
As one of the more guilty parties (re: Ed's article about not discussing security in net.unix-wizards), I feel obligated to relate a real-life example of a system break-in (the only really major one that I have first-hand experience with), and the consequences thereof: I went to school at a major Southern university. We primarily used a DEC-10 running the TOPS-10 operating system, although we switched to Unix on a PDP-11/34 for the upper-level courses later. The school of pharmacy made great use of the DEC-10 for research purposes, and there was one grad student in pharmacy who was the guru for the whole pharmacy school. This grad student was liked by EVERYONE, taught two computer courses for the computer science dept. every term, and had won several awards from the University. If any of the pharmacy faculty (or anyone else he knew) forgot their password, they just went to Jim (not his real name) and he would pull out a little printout that he had and tell them. This went on for some time until someone as the Computing Center found out about it and hit the ceiling. Apparently, (and remember, this is not Unix), someone had the password file VERY well protected, but the binary copy that was actually read by the system was readable by everyone. Jim found this out, got a dump of the binary, and used a sliding window technique to find out the password field and then decoded the simple ASCII. Even though it was demonstrated to everyone's satisfaction that Jim did not take advantage of this information in ANY way whatsoever, and even taking into account his very high standing with the University, and even though both the Computer Science dept. of the School of Engineering and the Dean of Pharmacy School came to bat for him, he still came within one vote of losing his job. And this information was just lying around for anyone to look at -- all he had to do was a very simple decoding. Imagine what would have happened had he really had to break a lot of stuff to get in!!! Because I worked on our Unix installation, I had privileged access (read: root password). One day, I was trying to find something for one of my professors when I catted a file that came up: Second Semester Final for CSCI xxx I immediately hit delete, and went to my professor later to tell him exactly what had happened in case he had some sort of accounting daemon running that I didn't know about. He smiled, said it was ok, and that he had three bogus copies of that final on disk just to catch anyone who might break in. He told me further that the real exam was always typed in by his assistant on the night before the exam, or even the morning thereof. Computer Science professors (and, increasingly, those in other areas) know that students will try to break in -- and those possible access methods are usually not totally booby-trap-free. It ain't worth it, when there's so much money to be made so easy in computer-related fields, -- The MAD Programmer -- 919-228-3814 (Cornet 291) alias: Curtis Jackson ...![ floyd sb1 mhuxv ]!burl!rcj
ron%brl-bmd@sri-unix.UUCP (06/20/83)
From: Ron Natalie <ron@brl-bmd> Unfortunately, the real RSH is usually very breakable. -Ron
bernie@watarts.UUCP (06/20/83)
Another simple technique is to choose an existing word or proper name, but spell it wrong (i.e. arbitrarily replace one of the letters with a random letter). For example, take "elephant" but replace the 'l' with an 'x' to get "exephant". This is (a) easy to remember, (b) fairly impervious to word search algorithms, and (c) confusing to people who look over your shoulder or try to decipher hard-copy listings. It works even better if you use a letter that's close on the keyboard to the correct one, such as 'k' for 'l'; someone with curious eyes would swear you'd typed 'elephant', only to find out later it doesn't work. Another approach is to replace the vowels, to get 'alaphent' or some such. --Bernie Roehl ...decvax!watmath!watarts!bernie
oz@rlgvax.UUCP (06/22/83)
Still another approach is to use YIDDISH words. Even if you tell someone what your password is, odds are they can't spell it! We had great success with that when I was at the Air Force Data Services Center. Our password while I was there was tsuris (which means "plenty headaches", or worries) very appropriate for a government UNIX V6 system! I do acknowledge that this approach won't work for everyone. OZ seismo!rlgvax!oz
trt@rti.UUCP (06/22/83)
Too bad UNIX does not have an 'External Security' password option. I think it is very effective at stopping randoms. It could accept either the current or the previous password so changing the external password does not require a flag day. (Maybe all that is in system V?) Once a user is logged onto a typical UNIX system, there is little to keep him from becoming super-user. It may take some imagination, or some time (like waiting for a super-user to run your graciously provided 'find-security-holes' program), but a good Bad Guy will eventually win. Restricted Shells, an Anecdote One day Ken Thompson and Bob Morris were challenged to break a supposedly secure UNIX. They were given a login and password. They were put into a restricted shell. I mean restricted! It would not exec(II) anything. Not 'who', not 'pwd', not even 'date'. It did not allow '>' or '>>' or some other things. That rsh was so secure it was unusable. BUT!!! while read x do $x done < /dev/passwd printed out: root:PGqwGalLnSc0Q:0:3:God:/:: cannot execute (restricted) joe::0:3:Joe Nice:/usr/joe:: cannot execute (restricted) ... So they logged in as joe and got a normal shell. Then they started in earnest. Elapsed time to super-user--20 minutes. The moral of the story: Make sure the people who can log onto your system are people you can trust. If you cannot trust them, well, Gary Fostel had good suggestions about detecting and fixing break-ins but you are definitely in trouble. Tom Truscott
goldfarb@ucf-cs.UUCP (06/23/83)
If the unpassworded account that Thompson and Morris found (joe) had uid=0 and gid=3, just like root, why did they have to go any further? They became superuser when they logged in as joe. -- Ben Goldfarb uucp: ...!duke!ucf-cs!goldfarb ARPA: goldfarb.ucf-cs@Rand-Relay
trt@rti.UUCP (06/23/83)
Oh yuck, 'joe' was a normal user. My example was wrong. (I do not have any original records, so I reconstructed it from my own /etc/passwd, but was careless in doing it.) Of course, there *are* systems with that kind of gaping hole. The point of the story is the same in either case: It is almost impossible to restrict something as general as the shell. Tom Truscott
paulsc@tekecs.UUCP (06/26/83)
I know someone who chooses his password (at least he used to) by dropping his hands on the keyboard. I guess he could do it the same way every time (well, almost every time). He didn't have to worry about writing down his password (or someone getting his password by torturing him), because HE didn't even know what it was. Paul H. Scherf P. O. Box 1000 Del. Sta. 61-201 Tektronix Engineering Computing Systems Wilsonville, Oregon, USA UUCP: ...!XXX!teklabs!tekecs!paulsc (where XXX is one of: aat cbosg chico decvax harpo ihnss lbl-unix ogcvax pur-ee reed ssc-vax ucbvax zehntel) CSNET: tekecs!paulsc @ tektronix ARPA: tekecs!paulsc.tektronix @ rand-relay