jmc@ptsfa.PacBell.COM (Jerry Carlin) (07/06/88)
Somewhere I remember hearing or reading that someone did a study
about typical (bad) password choices and/or what consituted good
password choices. Can anyone give me references? Thanks in advance.
--
Jerry Carlin (415) 823-2441 {bellcore,sun,ames,pyramid}!pacbell!jmc
To dream the impossible dream. To fight the unbeatable foe.davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/06/88)
In article <4387@ptsfa.PacBell.COM> jmc@ptsfa.PacBell.COM (Jerry Carlin) writes: | Somewhere I remember hearing or reading that someone did a study | about typical (bad) password choices and/or what consituted good | password choices. Can anyone give me references? Thanks in advance. My suggestion is to chose a random sentence from a book and use the first letters. Alternatively, pick a sentence of your own. Example: passwd sentence iutpotm I use this password on this machine athwamw Atilla the Hun was a mighty warrior This makes it VERY hard for someone to look over your shoulder and steal a password, guess a password, etc. In addition, most people who have tried it find it is slightly easier to remember than a single word. My favorite password (from a system with 12 char passwords) sssiacosbikb some say security is a crock of shit but I know better If you type in an environment where someone might watch as you type, be sure you choose a password which can be typed reasonably quickly. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
jbn@glacier.STANFORD.EDU (John B. Nagle) (07/07/88)
About five years ago, I posted to the net an "obvious password detector",
a few pages of C intended for use in places such as "passwd" to detect an
attempt to use a password that could be guessed by the usual techniques.
(The algorithm worked by using the fact that the space of letter triples in
English is only 20% populated.)
If anyone still has this code, I would appreciate a copy; I no longer
have one.
John Nagleklee@daisy.UUCP (Ken Lee) (07/07/88)
I don't know of any formal studies, but I wouldn't be suprised if half
of all (user picked) passwords are permutations (approximately in order) of:
spouse's (or significant other's) name
user's name
children's names
pet's names
other relative's names
present or former addresses (street or city names)
I also wouldn't be suprised if almost all of the rest were found in the
smallest on-line "spell" dictionary.
A good password is, obviously, not in any of the above look-up tables.
Better still, it is changed regularly and composed of a variety of
characters (lower case, upper case, numbers, other printable characters,
and, if allowed, non-printable characters).
Enjoy.
Ken
--
uucp: {atari, nsc, pyramid, imagen, uunet}!daisy!klee
arpanet: atari!daisy!klee@ames.arc.nasa.gov
STOP CONTRA AID - BOYCOTT COCAINEaaron@proxftl.UUCP (Aaron Zimmerman) (07/07/88)
Aah, the eternal 'what do I use as a password' conflict. Well, whoever posted
message #366 (or was it 266? I think 366) seemed to have the right idea -
take a relatively random phrase, and use the first letters of each word (or
the last letters, or the second letters, or whatever turns you on).
Bad passwords, obviously, are: your name, your middle name, names of members
of your families, names of anyone at all; common computer words such as
"foobar", "unix", etc. also aren't so great.
Again, what that other person said about something you can type quickly is
good. At my school (when I'm not working here at Proximity, I'm a student of
SUNY@Stony Brook), many people take pleasure in obtaining passwords of others
for practical joke purposes.. I once guessed someone's zzyzx password despite
his typing it very quickly - it's an unusual pattern (including three z's and
an x, both of which are in a corner of the keyboard). It might be a safer
guess to go with generally more centrally-located keys (not necessarily only
using asdf and jkl;, but certainly staying away from, say, 31415).
Oh, yes, other unsafe passwords are numerical constants. I once thought
that it would be a good password to use the first sixteen digits of pi (on a
system of unlimited password length), but it's not good enough, since fingers
which stay on the top row are easily followed... Someone must have seen the
314 at the beginning, listened to count the number of keystrokes, and then
looked up the actual digits. (now, if I had deliberately changed the last
few digits to something else...) Seriously, though, I'd say that the first
letters of each word in a randomly selected phrase has to be the best idea
I've seen.
A little while ago I came up with an algorithm for my personal computer (I
used to own a Macintosh, though I'm about to sell it).... Living in a college
dorm, and one where computers aren't too commonplace (there was an Apple II
on my hall, and otherwise my roommate's 286 and my Mac were the only computers
on the hall), people liked to mess with our systems - play games, use the
word processors, etc. It started getting out of hand, so my roommate used the
keyboard lock, and I came up with password protection. Now, people could
guess my password, or watch me type it, perhaps... but it would be to no
avail, for I am a fast, and consistent, typer. How is that relevant? The
program I had running which asked for the password *timed the rhythm in which
the keys were typed*. This would be infeasible on a unix system, but on a
personal computer of reasonable processor speed it's not unreasonable.
After a certain number of trials it notes the mean times between keystrokes,
as well as the standard deviation. Upon entering the password later, I am
permitted one standard deviation of difference, and then, upon acceptable
entry, the new pattern ('cause it's not _exactly_ the same every time) is
averaged into the old trials, to compensate for changing trends in typing
speed. My roommate and I tested it out... we're both fast typers, and,
though we each only get in about 1 out of every 1.4 trials, neither of us
could log in as the other, even knowing what password to type. I consider
this method fairly secure, though a bit off the topic.
While I'm rambling, Lottery tickets:
An interesting observation I've made is that, since any particular
number is just as likely to win one week as any other number, it would make
the most sense to pick something unusual, in an attempt to avoid having to
share a prize in the event of a win. That is, many people pick dates as their
lotto 48 numbers. Logical, then, would be to choose something like 33, 35,
37, 39, 41, 43... Or even 43, 44, 45, 46, 47, 48 (though someone else might
be doing the same thing). One might say, "aw, come on, you know what the
chances of them all coming out sequentially are?", but the numbers chosen do
not affect odds of winning - saying they won't come out sequentially is a
fair guess, but it is a fair guess that any particular combination of numbers
will not happen, considering the miniscule odds of winning. I don't play the
lottery 'cause, in NY State, at least, it's the same thing as giving them $1
and being given back 41 cents - and that's only if you play a lot and you
don't get screwed by the odds. It just doesn't pay, but if other people wish
to toss their money away in the hopes of the [not impossible] financial
security they can win, it's their business. Besides, the lottery money does
[often] go to a good cause. Anyway, I suppose this should have been in a
different message, but it was on my mind 'cause people keep asking me, "oh,
you're a computer programmer... so can you come up with any lottery numbers
for me?" Aaargh. I'd better end this before I get flamed to pieces for posting
in the wrong place.
/ Aaron Zimmerman \ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
/ 3511 NE 22 Ave. \ : Working for Proximity Technology, :
< Fort Lauderdale > : but not speaking on their behalf. :
\ Florida - 33308 / : UUCP: uunet!proxftl!aaron :
\ (3,055,663,511) / -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-mahn@prandtl.nas.nasa.gov.nas.nasa.gov (Richard Mahn) (07/07/88)
There is a good article in LAN magazine on selection of passwords. I believe it is the July issue.
gallen@apollo.uucp (Gary Allen) (07/08/88)
In article <4387@ptsfa.PacBell.COM> jmc@ptsfa.PacBell.COM (Jerry Carlin) writes: >Somewhere I remember hearing or reading that someone did a study >about typical (bad) password choices and/or what consituted good >password choices. Can anyone give me references? Thanks in advance. > >-- >Jerry Carlin (415) 823-2441 {bellcore,sun,ames,pyramid}!pacbell!jmc >To dream the impossible dream. To fight the unbeatable foe. I remember the title of a book that I studied several years ago called "Cryptography and Data Security". I don't remember the author or publisher, but it was fascinating; lots of history of ciphers, spies, etc. Also, there was an article in (I think) a Bell journal that discussed the UNIX password mechanism. I think it was written by Ken Thompson. I can give you the jist. Bad passwords are short and/or chosen from a small alphabet. Consider a 3-character password chosen from the alphabet of lower case letters. An exhaustive attack on this password will succeed in (worst case) 26^3 (17576) attempts. At a rate of 1 attempt/second (which is *very* slow), this password will be broken in less than 5 hours. A 6 character password chosen from a 96 character alphabet (upper and lower case letters, numbers and special characters) require (worst case) 96^6 (nearly a trillion) attempts. At 1 attempt/second, this works out to about 25,000 years. Another type of attack makes use of the fact that passwords are not chosen at random. Rather, people tend to use their children's names, birthdates, etc. A clever cryptologist [sp?] will have a batch of the 200-300 most common names, 200-300 most common words (assuming the local language), all combinations of 3 digits, a few local cities and towns, several dozen dirty words, etc. Assuming 3000 of these goodies, 1 attempt/second requires less than an hour. If the encrypting scheme is known (which UNIX's is), these words can be encrypted in advance and simply compared to the encrypted passwords stored in the system in no time at all. Fortunately, UNIX is protected against this by a "salt" derived from the clock. At least the test cases must be encrypted from scratch for each password under attack. So, the general rule is to use a relatively long password (UNIX hints that it wants 6 characters or more) including characters from each section of the character set, avoiding common names and words, no birthdays or other all-numeric codes. Gary Allen Apollo Computer Chelmsford, MA {decvax,umix,yale}!apollo!gallen P.S. With the exception of a couple of ciphers developed in the last few years, every known cipher in history has been broken. That doesn't imply that the last few haven't, just that we don't know that they've been broken.
exodus@mfgfoc.UUCP (Greg Onufer) (07/08/88)
And aside from the password choices listed, also commonly used are keyboard patterns: qwerty, asdfg, etc. Please: DO NOT USE WORDS FOUND IN THE UNIX SYSTEM DICTIONARY. FOR THAT MATTER, PLEASE DO NOT USE REAL WORDS AS FOUND IN ANY DICTIONARY. I HAVE FIRST-HAND KNOWLEDGE OF A USER AT OUR SITE WHO MAILED OUR PASSWORD FILE TO A FRIEND, AND, WITHIN A WEEK, RECEIVED A LIST OF ALL THE PASSWORDS THAT WERE REASONABLE!!!! Commosense helps: use at least one digit, mix upper and lower case if your system allows you to. A digit in the middle of the word will effectively foul up any brute force dictionary-type search. Disclaimer: I disclaim. --Greg -- Greg Onufer GEnie: G.ONUFER University of the Pacific UUCP: -= Focus Semiconductor =- exodus@mfgfoc ...!sun!daver!mfgfoc!exodus (and postmaster/exodus@uop.edu) AT&T: 415-965-0604 USMAIL: #901 1929 Crisanto Ave, Mtn View, CA 94040
hollombe@ttidca.TTI.COM (The Polymath) (07/08/88)
In article <4387@ptsfa.PacBell.COM> jmc@ptsfa.PacBell.COM (Jerry Carlin) writes: }Somewhere I remember hearing or reading that someone did a study }about typical (bad) password choices and/or what consituted good }password choices. ... Suggested reading: UNIX System Manager's Manual On the Security of UNIX Password Security - A Case History I did some experimenting and reading on the subject a few months ago. Here's some suggestions: Bad choices: anything under 6 characters anything in the spell dictionary (or any on-line dictionary) anything in your /etc/passwd entry (especially name and login id) any publicly available personal fact or attribute Good choices: not a bad choice (-: include at least one punctuation (non-alphameric) character use both upper and lower case -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax|trwrb}!ttidca!hollombe
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (07/08/88)
Choosing good passwords is also aggravated by password aging. The problem is that the user is suddenly told to choose a new password immediately. A local program (which I can't share but someone out there could write easily) gives you a reminder when you login if your password is going to expire within a week. This gives you plenty of time to cook up a good password. -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (strange but true)
roy@phri.UUCP (Roy Smith) (07/08/88)
Nobody has yet mentioned the quasi-classic paper "Password Security:
A Case History" by Robert Morris and Ken Thompson. It's included in the
4.2/4.3 Unix documentation, and probably in most other Unix doc sets. While
not an authoritative research paper on the subject, it does have some good
suggestions. They give a short list of commonly used types of passwords,
including anything in the dictionary, possibly spelled in reverse, and valid
license plate numbers in your state. Obviously, any of the above are bad
choices.
Personally, I usually use some 6-8 letter word I can remember but
with a deliberate mispelling, often combined with an unusual capitalization
and/or a digit or two thrown in. Something like "graPHiks88". Easy enough
to remember, but hard to guess. If what you're worried about is somebody
watching over your shoulder while you type, the capitals and the digits don't
help much; they just stand out like a sore thumb. When assigning passwords
for incomming uucp accounts, I just type random patterns on the keyboard.
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"brianm@sco.COM (Brian Moffet) (07/08/88)
In article <377@mfgfoc.UUCP> exodus@mfgfoc.UUCP (Greg Onufer) writes: > >Please: DO NOT USE WORDS FOUND IN THE UNIX SYSTEM DICTIONARY. FOR THAT Actually, you can use words in the dictionary, as long as you mistype them. I have yet to see a password cracker look for the word foobar when it is typed fppnar (right hand off by 1 key). -- Brian Moffet brianm@sco.com {uunet,decvax!microsof}!sco!brianm The opinions expressed are not quite clear and have no relation to my employer. 'Evil Geniuses for a Better Tommorrow!'
markz@ssc.UUCP (Mark Zenier) (07/09/88)
In article <4387@ptsfa.PacBell.COM>, jmc@ptsfa.PacBell.COM (Jerry Carlin) writes: > Somewhere I remember hearing or reading that someone did a study > about typical (bad) password choices and/or what consituted good > password choices. Can anyone give me references? Thanks in advance. It's not a study, but has a good descrition of password pitfalls. Out of the Inner Circle Bill Landreth 1985, Microsoft Press ISBN 0-914845-36-5 Mark Zenier uunet!pilchuck!ssc!markz
master@uop.edu (The President) (07/09/88)
The VMS generates passwords which is a combination very hard to figure out. If anyone is interested in the list let me know and I'll mail it... -Nasser.
csg@pyramid.pyramid.com (Carl S. Gutekunst) (07/09/88)
In article <3375@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >When assigning passwords for incomming uucp accounts, I just type random >patterns on the keyboard. Or you can try this trivial little jewel. Output looks something like this: a[=lRCuV X4Bb<f?4 HkQE:LpE Suitable for grabbing and stuffing on a Sun or a 630. :-) <csg> _______________________________________________________________________________ /* * randpass.c -- generate really random passwords. For BSD Unixes only. * Includes all ASCII chars '0' through 'z', except '@' and '\\' */ #define PASSCHARS 8 main() { int i, c; char s[PASSCHARS+1]; long random(); srandom((int) time(0)); for (i = 0; i < PASSCHARS; ++i) { while ((c = random() % 75 + '0') == '@' || c == '\\') ; s[i] = c; } s[PASSCHARS] = '\n'; write (1, s, PASSCHARS+1); }
thad@cup.portal.com (07/10/88)
The following is something pertinent to your question regarding selection
of passwords. Because it IS of general interest, I'm posting it; don't
know if there ever was a followup, but the suggestions contained herein
are good advice nonetheless.
Enjoy!
thad@cup.portal.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
DDN-MGT-BULLETIN 18 NETWORK INFO CENTER for
13 Jan 1984 DCA DDN Program Mgmt Office
(415) 859-3695 NIC@SRI-NIC
Defense Data Network
MANAGEMENT BULLETIN
The DDN MANAGEMENT BULLETIN is published by the Network Information
Center under DCA contract as a means of communicating official policy,
procedures and other information of concern to management personnel at
DDN facilities. Back issues may be obtained by FTP from the directory
<DDN-NEWS> at SRI-NIC [26.0.0.73 and 10.0.0.51].
**********************************************************************
INTERIM GUIDANCE FOR HOST PASSWORD DISCIPLINE
(The following is issued as interim guidance with the intent of
issuing permanent mandatory guidance within six months. The
instructions in this Management Bulletin should be followed until
superceded. Your comments, criticisms, and recommendations for
improvement are welcome and should be submitted by netmail to
GPARK@DDN1.)
---------------
The past two years have seen an increase in the number of unauthorized
accesses to ARPANET/MILNET host computers. While many of these
penetrations have been relatively benign, there has also been an
increase in the number of malicious attacks. In response, some host
administrators have implemented effective password systems, while
others have not, leaving themselves vulnerable to the hacker
community.
Analysis of host penetrations reported to DCA has consistently pointed
to inadequate host password discipline as the primary weakness making
these break-ins possible. Some examples of improper password practices
which have permitted successful intrusion are:
Passwords which can be logically derived from the users name, such
as initials, middle names, parts of names, combinations, etc.
Passwords based on proper names (relatives, States, cars, boats,
ball teams, beers, etc.)
Null passwords (e.g., carriage return for password).
Unencrypted password files (where encryption is feasible).
Unlimited password attempts permitted without disconnection.
Considerable effort has been expended by DCA and by DARPA to develop
an effective network access control mechanism without denying required
services to legitimate users. The TAC Access Control System (TACACS)
Phase 1, an outcome of this effort, becomes operational on the MILNET
17 Jan 1984 with a universal User ID and Access Code (in the TAC
Herald) for familiarization purposes, and will be fully implemented
February 15, 1984.
TACACS is expected to effectively accomplish the task it is designed
for. It must not, however, be viewed as a complete solution to the
problem, since, as its name implies, it only protects against
intrusion via TAC ports. It provides no protection against
penetration via host backside dial-ins. TACACS is like a fence built
only around the front yard. It remains the responsibility of each
host to extend the fence around the backside. It is imperative that
host managers examine their facilities and implement the improvements
needed to correct the weaknesses discovered.
A survey of hosts which do have good password discipline reveals some
effective practices which can be applied elsewhere. Either of the
following two options are recommended as a minimum, with Option One
preferred.
OPTION ONE:
Discontinue the practice of allowing users to select their own
passwords, and, instead, issue passwords consisting of at least 8
alphanumeric characters. If possible, passwords should be machine
generated and distributed to preclude viewing by persons other than
the intended recipient. Disable routines which permit the user to
change his password once issued unless the changed password is also
machine generated. Change and reissue passwords at least annually.
It is recommended that passwords be pronounceable.
OPTION TWO:
Develop and implement a password filter routine which will be
automatically invoked whenever a password is changed, and which
will reject any unacceptable user selected password. When the
password filter is implemented, require existing passwords to be
changed to insure all passwords pass the test of acceptability. A
password may be considered acceptable if it does not fall into any
of the unacceptable password categories listed below.
UNACCEPTABLE PASSWORDS:
- Null passwords, i.e., carriage return for password
- Passwords of less than eight characters
- Passwords which can be found in the English dictionary
- Proper names for passwords
- Passwords which are permutations of the user's name, account
number, etc.
Anonymous/guest passwords, although acceptable, are discouraged on
most machines. Hosts which do allow this convention must insure
that adequate internal safeguards exist to limit usage to only that
which is intended.
Whichever of the two options above are chosen, all hosts should also
implement automatic routines to provide for the following.
- Provide 30 day advance notice of the password expiration date.
Coupled with the notice should be a message explaining to the
user the standards for password selection and the reasons for
requiring strict password discipline. Upon expiration of the
password the user should be allowed to log-in with the expired
password, but only for the purpose of changing the password.
- Encryption of password files is strongly encouraged on those
machines where, in the judgement of host managers, it will
produce a true gain in security.
- All unsuccessful log-in attempts (Server TELNET, Server FTP,
regular log-in, etc.) should be logged and periodically
reviewed. If the machine is attended by an operator, the
operator should be notified. A notice of unsuccessful attempts
should be published to the account user at the time of the
next successful log-in.
- Auto-disconnect should occur after no more than three unsuccess-
ful log-in attempts. This is regardless of the means of
accessing the machine.
It is a standing requirement that the DDN be used for official Federal
Government business only. Activities operating host computers on the
DDN must insure that utilization of their facilites, via the network,
meets this requirement. Netwide adoption of the standards and
practices requested in this bulletin will substantually reduce the
susceptability of individual hosts to successful penetration by
unauthorized users. Simultaneously, the opportunity for any given
host to be used as an avenue into the network for penetration of other
hosts will be correspondingly reduced.
-------END OF MESSAGE-------todd@uop.edu (Dr. Nethack a.k.a Race Bannon ) (07/10/88)
In article <377@mfgfoc.UUCP>, exodus@mfgfoc.UUCP (Greggie-boy Onufer) writes: > And aside from the password choices listed, also commonly used > are keyboard patterns: qwerty, asdfg, etc. > > Please: DO NOT USE WORDS FOUND IN THE UNIX SYSTEM DICTIONARY. FOR THAT > MATTER, PLEASE DO NOT USE REAL WORDS AS FOUND IN ANY DICTIONARY. I HAVE > FIRST-HAND KNOWLEDGE OF A USER AT OUR SITE WHO MAILED OUR PASSWORD FILE > TO A FRIEND, AND, WITHIN A WEEK, RECEIVED A LIST OF ALL THE PASSWORDS THAT > WERE REASONABLE!!!! Get it right, it was turnaround in 2 days tops! > Commosense helps: use at least one digit, mix upper and lower case > if your system allows you to. A digit in the middle of the word will > effectively foul up any brute force dictionary-type search. With mods, will run on metacharacters as well. You are just nervous that someone else might get into your files!! I wonder why?? (another story) Besides.. getting root here takes no longer than 5 minutes, if you know how. > Disclaimer: I disclaim. Disclaimer: this was'nt me! > exodus@mfgfoc ...!sun!daver!mfgfoc!exodus (and postmaster/exodus@uop.edu) > AT&T: 415-965-0604 USMAIL: #901 1929 Crisanto Ave, Mtn View, CA 94040 I guess you are happy, you are in mountain view now!
mparker@chip.UUCP (M. D. Parker) (07/11/88)
With all this talk about "good" passwords, might I suggest that you look
in a relatively short manual from the NCSC concerning Passwords. It gives
some interesting insights. If somebody here had not borrowed my NCSC manual
set, I could give you the number. When I got it the color was a nice Flor.
Green color (maybe called the Green Book?).
===============================================================================
M. D. Parker ARPANet: chip!mparker@nosc.mil
UNIX Systems Manager UUCP: ...{ucsd,nosc,hp-sdd,crash}!chip!mparker
Phone: (619) 457-2340
USPS: M/A-COM Government Systems, 3033 Science Park Road, San Diego, CA 92121
Disclaimer: Opinions expressed are my own and not necessarily that of
M/A-COM Government Systems Inc.inc@tc.fluke.COM (Gary Benson) (07/12/88)
Well, I got all security conscious reading about passwords, decided that
I'd better change mine. In doing so, however, it occurred to me that one
aspect of this discussion hardly ever gets mentioned: how to REMEMBER what
you've changed it to. Herewith a few ideas to start things off:
1. Don't change your password on a Friday unless you write it down and put
it in that secret compartment in your wallet.
2. If you write it down as a reminder, encode it somehow. For example, if
you choose the first letter of the words making up a sentence, write a
permutation of the sentence. Here's what I mean: say your password is
TitdwtLhm (This is the day which the Lord hath made), you could put on
your "TODO" list, "Remind Rev. Ike about psalm 37".
3. Use the same "style" of password. For example, you might use biblical
references one month, David Letterman quotes for a while, names of trees,
streets in New York City, parts of a flower, and so on.
Any other ideas about how to remember what you changed to? I seem always to
break my first rule and change it on a Friday. Monday morning comes and I'm
all set to login, and BANG - mental block because I never write it down.
--
Gary Benson -_-_-_-_-_-_-_-_-inc@tc.fluke.com_-_-_-_-_-_-_-_-_-_
Publication Services Ensign Benson, Space Cadet, Digital Circus, Sector R
John Fluke Mfg. Co. Inc. _-_-_-_{uw-beaver, sun,microsoft}!fluke!inc-_-_-_-_-and%eurotra.essex.ac.uk@nss.cs.ucl.ac.uk (Andy Holyer) (07/12/88)
In article <4387@ptsfa.PacBell.COM> jmc@ptsfa.PacBell.COM (Jerry Carlin) writes: | Somewhere I remember hearing or reading that someone did a study | about typical (bad) password choices and/or what consituted good | password choices. Can anyone give me references? Thanks in advance. The Trick I learned was: a) Pick a common word b) Append 2 or 3 random letters or (better) numbers to it. Thus something like "letter4z" or "waterqx4" - the logic is that snoopers will get the first few letters, but the random ones are then almost impossible to get (If you're quick with them). Here in Blighty, I find car registration numbers are good; for two reasons. One, you always know your reg. no. (the first thing the police do over here if the stop you is face you away from the car and ask for the reg. no - easy way to spot if you've stolen it), and two, the structure is almost exactly the above ( For those of you who don't know, British car no's are of the pattern: "{letter}{letter}{letter}{number}[number]{letter}" or (for the last few years): "{letter}{number}[number]{letter}{letter}{letter}" ... There is a quite good logic behind this - ask a brit if you're interested, but that's another story. I don't suppose that would work so well with all those customised amercian plates... ----- &ndy Holyer (and@uk.ac.essex.eurotra) (Usual disclaimers) "I'm sorry it wasn't a Unicorn. It would have been nice to have Unicorns" - Tom Stoppard
karl@haddock.ISC.COM (Karl Heuer) (07/13/88)
In article <4396@fluke.COM> inc@tc.fluke.COM (Gary Benson) writes: >Any other ideas about how to remember what you changed to? I use a different password on each of my major accounts. I have a program that, given N-1 of the passwords, will output the missing one. So I'm safe until I forget two passwords at the same time. (No, the program itself doesn't know my passwords. It only knows the XOR of a base-95 encoding of them. The source code and data file are readable.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
amlovell@phoenix.Princeton.EDU (Anthony M Lovell) (07/15/88)
I've always found the best password to be "lollipop" It's cute, 8 letters, keys very closely grouped.. a real winner. Don't tell anyone. -- amlovell@phoenix.princeton.edu ...since 1963. disclaimer: These are MY opinions. You only WISH they were yours.
rbj@nav.icst.nbs.gov (Root Boy Jim) (07/20/88)
? From: thad@cup.portal.com ? The following is something pertinent to your question regarding selection ? of passwords. Because it IS of general interest, I'm posting it; don't ? know if there ever was a followup, but the suggestions contained herein ? are good advice nonetheless. NBS also produced a password recommendation report, but I don't know what the number is or how to get it. Perhaps the following message was partially derived from it's input. I have a few comments on various parts: ? DDN-MGT-BULLETIN 18 NETWORK INFO CENTER for ? 13 Jan 1984 DCA DDN Program Mgmt Office ? (415) 859-3695 NIC@SRI-NIC [quoted in part] ? - All unsuccessful log-in attempts (Server TELNET, Server FTP, ? regular log-in, etc.) should be logged and periodically ? reviewed. If the machine is attended by an operator, the ? operator should be notified. A notice of unsuccessful attempts ? should be published to the account user at the time of the ? next successful log-in. Note: DO NOT log the attempted password! At least not to a file which is readable by casual users! Remember, superusers have fumble fingers too, and your log is likely to be filled with legitimate trivial permutations of the real passwords as well as random attempts to break in. For example, if your root password is `superman', what would do you think a regular user would try if he saw `supeman' and `supermam' in the log? ? - Auto-disconnect should occur after no more than three unsuccess- ? ful log-in attempts. This is regardless of the means of ? accessing the machine. A more fiendish approach is to set a flag after three attempts, and allow additional logins/passwords to be entered, but reject them even if valid. One must type a ^D to restart login, but the cracker doesn't know this. Other approaches have been to disable an account after repeated failures to log in. I am glad to see this recommendation missing. Suppose I don't like Fred. I make him unpopular with the sysadmins by intentionally attempting to log on as him and giving the wrong password. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!
cmiller@sunspot.UUCP (Charlie Miller) (07/20/88)
In article <717@amelia.nas.nasa.gov> mahn@prandtl (Richard Mahn) writes: >There is a good article in LAN magazine on selection of passwords. I >believe it is the July issue. Communications of ACM recently (I beleive it to be the April issue??, check the index) ran a very good article on computer security and typical methods used to "break in". The article was about someone in W. Germany that had gained access to a network of U.S. Gov. computers. It goes on to explain how the intruder was trapped. -charlie miller
JPLILER@simtel20.arpa (John R. Pliler) (07/20/88)
Why not use a *random* password generator? John Pliler -------
trt@rti.UUCP (Thomas Truscott) (07/20/88)
All the password generators that I have ever seen
can be broken by straightforward attacks.
Password generators are dangerous in the same way
that weak cipher systems are dangerous --
they create a false sense of security.
A truly *random* password generator would be fine,
the problem is that randomness is hard to come by.
Consider the typical password generating program:
srand(time((time_t *)0))); /* seed "random" number generator */
.... generate "random" password ...
srand (or srandom) accepts only a 32 bit seed,
which means this program generates *at most* 2^32 different passwords,
whereas DES accepts a 56 bit key.
So right off we have lost considerable "randomness".
(This type of problem is mentioned in a cryptic paragraph
in "Password Security -- A Case History" by Robert Morris and Ken Thompson.)
It is also very misleading to use srand/rand
since the time-of-day is our only source of randomness.
For example, the hexadecimal representation of the time-of-day
is 8 characters long and can be used directly as the generated password.
Please, never ever use srand/rand in a password generating program!
Much worse, the time of day is *highly* predictable.
If a password's creation time can be guessed within a few hours
it can be found out in just a minute or so of computation.
(This is particularly easy if one can periodically snapshot
the list of encrypted passwords.)
It is possible to do even worse -- one password generator
posted to Usenet produced only about 1000 different passwords.
One can do much better by using other semi-random
values such as the current tv_usec (gettimeofday), millitm (ftime),
process id (getpid), and so on. But that is not enough.
Try this: ask the user to press <interrupt>
and then perform a busy loop such as:
long count = 0;
while (!interrupted && ++count < HUGE)
;
/* (If count >= HUGE the user wasted too much cpu time. Retry.) */
/* (If the high-order bits are zero we did not loop enough. Retry.) */
/* low-order 16 bits of count are fairly random now */
Do this three times to obtain 48 semi-random bits.
XOR into that the various semi-random values mentioned above.
Now generate an 8 character long password by using 6 bits per character
("base-64" characters ala uuencode).
Post THAT to the net. Please. I promise I will use it.
Help stamp out bogus password generators!
Tom Truscottcmiller@sunspot.UUCP (Charlie Miller) (07/20/88)
In article <16562@brl-adm.ARPA> JPLILER@simtel20.arpa (John R. Pliler) writes: > >Why not use a *random* password generator? >John Pliler Because you can generate your own password that has meaning to *you* and is easy for you to remember, but appears random. -Charlie cmiller@sunspot.UUCP
maart@cs.vu.nl (Maarten Litmaath) (07/21/88)
In article <16554@brl-adm.ARPA> rbj@nav.icst.nbs.gov (Root Boy Jim) writes:
\One must type a ^D to restart login, but the cracker doesn't know this.
Hahahahahahahahahaha thud (Laughed my head off!)
--
I'd rather live in Russia |Maarten Litmaath @ Free U Amsterdam:
than in South-Africa... |maart@cs.vu.nl, mcvax!botter!ark!maartddb@ns.UUCP (David Dyer-Bennet) (07/21/88)
In article <16562@brl-adm.ARPA>, JPLILER@simtel20.arpa (John R. Pliler) writes: > Why not use a *random* password generator? Random passwords are hard to remember. If you inflict random passwords on people, many of them will write them down or post them near their terminal. If you inflict many DIFFERENT random passwords on people who must use multiple systems, they will CERTAINLY write them down. There are probably sufficiently sensitive applications where a random password changed daily is necessary, but these also require a special class of dedicated user. -- -- David Dyer-Bennet ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@viper.Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300
PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu (07/21/88)
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> writes >Note: DO NOT log the attempted password! At least not to a file...... >..... Yes - if its in a file, and the system is cracked it can be be removed, and (if the cracker is clever) all trace of the breakin lost. The place for this info is a permanent WOM (Write Only Memory) - I prefer a priniting console type device, with TWO copies, locked up in the machine room, Because if anyone gets physically to the powerswitch you are wide open any way, soo leaving a paper record there makes littl difference. I have detected and analysed three attempts at cracking our system. We could prove that it was a local hischooler who had once taken a BASIC class on Campus...using the console log. >? [...what to do with multiple login attempts...] >A more fiendish approach is to set a flag after three attempts... In May 1986 I published an article in the Communications of The Association for Computing Machinary (vol 29, No 5, pp416-417) on "Novel Security Techniques for Online Systems". In this I suggested the deliberate creation of a "Negative Security Zone" which is easy to get into, impossible to get out of (except by logging out) and provably secure. It has two main purposes: (1) Advertising (2) A Hacker Trap for repeated login attempts. The Unix implementation was carried out by an intern (John where are you??) and myself. I hacked up a /usr/contrib/sys/login.c program and John wrote the FREindly SHell (fresh). All guests run under 'fresh' - which is VERY easy to use (but with NO UNIX functionallity other than mail and local 'cat'). After three attempts the 'user' is logged in as an 'accidental guest' with user name 'a', read/write access to /usr/guest (ONLY) running under /bin/fresh. Consequence - the naive think they have broken in - and can do know harm. Users who have forgotten their passwords can mail the system administrator and beg for help. Wandering Gurus can make contact and be turned into friends rather than criminals. Local crackers/hackers with learn are fed advertising slogans as they play with the system. When the port selection hardware forgets things (we get lots of power outages) the system helps people who are talking to the wrong machine to get to the right one. Other refinements - 'root' can not log in. In fact the word 'root' is never visible to guests. Any attempt to login as root, whether even with the right password(!) is recorded on paper and rejected. Access to superuser powers is via 'su' and this has been hacked to report all 'su's to 'root' - good and bad. WE therefore have a continuous log of all the times that the system is open to abuse and who asked to abuse it - again on PAPER. Another - any 'login' that starts 'login' is spotted, 'help' gives help, 'where' prints out a description of the system and a map, 'when' runs 'data' as a shell, 'who' runs 'who', 'why' runs 'why' (why not?)... also we have 'status' as a pseudo login which does a UCB 'w'.... All these 'pseudo-users' are logged in as 'anon' and have a single (SIMPLE) command as a login shell. Consequence - No breakins for 2 years - and the number has been published (714-887-7365) nationally and locally for the most of that time... Hum -- I diddn't plan to say all that.... Dick Botting PAAAAAR@CCS.CSUSCC.CALSTATE(doc-dick) paaaaar@calstate.bitnet PAAAAAR%CALSTATE.BITNET@{depends on the phase of the moon}.EDU Dept Comp Sci., CSUSB, 5500 State Univ Pkway, San Bernardino CA 92407 Disclaimer: I am an only an egg
dunc%moria@Sun.COM (duncs home) (07/22/88)
In article <16562@brl-adm.ARPA> JPLILER@simtel20.arpa (John R. Pliler) writes: > >Why not use a *random* password generator? Because a typical user, given a meaningless password, will write it down lest it be forgotten. --Dunc
JPLILER@simtel20.arpa (John R. Pliler) (07/22/88)
cmiller@sunspot.uucp (Charlie Miller) wrote: >In article <16562@brl-adm.ARPA> JPLILER@simtel20.arpa (John R. Pliler) writes: >> >>Why not use a *random* password generator? >>John Pliler > >Because you can generate your own password that has meaning to *you* >and is easy for you to remember, but appears random. > -Charlie cmiller@sunspot.UUCP > Not all users are security conscious like you or I. Many users, particularly novices, choose *easy* passwords, such as flames, street addresses, telephone numbers, nicknames, common words. I've done this myself in the past. The random password generator prevents this. dave@csd4.milw.wisc.edu (David A Rasmussen) wrote: >I had obtained some code from someone a number of years ago that generated >8 letter random pronouncable gibberish passwords. I use a subset of this >code in our users initial passwords {and then they teach them in the >beginning users class that they can use the passwd command to change their >password to something easier to remember :-( } > >Perhaps if he reads this he may want to make a posting? > >nifcucta rirpolta fipnosto lutlogro (samples) > > You need to write another passwd program and incorporate a procedure to call the random password generator. (We have a nice piece of code that performs this task but I can't release it since it is *controlled*.) The password generator is really meant to be an *additional* security feature, not the only security feature. There are other features, many of which have been recently publicized in INFO-UNIX, which will provide even more peace of mind.. John R. Pliler Electronics Engineer White Sands Missile Range -------
rbj@nav.icst.nbs.gov (Root Boy Jim) (07/23/88)
? From: "John R. Pliler" <JPLILER@SIMTEL20.ARPA> ? Why not use a *random* password generator? Because you won't remember it and will write it down. ? John Pliler (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!
jmc@ptsfa.PacBell.COM (Jerry Carlin) (07/23/88)
In article <16595@brl-adm.ARPA> JPLILER@simtel20.arpa (John R. Pliler) writes: >>>Why not use a *random* password generator? Just make sure that the algorithm generates a LARGE number of possibilities and is not known. If someone gets it and it generates too small a number (such as 10 to the 10th) of possibilities someone can easily find out all your passwords. -- Jerry Carlin (415) 823-2441 {bellcore,sun,ames,pyramid}!pacbell!jmc To dream the impossible dream. To fight the unbeatable foe.
PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu (07/23/88)
>In article <16562@brl-adm.ARPA> JPLILER@simtel20.arpa (John R. Pliler) writes: >Why not use a *random* password generator? > -Charlie cmiller@sunspot.UUCP replied >Because you can generate your own password that has meaning to *you* >and is easy for you to remember, but appears random. Random passwords are not particularly memorable or typable. A nice random password generator should therefore provide a memorable meaning as well. Kurzban wrote a paper in the ACM SIGSAC Review called "Easily Remembered PassPHRASES - a better Approach" (Vol 3, Numbers 2 & 4, Fall-Winter 1985). (SIGSAC is the Association for Computing Machinary's Special Interest Group on Security, Audit and Control which publishes a periodical "Review") In essence the password can be the initial letters of a sentence generated by picking words in the correct grammatical categories and with the correct initial letters. When the system generates the password it looks up word to make a random phrase like (using a dictinary) Interns Stew dimples ballooning masterful Office-boys. (only better!). Nobody has gone the whole hog of using the fact that humans find obscene phrases the most memorable ones:-) I have never heard of a working version of this scheme and have not had time to test it out. Dick Botting PAAAAAR@CCS.CSUSCC.CALSTATE(doc-dick) paaaaar@calstate.bitnet PAAAAAR%CALSTATE.BITNET@{depends on the phase of the moon}.EDU Dept Comp Sci., CSUSB, 5500 State Univ Pkway, San Bernardino CA 92407 Disclaimer: What with my brain, my fingers, this Mac, Red Ryder, the PDP and its software, NOS and the CSU CYBERS, plus transmission errors, your machine, terminal, eyes, and brain,..... I probably didn't think what you thought you just read any way!
friedl@vsi.UUCP (Stephen J. Friedl) (07/24/88)
In article <16595@brl-adm.ARPA> JPLILER@simtel20.arpa (John R. Pliler) writes: > Why not use a *random* password generator? In article <4436@ptsfa.PacBell.COM>,jmc@ptsfa.PacBell.COM (Jerry Carlin) writes: > Just make sure that the algorithm generates a LARGE number of > possibilities and is not known. It is a better idea to use an algorithm that generates a very large number of possibilities and then make the algorithm known. To do otherwise places a burden on the implementor to keep the secret and makes this information valuable to a nasty person, thereby giving a challenge. Security by secrecy requires eternal vigilance. Steve -- Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl --------- Nancy Reagan on flood-control: "Just say Noah
peter@ficc.UUCP (Peter da Silva) (07/25/88)
I *like* random passwords. I still remember the ones I was given for my CS40 and CS41 accounts at Berkeley: aazjtcpg and hojkaqpl. I'm currently using a couple of random passwords on BBSes and don't have any more trouble remembering them than remembering phone numbers. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" (uunet,tness1)!sugar!ficc!peter.
andie@aipna.ed.ac.uk (Andie Ness) (07/27/88)
In article <653@sunspot.UUCP> cmiller@sunspot.UUCP (Charlie Miller) writes: >In article <16562@brl-adm.ARPA> JPLILER@simtel20.arpa (John R. Pliler) writes: >> >>Why not use a *random* password generator? >>John Pliler > >Because you can generate your own password that has meaning to *you* >and is easy for you to remember, but appears random. > -Charlie cmiller@sunspot.UUCP And since the random numbers are only pseudo-random, they can be easily re-created. According to the Unix System Managers Manual, it could take as little as 1 minute of CPU time to crack the system-generated passwords. --Andie. ------------------------------------------------------------------------------ ARPA: andie%ed.eusip@nss.cs.ucl.ac.uk andie%ed.aipna@nss.cs.ucl.ac.uk UUCP: ...!uunet!mcvax!ukc!eusip!andie JANET: andie@uk.ac.ed.eusip andie@uk.ac.ed.aipna ------------------------------------------------------------------------------
steve@oakhill.UUCP (steve) (07/27/88)
There are two stories about passwords which are probably just urban myths but are somewhat appropriate here. The first is about random passwords : At a location where random passwords were used, a programmer (I heard Kernigham when I was told) took his password, and on finding the random algorithm generated a set of the next n passwords which he could apply to every user on the system til he got in. This was done (as the story goes) as a demonstration of the falibity of random password generation. The second story also has to do with security, and I also heard abscribed to Kernighan (interesting his name pops up twice in related stories). It seems that in the original unix systems one of the programmmers left a backdoor in login that allowed him on any user system. This was left in the binary and not the source so that regenerating login would cure it, but since most original systems just copied the binary, this trap was left in. I don't believe either of these stories are true. In fact, careful anaysis shows that both are improbable; BUT it does show that we a too careless with security. I have done some consulting work on computter security; and I have yet to truely find a completely secure system. But the holes that one finds in the everyday system are inexcusable. We cannot hope looking the other way will solve these problems, and we should never think we have completely solved these problems. Your mooncalf - Steve
guy@gorodish.Sun.COM (Guy Harris) (07/28/88)
> The second story also has to do with security, and I also heard abscribed > to Kernighan (interesting his name pops up twice in related stories). > > It seems that in the original unix systems one of the programmmers > left a backdoor in login that allowed him on any user system. This > was left in the binary and not the source so that regenerating > login would cure it, but since most original systems just copied the > binary, this trap was left in. In his 1983 Turing award lecture, in the August 1984 CACM, Ken Thomson ascribes it to himself; the backdoor was actually in the C compiler (preprocessor, probably) - if it compiled itself, it stuck the backdoor in, and if it compiled "login", it stuck the other backdoor in. Thus, even if *did* regenerate "login", it wouldn't be cured, and even if you *did* have the source, you might never find it. He later ascribes the idea to an Air Force critique of an early Multics implementation; he didn't remember what the document was that contained the critique, and asked anybody who did know it to let him know.
ron@topaz.rutgers.edu (Ron Natalie) (07/28/88)
The classic trojan horse/backdoor was referenced by Ritchie in his Turing lecture. Dig through your ACM communications. Eric Allman provided us all a similar feature for sendmail. -Ron
ark@alice.UUCP (07/28/88)
In article <1406@devsys.oakhill.UUCP>, steve@oakhill.UUCP writes: > It seems that in the original unix systems one of the programmmers > left a backdoor in login that allowed him on any user system. This > was left in the binary and not the source so that regenerating > login would cure it, but since most original systems just copied the > binary, this trap was left in. > > I don't believe either of these stories are true. This one is, almost. Once upon a time, Ken Thompson changed three things in the system: 1. He inserted a back door in login. 2. He changed the C compiler to detect whether it was compiling login. If so, he made the compiler insert change #1 into the object code. He could now remove change #2 from the source code of login, leaving it impossible to tell by examining the source code that it had been changed. 3. He changed the C compiler to detect whether it was compiling the C compiler. If so, he made the compiler insert changes #2 and #3 (!) into the object code. He could now remove both changes #2 and #3 from the source code of the C compiler, leaving it impossible to tell by examining the source code that it had been changed. Notice the situation after he was done: he had a trap door in login, yet all the source code everywhere in the system was precisely what it had been before he started. Moreover, recompiling any part of the system would leave his trap door intact. To convince yourself that this story is not a myth, go through back issues of Communications of the ACM until you find the Turing Award lectures by Thompson and Ritchie.
dmt@ptsfa.PacBell.COM (Dave Turner) (07/29/88)
In article <Jul.27.21.25.20.1988.21583@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >The classic trojan horse/backdoor was referenced by Ritchie in his >Turing lecture. Dig through your ACM communications. Eric Allman >provided us all a similar feature for sendmail. Sorry but it was Ken Thompsom's lecture, "Reflections on Trusting Trust." It was in CACM Vol 27 No 8 August, 1984. -- Dave Turner 415/542-1299 {att,bellcore,sun,ames,pyramid}!pacbell!dmt
blu@hall.cray.com (Brian Utterback) (08/12/88)
In article <8073@alice.UUCP| ark@alice.UUCP writes: |In article <1406@devsys.oakhill.UUCP>, steve@oakhill.UUCP writes: |> It seems that in the original unix systems one of the programmmers |> left a backdoor in login that allowed him on any user system. This |> was left in the binary and not the source so that regenerating |> login would cure it, but since most original systems just copied the |> binary, this trap was left in. |> |> I don't believe either of these stories are true. | |This one is, almost. | [ Description Deleted] |Notice the situation after he was done: he had a trap door in login, |yet all the source code everywhere in the system was precisely what |it had been before he started. Moreover, recompiling any part of |the system would leave his trap door intact. | |To convince yourself that this story is not a myth, go through |back issues of Communications of the ACM until you find the |Turing Award lectures by Thompson and Ritchie. I think it was just Thompson. The key word here is almost. In the Turing lecture, this was presented as a scenario, not as a historical reference. It is clear after reading the article that what is done is a little beyond the state of the art in artificial intelligence. But only a little. After the lecture was entitled "Reflections on Trusting Trust" not "How I Broke Login". His point is that theoretically, to trust a program to be trap free, one must have verified it in the source for the program, all the previous source, the source for the compiler and all the previos source for the compiler. -- Brian Utterback |UUCP:{ihnp4!cray,sun!tundra}!hall!blu | "Aunt Pheobe, Cray Research Inc. |ARPA:blu%hall.cray.com@uc.msc.umn.edu | we looked like One Tara Blvd. #301 | | Smurfs!" Nashua NH. 03062 |Tele:(603) 888-3083 |
rick@seismo.CSS.GOV (Rick Adams) (08/13/88)
In article <8502@hall.cray.com>, blu@hall.cray.com (Brian Utterback) writes: > The key word here is almost. In the Turing lecture, this was presented as > a scenario, not as a historical reference. OK. Here is a historical reference that describes it as reality and not as a scenario. From research!dmr Thu Nov 4 02:30:06 1982 Subject: Joy of reproduction Newsgroups: net.lang.c Some years ago Ken Thompson broke the C preprocessor in the following ways: 1) When compiling login.c, it inserted code that allowed you to log in as anyone by supplying either the regular password or a special, fixed password. 2) When compiling cpp.c, it inserted code that performed the special test to recognize the appropriate part of login.c and insert the password code. It also inserted code to recognize the appropriate part of cpp.c and insert the code described in way 2). Once the object cpp was installed, its bugs were thus self-reproducing, while all the source code remained clean-looking. (Things were even set up so the funny stuff would not be inserted if cc's -P option was used.) We actually installed this on one of the other systems at the Labs. It lasted for several months, until someone copied the cpp binary from another system. Notes: 1) The idea was not original; we saw it in a report on Multics vulnerabilities. I don't know of anyone else who actually went to the considerable labor of producing a working example. 2) I promise that no such thing has ever been included in any distributed version of Unix. However, this took place about the time that NSA was first acquiring the system, and there was considerable temptation. Dennis Ritchie