The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1989)
DOCUMENT: Rutgers 'Security List' for May 1989 (79 messages, 33398 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1989/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 07:07:41 GMT
From:      waters@dover.sps.mot.com (Mike Waters)
To:        misc.security
Subject:   Re: MEDCO locks

>you can always rekey when an employee leaves (and it's
>pretty easy to do so if you use interchangeable-core cylinders).

Re-keying is also pretty cheap, it cost me $20 to change all seven locks
when I moved into my present house. Don't negelect the obvious and the
cheap solutions too!

-- 
*Mike Waters    AA4MW/7  waters@dover.sps.mot.com OR waters@cad.Berkley.EDU*
Mr and Mrs PED, can I borrow 26.7% of the RAYON TEXTILE production
 of the INDONESIAN archipelago?

-----------[000001][next][prev][last][first]----------------------------------------------------
From:      david paul hoyt <YZE6041@vx.acss.umn.edu>  2-MAY-1989 18:08:19
To:        security@pyrite.rutgers.edu
>How many seconds?  Does this rely upon a chip in the card keeping time
>accurate to within a number of seconds over an operating lifetime of
>possibly years? ...

  This isn't a problem really.  There are phone numbers you can dial to get
the correct time (international standards, inference clocks) accurate to
some fraction of a millisecond.  The macintosh pd program "setclock" uses
this mechanism to get the 'correct' time.  The card only needs to be able to
resync before connecting to the remote system (assuming the remote uses an
accurate clock as well).

  Alternatively, the card can sync with the remote as part of the handshake. 
After all trading times in clear text can hardly pose any kind of security
breach.

david | dhoyt@vx.acss.umn.edu | dhoyt@umnacvx.bitnet
-----------[000002][next][prev][last][first]----------------------------------------------------
From:      _David C. Kovar <daedalus!corwin@talcott.harvard.edu>  2-MAY-1989 19:35:29
To:        security@rutgers.edu
  I was tracing the phone wires in my house yesterday afternoon trying to
find out why my phone was "off-hook" when all of the phones were actually
hung up. Just before the lines enter my house I found a gray box labelled
"Telephone Network Interface". Curious, I opened the box to find two RJ-11
modular phone jacks with black connectors in them that were held in by
clips. I popped the clip, unplugged the plugs and plugged in a normal phone.
Lo and behold, a dial tone! I wandered around the neighborhood a bit and
found a few more of these boxes. Looks like you can wander around Boston
with a phone, plug into someone's circuit, and make as many phone calls
as you like. Who needs lineman's equipment?

-David C. Kovar
	Technical Consultant			ARPA: kovar@husc4.harvard.edu
	Office of Information Technology	BITNET: corwin@harvarda.bitnet
	Harvard University			MacNET: DKovar
						Ma Bell: 617-495-5947

"It is easier to get forgiveness than permission."
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 13:53:48 GMT
From:      silber@TCGOULD.TN.CORNELL.EDU (Jeffrey Silber)
To:        misc.security
Subject:   Access control & accounting

I am looking for accounting and access control software to run a
production Unix (tm) system (2000-3000 users).  If anyone has any
suggestions please send e-mail.  Thanks.

-- 
"A billion here, a billion there, and pretty soon you're talking real money."
                                                        --Sen. Everett Dirksen
Jeffrey A. Silber/silber@tcgould.tn.cornell.edu
Business Manager/Cornell Center for Theory & Simulation in Science & Engineering

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 20:02:14 GMT
From:      rogers@MARLIN.NOSC.MIL (Rollo D. Rogers)
To:        misc.security
Subject:   Re: car locks

hi, have you heard of the latest lock for vehicles here in S. Calif.
which is called the "Club".

If yes, what is your opinion as to how secure from theft a car with
this club locked onto the steering wheel would be?

  REgards, RollO~~

-----------[000005][next][prev][last][first]----------------------------------------------------
From:      "Michael J. Chinni, SMCAR_CCS_E" <mchinni@pica.army.mil>  3-MAY-1989  7:22:13
To:        security@pyrite.rutgers.edu
What we do:
  Our site is a government installation (DoD - Army). (1) dealt with verbally
  (i.e. those that need to know are told verbally). (2) the non-administrator
  doesn't get the password. The passwords are NEVER to be written down, under
  any circumstances.
Recommendations:
  What we might do if we did write down the password in a "book" would be to
keep this "book" in a combination-type safe. Only those people who were
authorized, in advance, as primary or alternate admins. (or bosses) would have
the combo. to that safe (that includes lock&key control as not have-ers).

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
			    Michael J. Chinni
      Chief Scientist, Simulation Techniques and Workplace Automation Team
	US Army Armament Research, Development, and Engineering Center
 User to skeleton sitting at cobweb    () Picatinny Arsenal, New Jersey  
   and dust covered terminal and desk  () ARPA: mchinni@pica.army.mil
    "System been down long?"           () UUCP: ...!uunet!pica.army.mil!mchinni
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
-----------[000006][next][prev][last][first]----------------------------------------------------
From:      steve@polyslo.calpoly.edu (Steve DeJarnett)  3-MAY-1989  8:10:16
To:        CHRIS@BROWNVM.BITNET, SECURITY@pyrite.rutgers.edu
	We deal with the need-to-know problem in a fairly simplistic way.
We keep our root password inside of a sealed (and taped-shut) envelope that
is stored in a lock-box.  Those people who might actually need to know it in
an emergency have a key to that lock-box.  The envelope is checked daily.  If
someone needs to know the password in an emergency, they must go into the
machine room, where the lock-box is -- only about 12 people have keys to this
room, and of those 12, only 8 have keys to the lock-box, and of those 8, 5 
already know the root password (whew -- what a great sentence :-).  From 
there, they must sign their name and write down the reason they took the root
password.  As soon as the system staff come in, the password is immediately
changed, and a quick audit is done of the file system (all automated in shell
scripts, so it's not too difficult).

	This does rely on the fact that you know everyone who has access to
the lock-box, and that they can be trusted to sign for the password when they
take it.  We've only had one problem with this, and that was when a new admin
on one of our smaller machines thought he had a valid reason to access the 
password, and did so.  When we came in, we found the machine in single-user
mode with no one in sight.  That operator was "re-educated", and we haven't
had any problems since then.

	It is important to make the envelope fairly tamper-resistant (we use
a thick manilla (opaque) envelope with a smaller envelope inside of it.  Both
are sealed, and the outer one is taped shut.  We've never had a problem with
someone trying to open it without being noticed.

	Another security feature you could add to make this safer is to have
a video camera trained on the lock-box and run it all day long.  If you had
any doubts about someone breaking in, just check the tape.

	Well, that's my $0.25 worth.

	Steve DeJarnett
	System Manager
	Cal Poly San Luis Obispo
	steve@polyslo.CalPoly.EDU
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 09:29:00 GMT
From:      SUNDSTROM@aboy2.abo.fi
To:        misc.security
Subject:   Re: MEDCO locks

>I have never seen any third party abloy clone
>keys, thereby making abloy your only source for key blanks.
 
 In Finland we have two different types of Abloy locks (or keys) one 
 'standard' and one with one or two security slots ("scores"). For the later
 one, duplicate keys are only obtainable from the factory with an authorized
 name signature (=signature of the person who bought the lock). The 'standard'
 key is obtainable from any locksmith. The Abloy locks here are absolutly
 most common locks a rought approx. is about 95 % of door locks

  Hans Sundstrom                     Internet: SUNDSTROM@ABOY2.ABO.FI
  Heat Eng. Lab. 
  Abo Akademi
  FINLAND  

[Moderator toss-in: Abloy originally started in Finland, I believe.  I just
recently had a longish talk with their Texas office...   _H*]

-----------[000008][next][prev][last][first]----------------------------------------------------
From:      deh@eng.umd.edu  3-MAY-1989 17:28:37
To:        34AEJ7D@CMUVM.BITNET
Cc:        security@pyrite.rutgers.edu
I agree that you should use whatever you can get your
hands on for illumination of code buttons; I mentioned 
laser dyes because I happened to have a lot of them around at
the time that I first tried this, and it worked very well.

Most of the dyes that I have used are pretty common, pretty cheap,
and to the best of my knowledge none of the ones that I have used
have been toxic....

One consideration in choosing the dye to use (for buttons, not for 
lasers) is what it looks like in regular light, since you don't 
want people seeing it on the buttons. ANother consideration is the 
method of application. One reason the laser dyes worked so well
was the fact that they were disolved in solvents, usualy alcohol
but also ether some times. In a spritzer bottle, these can be sprayed
on the target area where they will dry quickly, leaving a very fine
and uniform distribution of the dye material which is very likely
to escape detection. DO make sure that the solvent doesn't melt
the materials that the buttons, etc. are made of though.....

Doug
-----------[000009][next][prev][last][first]----------------------------------------------------
From:      "David F. Lambert" <LAMBERT@mitvma.mit.edu>  3-MAY-1989 18:13:42
To:        security@pyrite.rutgers.edu
You'll be better off *not* sharing passwords due to the problems you've
raised here as well as other problems that shared passwords can cause.
It is more desirable and auditable for you to be able to logon to
the "commonly shared" userid with other "authorized" passwords.  This
method has several advantages:

-provides auditability by requiring the "real" logon persons
 to identify themselves (via their password)
-allows you to change passwords of shared userids without contacting
 all users who logon to those userids (if you still need the "normal"
 logon password)
-makes encrypting passwords more feasible
-no need to memorize multiple passwords for various userids

Of course, this scheme does imply that more than the single standard
password can be used to logon.  If you're running VM, which your node
name suggests, VMSECURE implemented this scheme nicely in Release 3.2
I believe.  VMSECURE calls it the LOGONBY access rule.  I'm not sure
if RACF or other VM security package equivalents have this feature.
                                                                    -Dave
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 21:29:57 GMT
From:      haynes@UCBARPA.BERKELEY.EDU (Jim Haynes)
To:        misc.security
Subject:   Re: Telephone line security

These boxes replace the former lightning protectors.  Now that you
own, and are responsible for maintaining, the wiring inside your house,
the box provides a way for you to disconnect all your house wiring and
test the circuit at the phone company's demarcation point.  Otherwise
if you report trouble and they come out and find it's in your house
wiring they will charge you a lot for their time and trouble.
Just consider it one of the benefits of deregulation...

While it does make it a little easier for someone outside to make
calls on your phone line, the possibility was always there.  With
the older units the bad guy had to have alligator clips instead of
a modular plug on his phone, that's all.
haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ...ucbvax!ucscc!haynes

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle

-----------[000011][next][prev][last][first]----------------------------------------------------
From:      John Kinne <JDKINNE@MIAMIU.BITNET>  4-MAY-1989  6:07:23
To:        security@pyrite.rutgers.edu
To be effective, the number of people who know a pw must be kept to a minimum.
The small department that I am associated with insures that each member of
that small group is told the new pw, verbally, in a low voice.

>   how does a non-administrator get the password in an emergency?

That service is unavailable until a staff member can fix it.  We strive not
to have all members of the support staff absent on the same day.  When it is
necessary that the complete support staff be absent, then we leave forwarding
numbers.  If that doesn't work, then the service is unavailable.
-----------[000012][next][prev][last][first]----------------------------------------------------
From:      Lynn R Grant <Grant@dockmaster.ncsc.mil>  4-MAY-1989  8:18:09
To:        SECURITY@pyrite.rutgers.edu
The way to know make sure that everyone who needs to know knows when a
password changes is to have only one person per userid.  This also gets
you accountability.  As for data set passwords, if you have a good
access control system (like the ones my employer makes) you don't need
them; since the one userid/password scheme can assure that the person is
who he claims to be, you merely need to tell the access control system
who can get at what.  (Of course, for the accountability to work, you
need to do the ordinary stuff about not writing down the passwords, not
using your name, or your girlfriends name, or your social security
number, or whatever, etc.)

One approach to what to do when the security administrator isn't around
is to have a special security administrator userid whose password is in
a sealed envelope.  If your shop is a mainframe shop, you give it to the
night shift operations supervisor.  Otherwise you put it in a "break
glass" sort of box.  Every morning, the real security officer checks to
see if the envelope has been opened.  If so, he immediately changes the
password and investigates what was done with it.

There is some exposure here, since this is a detective control.  If you
don't have an access control system with good logging capabilities, you
won't know what was done with the special userid.  And if the person who
uses it is a very sharp crook, he may be able to wipe out the logging
anyway, if the userid in the envelope is powerfull enough.  But if you
can't afford to have full-shift security officer coverage, it works
better than giving everyone security privileges.

   Lynn R Grant
   Computer Associates International, Inc.
-----------[000013][next][prev][last][first]----------------------------------------------------
From:      jwright@atanasoff.cs.iastate.edu (Jim Wright)  4-MAY-1989  9:11:41
To:        misc-security@ames.arc.nasa.gov
The voting period for the new newsgroup comp.virus has just ended.
The final vote count was 403 YES, 30 NO.  I think it's fair to say
that significant interest has been shown in this group.  The list
of voters will be posted in news.groups so you may verify that your
vote was recorded.  I'll gladly accept any corrections, although
it would take a rather colossal error to affect the outcome of the
vote.

As per the "official guidelines", the group should be formed in
approximately five days.  (Today being 24-Apr-89.)  Look for it
soon at a computer near you.

There has been some interest in the mailng list virus-l.  Comp.virus
and virus-l will contain the same information, the only difference
being the method of distribution.  The following information should
assist you in subscribing to the list.  Note that it is NOT necessary
to subscribe to virus-l if you receive Usenet.  Also, if you receive
Usenet and subscribe to virus-l, you should unsubscribe once the
group comp.virus is formed.  There are currently about 1175 direct
subscribers to virus-l, so I'm sure Ken would appreciate the reduced
load.

> ... So, to get onto the VIRUS-L mailing
> list, send a mail message to <LISTSERV@LEHIIBM1.BITNET>. In the body
> of the message, say nothing more than SUB VIRUS-L your name. LISTSERV
> is a program which automates mailing lists such as VIRUS-L. 
> ...
> If, in the unlikely event, you should happen to want to be removed
> from the VIRUS-L discussion list, just send mail to
> <LISTSERV@LEHIIBM1.BITNET> saying SIGNOFF VIRUS-L.

Finally, we have been hard at work trying to organize a system of
anti-viral software archive sites.  Through the generous assistance
of the individuals at each site, this promises to be a great success.
We are still tying up some loose ends.  Look for a full announcement
of the archive system once comp.virus is in action.

-- 
Jim Wright
jwright@atanasoff.cs.iastate.edu
-----------[000014][next][prev][last][first]----------------------------------------------------
From:      shipley@tarantula.berkeley.edu (Pete Shipley)  4-MAY-1989 17:36:24
To:        misc-security@ucbvax.berkeley.edu
Question:
What problems will using a modified passwd des crypt function will create.

The idea I am tring to present is that if a system was to use a modified
version of crypt(3) (and install it in the libaries) and use it for the local
password file password enteries wont this prevent the grabing of
password files and 'grinding' on a local system.

				    -Pete
Pete Shipley: 
email: shipley@berkeley.edu		Flames:  cimarron@postgres.berkeley.edu 
       uunet!lurnix!shipley or ucbvax!shipley or pyramid!hippo!{ root peter }
Spelling corections: /dev/null                    Quote: "Anger is an energy"
-----------[000015][next][prev][last][first]----------------------------------------------------
From:      simsong@idr.cambridge.ma.us (Simson L. Garfinkel)  4-MAY-1989 17:55:09
To:        security@pyrite.rutgers.edu
This has gone far enough.

When I was in New York, I was living with a cocaine dealer who had a 
Medeco lock on her front door.  I wanted a spare key for my girlfriend,
but the landlady wouldn't give one to me.

I took the key to a tiny, Israeli locksmith near 98th street and Broadway.
He measuered the hights of each using a tool with a triangular hole in it
(with calibrations along the side), and wrote down the orientation of each
notch.  He then took a blank (that did not say "Medeco" on it) put it in
a machine and started cutting the key.  On each notch, he would change the
orientation of the blank in the machine, in accordance with the original.

The process took about 4 minutes and cost $5.00.  The key worked the first
time.

-simson
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 15:48:05 GMT
From:      kerchen@IRIS.UCDAVIS.EDU (Paul Kerchen)
To:        misc.security
Subject:   Re:  password security

>password.  As soon as the system staff come in, the password is immediately
>changed, and a quick audit is done of the file system (all automated in shell
>scripts, so it's not too difficult).

Hmm, what's the use in using shell scripts if they can be changed by
whoever last used the root password?  Or, do you keep these scripts off
line and just put them on the system when you need to make these checks?
If I were a nasty employee (not to imply that you have such people where
you are), I would get the password, do my damage, and then change the
script to something like:
	echo "Everything's okee dokee!  No reason to be suspicious!"
 	(or whatever the appropriate message is)
What's to stop this kind of nonsense?

Paul Kerchen				| kerchen@iris.ucdavis.edu

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 19:57:49 GMT
From:      gretzky@UNISON.LARC.NASA.GOV (Mr. Stanley Cup)
To:        misc.security
Subject:   System Security

Greetings to all you *net-landers*!

I have been recently assigned a task to investigate methods for enhancing
security on our "Super Computer Network" (1 Cray 3 Convex).  In addition
to this, I am supposed to "search and destroy" any security holes.
For instance:  Our convexes, being 4.2 based, had some *nasty* 4.2 bugs
with the set process group, writing to ttys, and chfn.

I am trying to compile a set of "test" programs that will check for these
and other security holes.  Could anyone give me a list of well known and
not so well known security holes for 4.2 and 4.3 BSD and System V (UNICOS).

Lists, explanations, code to exploit these holes will all be welcome and
very much appreciated.  Please *do not* post any code, but mail it directly
to me at one of the below addresses.

Any suggestions for security enhancement (not recently posted) would also
be appreciated.

Thanks Alot!

		   -=>gretzky<=-
.mitch

=================================
		   		|
gretzky@unison.larc.nasa.gov	|
root@unison.larc.nasa.gov	|
gretzky@eagle.larc.nasa.gov	|
gretzky@uxv.larc.nasa.gov	|
mitch@teb.larc.nasa.gov		|
				|
 =================================

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 18:08:21 GMT
From:      goldstein@star.DEC.COM (Andy Goldstein)
To:        misc.security
Subject:   Re: password security

> The idea I am tring to present is that if a system was to use a modified
> version of crypt(3) (and install it in the libaries)

Well, the problem is that by virtue of this mail you've now announced
to the world that you're running a modified crypt(3) (or might be). So
all the crackers have to do is take your version of crypt along with
your password file.

Your best bet is to convince your users (by moral suasion or,
preferrably, software) to not use dictionary words as passwords.

					- Andy Goldstein
					  VMS Development

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 01:23:00 GMT
From:      A01MES1@NIU.BITNET (Michael Stack)
To:        misc.security
Subject:   Re: password security

>                                                     ... I'm not sure
> if RACF or other VM security package equivalents have this feature.

"group logonids" are a standard feature of ACF2/VM and are intended to
provide accountability for the use of VMs like MAINT.

Michael Stack
Northern Illinois University

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 04:56:27 GMT
From:      rjg@sialis.mn.org (Robert J. Granvin)
To:        misc.security
Subject:   Re: Medeco Keys

Please realize the whole point is that Medeco locks and keys aren't
that they can't be duplicated, but that they are normally very
difficult to do so.  The vast majority of people wanting to make a
copy won't go through the effort to find someone as you described,
and if they did, they probably wouldn't have the same first time
success rate.  Doing so, depending on the environment where the key is
intended for, may show criminal intent.  You can't really say that
about your normal household locks you get from the hardware store.

On the other hand, picking a Medeco lock is again, significantly more
difficult than other locks.

Nothing is 100% guaranteed secure, but you can make the "average"
criminal go somewhere else and leave you alone.  This is generally the
goal.

The only way that you can prevent keys from being duplicated is don't
put a keyed lock on a door, and don't distibute keys for that lock
that doesn't exist.

-- 
________Robert J. Granvin________   INTERNET: rjg@sialis.mn.org
____National Computer Systems____   CONFUSED: rjg%sialis.mn.org@shamash.cdc.com
__National Information Services__       UUCP: ...uunet!rosevax!sialis!rjg

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      6 May 89 17:27:18 GMT
From:      jaw@SESUN.JPL.NASA.GOV (Joe Wieclawek)
To:        misc.security
Subject:   Computer hacker working on another plea bargain

An article in the 6 May 1989 'Los Angeles Herald Examiner' reports:

   Attorneys said yesterday they are negotiating a second plea
bargain for computer hacker Kevin Mitnick, whose first offer
to plead guilty was scuttled by a judge because it called
for too little time in prison.
   Mitnick, 25, of Panorama City (CA) offered in March to serve
one year in prison and to plead guilty to computer fraud and
possessing unauthorized long-distance telephone codes.

-----------[000022][next][prev][last][first]----------------------------------------------------
From:      simsong@idr.cambridge.ma.us (Simson L. Garfinkel)  9-MAY-1989 21:24:34
To:        security@pyrite.rutgers.edu
Friends,
	I've received over 20+ messages asking for a copy of the article.
I'm happy to post a copy of it if I retain the copyright (I don't know
if whole earth review lets me do that or not.)  Please don't send me any
more requests for copies.

	Thank you.

-simson
-----------[000023][next][prev][last][first]----------------------------------------------------
From:      waters@dover.sps.mot.com (Mike Waters)  9-MAY-1989 22:14:08
To:        misc-security@uunet.uu.net
>you can always rekey when an employee leaves (and it's
>pretty easy to do so if you use interchangeable-core cylinders).

Re-keying is also pretty cheap, it cost me $20 to change all seven locks
when I moved into my present house. Don't negelect the obvious and the
cheap solutions too!

-- 
*Mike Waters    AA4MW/7  waters@dover.sps.mot.com OR waters@cad.Berkley.EDU*
Mr and Mrs PED, can I borrow 26.7% of the RAYON TEXTILE production
 of the INDONESIAN archipelago?
-----------[000024][next][prev][last][first]----------------------------------------------------
From:      Victoria Landgraf <VLANDGRAF@eagle.wesleyan.edu>  9-MAY-1989 23:14:32
To:        SECURITY@pyrite.rutgers.edu
On the subject of hard-to-copy keys, Russwin makes blanks that they don't sell
to your corner hardware store; and when you try to get such keys copied at a
locksmith's, s/he looks at you funny and says "That's a restricted blank; I
don't carry it; you have to get it copied where you got the original."  I
assume this is a fairly standard tactic among lock companies who want to be
able to market a "high-security" line without doing much real work. On the
bright side, there's nothing particularly special or complex about a Russwin
key, so there's always brickstrap...

                                                     Victoria
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 22:32:21 GMT
From:      hazel%unm-la@LANL.GOV (AIDE Hugh Hazelrigg)
To:        misc.security
Subject:   orange book

About a week ago someone posted an article to misc.security which had some info
on where to find the "Orange Book."  Well, someone named Danny at the Federal
Information Center had never heard of the "National Computer Security Center 
[publications office]" (which was the name of the source in the posting), nor 
the Orange Book nor Rainbow Set.  He sounded like he really wanted to help, 
but needed more information.  Can you or anyone in m.s provide it?

Thanks in advance.
Hugh

[Moderator note:  "Dunno" -- can anyone else clarify for him?   _H*]

-----------[000026][next][prev][last][first]----------------------------------------------------
From:      SUNDSTROM@aboy2.abo.fi  10-MAY-1989 17:34:23
To:        security@pyrite.rutgers.edu
>I have never seen any third party abloy clone
>keys, thereby making abloy your only source for key blanks.
 
 In Finland we have two different types of Abloy locks (or keys) one 
 'standard' and one with one or two security slots ("scores"). For the later
 one, duplicate keys are only obtainable from the factory with an authorized
 name signature (=signature of the person who bought the lock). The 'standard'
 key is obtainable from any locksmith. The Abloy locks here are absolutly
 most common locks a rought approx. is about 95 % of door locks

  Hans Sundstrom                     Internet: SUNDSTROM@ABOY2.ABO.FI
  Heat Eng. Lab. 
  Abo Akademi
  FINLAND  

[Moderator toss-in: Abloy originally started in Finland, I believe.  I just
recently had a longish talk with their Texas office...   _H*]
-----------[000027][next][prev][last][first]----------------------------------------------------
From:      hollombe@ttidca.tti.com (The Polymath)  10-MAY-1989 18:39:19
To:        misc-security@sdcsvax.ucsd.edu
}WIEGAND is by far the best card technology that is available today

We here at the CAT factory have a different view.  We've always thought
our Magic Middle cards were the best technology. (-:

}... WIEGAND cards work
}by having a thin bi-metal wire embedded in the card.

Sorry, I can't talk about how our cards work.  I can tell you your
Cyclotron Analyser wouldn't affect them.  I've also seen one cut in half
and taped back together and it still worked.  Legend has it one hotshot at
Cal Tech was able to crack their encoding.  We hired him. (-:

-- 
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}!ttidca!hollombe
-----------[000028][next][prev][last][first]----------------------------------------------------
From:      simsong@idr.cambridge.ma.us (Simson L. Garfinkel)  11-MAY-1989  3:57:38
To:        daedalus!corwin@talcott.harvard.edu
Cc:        security@rutgers.edu
Indeed, this is why I keep a lock on my Network Interface.
		Simson Garfinkel
-----------[000029][next][prev][last][first]----------------------------------------------------
From:      haynes@ucbarpa.berkeley.edu (Jim Haynes)  11-MAY-1989  4:36:30
To:        misc-security@ucbvax.berkeley.edu
These boxes replace the former lightning protectors.  Now that you
own, and are responsible for maintaining, the wiring inside your house,
the box provides a way for you to disconnect all your house wiring and
test the circuit at the phone company's demarcation point.  Otherwise
if you report trouble and they come out and find it's in your house
wiring they will charge you a lot for their time and trouble.
Just consider it one of the benefits of deregulation...

While it does make it a little easier for someone outside to make
calls on your phone line, the possibility was always there.  With
the older units the bad guy had to have alligator clips instead of
a modular plug on his phone, that's all.
haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ...ucbvax!ucscc!haynes

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
-----------[000030][next][prev][last][first]----------------------------------------------------
From:      nichols@cbnewsc.att.com (robert.k.nichols)  11-MAY-1989  5:23:25
To:        mmm@cup.portal.com
Cc:        security@rutgers.edu
I have one of these "CIA letter openers" made by A. G. Russell,
Springdale, Ark.  I got it as a freebee with an order.  I consider it
just a novelty.  It's pretty ineffective as a knife and too bulky for
opening letters.  The info sheet that came with it suggested that it
could also be used as a tent peg.  That's about the best use I can think
of for it.

Yes, it undoubtedly would pass through a metal detector (but, I am
warned, it is NOT invisible to X-ray).  If you wanted to sneak something
onto an airliner, though, you'd be better off carrying a sharpening
stone and using it to hone the cutlery that comes with the "food."

-- 
.sig included a no extra charge.           |  Disclaimer: My mind is my own.
Cute quotes and batteries sold separately. |
>> Bob Nichols   nichols@iexist.att.com << |

[Moderator tack-on: American Airlines has pretty nasty-looking butter knives,
that probably wouldn't require too much additional work to be destructive.
On a recent round trip I pocketed mine on the way to, and on the way from
took it through security and put it in the little metal-things-you're-carrying
bucket.  They looked real funny at it and wondered why I was carrying it
until I pointed out the little "AA" logo engraved into the blade, and told
them I was bringing it back.  They then let me through with it.   _H*]
-----------[000031][next][prev][last][first]----------------------------------------------------
From:      steve@nuchat.uu.net (Steve Nuchia)  11-MAY-1989  5:41:35
To:        misc-security@uunet.uu.net
A client has a small network of Suns that they would like
to connect to the internet.  They would accomplish this
by bridging to the ethernet operated by the umbrella
organization of which they are loosely a part.  They
have limited experience with this style of networking,
having transitioned from VMS/THEnet only recently.  They
are very concerned about security.  Not spooky, just
the normal desire to have the system continue to work
most of the time.

The system is a 3/280 + 4 diskless Sun3 clients; some 386i
stuff will be attached soon.  All running SunOS4.0.1.
The environment is quasi-academic, with lots of students
hanging around.  The attack scenarios we are most concerned
with are the typical things you see at schools rather than
sophisticated industrial espionage attacks.

I haven't been through this before.  I know a bit about
security in general and securing a regular timesharing
sort of system, but all the networks (and especially
NFS systems) I've been responsible for have been isolated.

I would appreciate any advice you might have to offer.
Something like a checklist of things to button up or
turn off seems a good goal, but priciples, platitutes,
and references are also welcome.  Ultimately I would like
to have enough information to be able to tell my client that
his system is safe to connect.

Please send me mail -- my system is expiring news more
often than I can get home to read it.  I will condense the
suggestions I receive and post a summary.  Thank you.
-- 
Steve Nuchia	      South Coast Computing Services
uunet!nuchat!steve    POB 890952  Houston, Texas  77289
(713) 964 2462	      Consultation & Systems, Support for PD Software.
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 13:17:00 GMT
From:      WHMurray@DOCKMASTER.NCSC.MIL
To:        misc.security
Subject:   Sharing of Passwords

>To be effective, the number of people who know a pw must be kept to a
>minimum.  The small department that I am associated with insures that
>each member of that small group is told the new pw, verbally, in a low
>voice.                   

(I am unable to tell whether this posting is "tongue-in-cheek."  I will
assume that it is intended to be sincere.)

In order to be effective a password must be known by no more than one
person.  In the kind of open systems in which we deal (i.e., with many
privileged users), the only way to be sure that it is known to only one
person is to use it only once.

The solution to this dilemma, dealt with many times in this forum in
One-time password generators.  This mechanism also provides for the
passing and withdrawing of high privilege, since, unlike a password, the
generator can be returned.

(The discussion by the "secure" installation where five people know the
root password and another copy is kept in a lock box is too absurd to
deal with.  If a system is so unstable that it takes five people with
privilege to keep  it up, it cannot be said to be secure in any
meaningful sense anyway, but if five people share the password any way,
then how you protect and account for the use of any copy is not
material.)

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114                          
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840                

-----------[000033][next][prev][last][first]----------------------------------------------------
From:      silber@tcgould.tn.cornell.edu (Jeffrey Silber)  11-MAY-1989 22:59:15
To:        misc-security@rutgers.edu
I am looking for accounting and access control software to run a
production Unix (tm) system (2000-3000 users).  If anyone has any
suggestions please send e-mail.  Thanks.

-- 
"A billion here, a billion there, and pretty soon you're talking real money."
                                                        --Sen. Everett Dirksen
Jeffrey A. Silber/silber@tcgould.tn.cornell.edu
Business Manager/Cornell Center for Theory & Simulation in Science & Engineering
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 16:11:14 GMT
From:      biocca@BEVB.BEV.LBL.GOV (Alan Biocca)
To:        misc.security
Subject:   Re: MEDCO locks

Rekeying isn't difficult or expensive to do yourself, either.  I recently
bought a $20 kit for schlage rekeying at the local Home club.  It comes
complete with instructions and some tools, all you need is screwdriver and
pliers.  Re-keying requires that you have both new and old keys, so it works
best if you have a collection of keys to pick from when rekeying.  You could
file a key and make a new one, too.  There is a gauge included that could
be used to determine when the filing had reached a new 'standard' depth.
The kit also includes a large quantity of each standard pin size as well
as replacement springs in case they get lost or lose their force.  I've done
fifteen or twenty locks now and since you exchange pins rather than lose them
you can almost handle an indefinite number of locks.  Eventually you'll run
out of a particular size and have to buy more of them or a new kit.

Comments by Alan K Biocca

-----------[000035][next][prev][last][first]----------------------------------------------------
From:      ns@maccs.mcmaster.ca (Nicholas Solntseff)  12-MAY-1989 19:15:22
To:        misc-security@gpu.utcs.utoronto.ca
I have been told by someone in Export Controls in the Pentagon that letting
a non-Canadian student (e.g., from the PRC or Poland) use a DES program is
legally the same as exporting!  Thus, a copy of Dbase III labelled 
"Not for export" cannot be used in an open lab here.

Nick .....
-----------[000036][next][prev][last][first]----------------------------------------------------
From:      "S.J.Leviseur" <sjl@ukc.ac.uk>  12-MAY-1989 19:42:14
To:        misc-security@kestrel.ukc.ac.uk
>(5) Suppose you take DES binary out and some smart European puts it
>    back in, over there?         

As I understand it the terms of the AT&T licence says that I am entitle
to use code from all previous releases of Unix. Since I have (legitimately)
the DES code from 32V dose this mean that any SysV source code holder
can be given it?

	sean
-----------[000037][next][prev][last][first]----------------------------------------------------
From:      Rich Salz <rsalz@bbn.com>  12-MAY-1989 20:57:36
To:        hal@gateway.mitre.org
Cc:        misc-security@uunet.uu.net
Hi.  A similar question came up in the Usenet newsgroup comp.unix; this
is what I wrote.  My interest goes back three years when I posted a DES
package to world-wide distribution and got scared.
	/r$
PS:  Any other DES-legal discussion in misc-security I can FTP?

---------------------------------
Newsgroups: comp.unix
Subject: Re: DES software

>I need to find a copy (or, preferably, a summary written in English instead
>of legalese) of the American regulations that restrict the export of DES and
>other cryptographic software.  Does anybody know where I can find this?

Let me start with a disclaimer:  I'm speaking only for myself here, most
definitely not for my employer or anyone else I refer to below, and only
as an interested layman.

You will not be able to find a non-legalese summary.  (Hubris makes me
want to add "other than this one." :-)  You will only be able to find
legalese rules and such.  Your best bet is to hunt through a law library
and a one that has the US Federal Register.

There are two popular researched analyses on DES that were distributed on
Usenet.  One is by John Gilmore, the other is by DEC's Corporate Law
Office.  Lots of other opinion and "facts" have been offered, but almost
without exception they have been based on ignorance; unless you've done
research, or have the two primary sources, it's probably safe to ignore
everything you've read other than this.  (There's that hubris again.)

DES export is a complicated issue, and like all legal issues when you
get an opinion you should keep in mind the viewpoing of the person who
gives it.  John wants to spread open information as widely as possible,
DEC doesn't want to get hauled into court.  I agree with John.

>From his readings of the rules and regulations, John determined that
DES is technical information, and software.  This means that it is under
the control of the Department of Commerce.  As such, once it is in the
open literature, it can be passed around the world.  In terms of Usenet
and distributing source, this might mean someone would first have to
publish their code in a journal somewhere.  The only exception to this is
if you're on a small list of banned countries, and even that might not
hold.

DEC claims that John is wrong, that DES is specifically called out as
munitions, and therefore is under the control of the Department of
Defense, specifically the Munitions Control Act.  The upshot is that
you can't give it outside of the USA.  I'm not a lawyer, but the took
John's analysis apart sentence by sentence, ending with "It is imperative
that no Digital employee act in reliance on Gilmore's analysis or his
conclusions."  They even used SCREAMING all-caps.

Since neither Department is an expert, the NSA acts as the technical
advisory expert.  Based on a couple of phone calls, chats with some
former employees, and a DES-related meeting, the NSA's position is that
DES should not leave the country.

Because of this, many Unix vendors have two versions of their software,
and it depends on whether they ship the DES cryptographic stuff or not.
I remember reading a note from one of the Unix originators, that the only
reason there were two versions of Version 7 was more administrative than
legal.  Perhaps if someone back then was able to fight the red tape we'd
be spared all this mess today, perhaps not.  I've heard Amdahl got the
right permissions to export DES, but I don't know for sure; it was only
"planned" at the time I read that note, they may have backed down.

DES export has been discussed, at times, in sci.crypt, and in the Kerberos
and Internet Engineering Task Force mailing lists.

Switching from reporter to interpreter, let me say that I think the
situation is changing, and that the stupid US rules may -- applicable or
not -- may be lifted soon.  Note that soon is measured on a beaurocratic
time scale, which is similar to geologic time.  The technical community,
in particular the Internet, has a good channel into the Department of
Defense, and the right word seems to be reaching the right people.  There
is a need for DES to be used globally, and there has been world-wide
publication (in comp.sources.unix/unix-sources) of a package written in
Finland, posted from Australia.

I no longer have John's analysis at all (it was mostly private email, that
he later posted), and I do have the DEC analysis.  I don't like to
distribute it since it has the look of a DEC internal thing (even though
it was forwarded, second-hand, to sci.crypt), and especially since I don't
have John's work.  It is, however, interesting reading, and if someone is
going to take up the fight (as opposed to just idle curiousity), let me
know.

If you want to play lawyer, here are some places to start:
	Department of State
	You want sections 120-126, at least, of the International
	Traffic in Arms Regulation 22C.F.R Subch. M (I don't
	know what that last part means.)

	Office of Munitions Control, Department of State
	They're responsible for saying if something is "munitions."

	The National Security Agency
	I've heard their DES tech expert left, and they're in
	the lurch.  It's funny the way the answer their phones.

	Department of Defense
	You want Section 38 of the Arms Export Control Act.

	Department of Commerce
	You want the Commodity Control List, and
	Export Administration Regulations, Section 370.10
	and 379.3 (General License GTDA).

I like to know what's going on, and I seem to be in touch with the several
areas where this is discussed, so if you start digging around, I'd like to
know.  Yes, that means I'm offering to be a "point man" on this.

	/rich $alz

PS:  if ANYONE has a copy of John's research, please let me know; I'll
pay you for a copy.
-----------[000038][next][prev][last][first]----------------------------------------------------
From:      Sean Casey <sean@ms.uky.edu>  13-MAY-1989  5:31:15
To:        security@rutgers.edu
>I'm trying to find out what's going on with US DES export laws:

No problem. A guy in Finland or somewhere wrote a version of DES, which
was posted to comp.sources.unix with worldwide distribution. Since it
originated outside the US, it does not fall under the export restriction
laws.

It is a verified version of DES.

Sean
-- 
***  Sean Casey                         sean@ms.uky.edu, sean@ukma.bitnet
***  Quid, me vexari?                   {backbone|rutgers|uunet}!ukma!sean
***  ``A computer network should be considerably faster than a calendar.'' -me
-----------[000039][next][prev][last][first]----------------------------------------------------
From:      kerchen@iris.ucdavis.edu (Paul Kerchen)  13-MAY-1989  6:15:17
To:        security@pyrite.rutgers.edu
>password.  As soon as the system staff come in, the password is immediately
>changed, and a quick audit is done of the file system (all automated in shell
>scripts, so it's not too difficult).

Hmm, what's the use in using shell scripts if they can be changed by
whoever last used the root password?  Or, do you keep these scripts off
line and just put them on the system when you need to make these checks?
If I were a nasty employee (not to imply that you have such people where
you are), I would get the password, do my damage, and then change the
script to something like:
	echo "Everything's okee dokee!  No reason to be suspicious!"
 	(or whatever the appropriate message is)
What's to stop this kind of nonsense?

Paul Kerchen				| kerchen@iris.ucdavis.edu
-----------[000040][next][prev][last][first]----------------------------------------------------
From:      *Hobbit* <hobbit@pyrite.rutgers.edu>  13-MAY-1989  6:22:38
To:        security
I've often advocated the following around our shop, but nobody else wanted to
bother with it: Administrators would normally be non-privileged, just like any
other user, but they'd be able to run a magic program that accepts a
*different* password that is unique to the person [taken from /etc/magicpasswd
or some such], and if correct drops a root shell [privileged job for non-unix
folks] on their terminal.  We currently have such a magic program, but it
doesn't ask for a password.  Okay, so you have to remember an extra password,
but BFD.  Unfortunately this still doesn't prevent someone from trojan-horsing
your .cshrc or other init files, but it does prevent someone random from
finding a terminal you left logged in by mistake and whomping all over the
system right then.  Now, the remaining question is, whether it asks for a
password or not: how do you tell before invoking such a thing if you've been
trojan-horsed for the next time 'round after something like that happens?  You
certainly aren't going to want to sit there and read over your own login init
every time you want to do something privileged.  Answer a is, of course, don't
leave yourself logged in on a public terminal; answers b, c, d..  are left to
the reader.

On a vax I ran a while back I had a fairly elaborate mechanism which would
checksum as many of the various init files that the privileged job would invoke
that I could find; and if any of them failed it would yell loudly.  Said
mechanism was protected from prying eyes; it had a separate built-in password,
etc, etc. and was probably far more than anyone would normally want to deal
with.  Naturally, I'd have to go update the mechanism whenever I updated my
init files.  But by throwing up enough firewalls, even for myself [and typing
the appropriate things needed quickly became microcoded into my fingers] made
the machine quite a bit more secure.

_H*
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 04:54:02 GMT
From:      steve@POLYSLO.CALPOLY.EDU (Steve DeJarnett)
To:        misc.security
Subject:   Re:  password security

>Hmm, what's the use in using shell scripts if they can be changed by
>whoever last used the root password?  Or, do you keep these scripts off
>line and just put them on the system when you need to make these checks?

	The version I use to check things lives in my bedroom at home.  If
these people can break into my house and modify the tape, then I guess I have
larger problems than system security :-|.

	The fact that few people (until I sent this note out :-) knew that
such scripts even existed makes it a little less likely that they'd be found
(they also live so far down in the filesystem that I occasionally have trouble
remembering where they are).  When we do check the system, though, we either 
make a visual check of the scripts before running them, or bring my tape in 
from home.  Of course, University security requirements aren't QUITE as 
stringent as those required by, say, the DoD.

	Steve DeJarnett
	Cal Poly San Luis Obispo
	steve@polyslo.CalPoly.EDU

-----------[000042][next][prev][last][first]----------------------------------------------------
From:      Clive Dawson <AI.CLIVE@mcc.com>  16-MAY-1989 13:04:22
To:        steve@polyslo.calpoly.edu
Cc:        CHRIS@BROWNVM.BITNET, SECURITY@pyrite.rutgers.edu
I'm always amused by the notion of "tamper-resistant" envelopes.  I
would hope that your scheme includes some means of authenticating
the original envelope.  What would prevent somebody from tearing open
the envelope(s) and placing the contents into identical envelopes
sealed in the same careful manner, etc.  Are you using sealing wax
and a secret signet ring?  :-)

Clive
-------
-----------[000043][next][prev][last][first]----------------------------------------------------
From:      Mr. Stanley Cup <gretzky@unison.larc.nasa.gov>  16-MAY-1989 13:43:00
To:        @uxv.larc.nasa.gov:security@pyrite.rutgers.edu
Greetings to all you *net-landers*!

I have been recently assigned a task to investigate methods for enhancing
security on our "Super Computer Network" (1 Cray 3 Convex).  In addition
to this, I am supposed to "search and destroy" any security holes.
For instance:  Our convexes, being 4.2 based, had some *nasty* 4.2 bugs
with the set process group, writing to ttys, and chfn.

I am trying to compile a set of "test" programs that will check for these
and other security holes.  Could anyone give me a list of well known and
not so well known security holes for 4.2 and 4.3 BSD and System V (UNICOS).

Lists, explanations, code to exploit these holes will all be welcome and
very much appreciated.  Please *do not* post any code, but mail it directly
to me at one of the below addresses.

Any suggestions for security enhancement (not recently posted) would also
be appreciated.

Thanks Alot!

		   -=>gretzky<=-
.mitch

=================================
		   		|
gretzky@unison.larc.nasa.gov	|
root@unison.larc.nasa.gov	|
gretzky@eagle.larc.nasa.gov	|
gretzky@uxv.larc.nasa.gov	|
mitch@teb.larc.nasa.gov		|
				|
=================================
-----------[000044][next][prev][last][first]----------------------------------------------------
From:      ron@ron.rutgers.edu (Ron Natalie)  17-MAY-1989  0:35:09
To:        misc-security@rutgers.edu
Not ANY duplicators are set up to do them.  To get additional
keys, we used to have to order them by number from the manufacturer.

-Ron
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 17:04:09 GMT
From:      MOG::REX@ISDMNL.MENLO.USGS.GOV (Rex Sanders)
To:        misc.security
Subject:   RE: passwords

On our 4.3 BSD Unix system, we have three people that need
root permissions.  We used to all know the root password.
Then, a security directive came around: one account, only one
person knows the password.

We set up three accounts, with names other than "root", and
uid 0, gid 1.  Each account has it's own password, and I
changed the "root" password to something I've already forgotten.
We put hooks in /.login and /.cshrc to source files of our own.
This scheme has worked fine for several years now.

To help other users identify "root" users when logged in, we
named the other accounts with root vegetable names - mine is
"radish".

-- Rex
   rex@isdmnl.menlo.usgs.gov

-----------[000046][next][prev][last][first]----------------------------------------------------
From:      rogers@marlin.nosc.mil (Rollo D. Rogers)  17-MAY-1989  1:06:35
To:        NCASTELLANO@eagle.wesleyan.edu
Cc:        security@pyrite.rutgers.edu
hi, have you heard of the latest lock for vehicles here in S. Calif.
which is called the "Club".

If yes, what is your opinion as to how secure from theft a car with
this club locked onto the steering wheel would be?

  REgards, RollO~~
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 18:14:32 GMT
From:      andrews@APPLE.COM (Richard Andrews)
To:        misc.security
Subject:   Re: DES Export

>From my own experience, it seems to me that DES per se is not excluded from
export.  It just depends on how you use it.  I worked on a product, the
AppleShare File Server, that uses DES to encrypt passwords, and that was
granted a Commerce Jurisdiction (meaning Apple is free to export it).
Clearly, we would not have been able to export it if we used DES for file
encryption.

-----------[000048][next][prev][last][first]----------------------------------------------------
From:      Mr. Stanley Cup <gretzky@unison.larc.nasa.gov>  17-MAY-1989 12:31:41
To:        @uxv.larc.nasa.gov:security@pyrite.rutgers.edu
Subject: Password Security and multiple users per account (password)
			       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
				   DON'T (it's that simple)

Two comments:

1)     On the system that I am running, I have a program called "do" which
will allow users to execute commands as root.  The user must be in a "doers" 
file and a member of the "cando" group.  The "doers" file can also restrict 
members of "cando" to a limited set of commands.  All commands executed using
do are logged (including failed command attempts), of course one can get around
the logging by "doing" a command which allowed shell escapes (but I am working
on that).

2)     Have overhead accounts, 1 for each person that needs the password, and
give them all the same user-id. (ie).

root:/\/\/\/\/\/\:0:1:Root of All Evil:/:/bin/tcsh
nobody:*:-2:-2::/:
daemon:*:1:1::/:
  ...
audit:*:9:9::/etc/security/audit:/bin/tcsh
  ...
need1:abcdefghij:9:9:Mr. John Doe:/etc/security:/bin/csh
need2:klmnopqrst:9:9:Ms. Jane Doe:/etc/security:/bin/csh
  ...

Now if "need1" logs in with his password, then he becomes "audit".
The same goes for "need2", but with her password.
You can check wtmp for the last time that they logged in, and use lastcomm
to see what they did (under "audit").  Of course this is *NOT* a good idea
for root access.

-- For root acess, use something like "do" --

>>> Just my 6 pence worth <<<

			   -=>gretzky<=-
.mitch
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 05:04:30 GMT
From:      alo@KAMPI.HUT.FI (Antti Louko)
To:        misc.security
Subject:   Re: DES export laws

> Thus, a copy of Dbase III labelled 
> "Not for export" cannot be used in an open lab here.

Software vendors could do the following:

Take their software product without any non-export stuff to some of
their labs outside US. At that site, include some outside-US
DES-package into their product, or even better, ship their product in
relocatable form, so customer can link any encryption package with it.

My DES-package can be used freely for non-commercial purposes. If a
vendor ships my DES-package in source code (and optionally in
relocatable code) with their product so that customer can link it
together himself, I consider this as non-commercial use. The idea is
that the customer could do the same even if the vendor wouldn'n
provide the DES-package.

If the vendor packages their product and DES together (eg. linking
them into an executable) I consider this as a commercial use.

In my opinion:

Software vendors should ship all their software also in reloacatable
form!!

My DES-package is available by ftp at kampi.hut.fi (128.214.3.9) at
directory /alo/

------------------
 alo@santra.UUCP (mcvax!santra!alo)       Antti Louko
 alo@hut.fi                               Helsinki University of Technology
 alo@fingate.bitnet                       Computing Centre
 alo%fingate.bitnet@cunyvm.cuny.edu       SF-02150, Espoo
                                          FINLAND
                                          tel. +358 0 4514314
------------------

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 17:26:01 GMT
From:      ron@RON.RUTGERS.EDU (Ron Natalie)
To:        misc.security
Subject:   Re: System Security

UNICOS, at least as I saw it two years ago, had no
pretense at security.  It was quite easy to do things that
would crash the machine, and only moderately more difficult
to get unauthorized access to root.

You might ring up your colleagues at NASA-AMES, who certainly
have much more experience with UNICOS that I do.  They're also
pretty sharp on the security scene.

-Ron

-----------[000051][next][prev][last][first]----------------------------------------------------
From:      AIDE Hugh Hazelrigg <hazel%unm_la@lanl.gov>  18-MAY-1989  9:32:38
To:        hobbit@pyrite.rutgers.edu
About a week ago someone posted an article to misc.security which had some info
on where to find the "Orange Book."  Well, someone named Danny at the Federal
Information Center had never heard of the "National Computer Security Center 
[publications office]" (which was the name of the source in the posting), nor 
the Orange Book nor Rainbow Set.  He sounded like he really wanted to help, 
but needed more information.  Can you or anyone in m.s provide it?

Thanks in advance.
Hugh

[Moderator note:  "Dunno" -- can anyone else clarify for him?   _H*]
-----------[000052][next][prev][last][first]----------------------------------------------------
From:      nugent@anubis.uchicago.edu  18-MAY-1989 10:07:49
To:        security@pyrite.rutgers.edu
Cc:        simsong@idr.cambridge.ma.us
Medeco patents each of their key blanks.  The patents on the older
keyways ran out a couple of years ago and blanks started showing up,
which is one of the reasons that Medeco has moved into the Biaxial locks.

I would be interested to know if the key you had copied had a round or
a square shoulder end(the part you hold onto).  I think all the older
keyways had round keys.  It is certainly interesting news if the
Biaxial Medeco key blanks are available in spite of the patent
infringement.  

Of course as people have pointed out, if you are good with a
machinest's file or a milling machine, not having the key blank is not
a problem.  But that kind of person is difficult to keep out of a bank
vault as well.

Todd
-----------[000053][next][prev][last][first]----------------------------------------------------
From:      rjg@sialis.mn.org (Robert J. Granvin)  18-MAY-1989 10:30:45
To:        misc-security@uunet.uu.net
Please realize the whole point is that Medeco locks and keys aren't
that they can't be duplicated, but that they are normally very
difficult to do so.  The vast majority of people wanting to make a
copy won't go through the effort to find someone as you described,
and if they did, they probably wouldn't have the same first time
success rate.  Doing so, depending on the environment where the key is
intended for, may show criminal intent.  You can't really say that
about your normal household locks you get from the hardware store.

On the other hand, picking a Medeco lock is again, significantly more
difficult than other locks.

Nothing is 100% guaranteed secure, but you can make the "average"
criminal go somewhere else and leave you alone.  This is generally the
goal.

The only way that you can prevent keys from being duplicated is don't
put a keyed lock on a door, and don't distibute keys for that lock
that doesn't exist.

-- 
________Robert J. Granvin________   INTERNET: rjg@sialis.mn.org
____National Computer Systems____   CONFUSED: rjg%sialis.mn.org@shamash.cdc.com
__National Information Services__       UUCP: ...uunet!rosevax!sialis!rjg
-----------[000054][next][prev][last][first]----------------------------------------------------
From:      Clive Carmock <cca@cs.exeter.ac.uk>  19-MAY-1989  0:42:24
To:        misc-security@ukc.ac.uk
For some time I have tried to have a duplicate Medeco key cut, which operates
a key switch.  The kwy switch is effectively useless to me until I get spare
keys.  It was part of a disused lift (elevator) car panel and was the SERVICE
keyswitch.  The panel was imported from the US from a company called GAL 
Elevators of (I think New York).  The key bears the number R63 LF.  I was told
by a UK locksmith that the number meant nothing to him, but he did know that
the final two letters were connected with the company/locksmith who issued the
keyswitch.  

I wonder if anyone could throw some light onto this and tell me where I may be able to get spare keys cut.
Thanks
CLive Carmock
(cca@expya.uucp  OR  cca@cs.exeter.ac.uk)
-----------[000055][next][prev][last][first]----------------------------------------------------
From:      biocca@bevb.bev.lbl.gov (Alan Biocca)  19-MAY-1989  1:18:46
To:        misc-security@ucbvax.berkeley.edu
Rekeying isn't difficult or expensive to do yourself, either.  I recently
bought a $20 kit for schlage rekeying at the local Home club.  It comes
complete with instructions and some tools, all you need is screwdriver and
pliers.  Re-keying requires that you have both new and old keys, so it works
best if you have a collection of keys to pick from when rekeying.  You could
file a key and make a new one, too.  There is a gauge included that could
be used to determine when the filing had reached a new 'standard' depth.
The kit also includes a large quantity of each standard pin size as well
as replacement springs in case they get lost or lose their force.  I've done
fifteen or twenty locks now and since you exchange pins rather than lose them
you can almost handle an indefinite number of locks.  Eventually you'll run
out of a particular size and have to buy more of them or a new kit.

Comments by Alan K Biocca
-----------[000056][next][prev][last][first]----------------------------------------------------
From:      *Hobbit*  <security_request@pyrite.rutgers.edu>  19-MAY-1989  4:34:26
To:        ???
An amazing number of replies came in.  I have included a couple of the most
informative for the benefit of anyone else who was curious.  Hugh's question
has been answered, in serious overkill fashion -- y'all can stop sending
them in now, I'm drowning over here!

Thanks to everyone else who passed on information...

_H*

****************
Date: Thu, 18 May 89 09:04:34 -0400
From: (Jeffrey A. Edelheit) <edelheit@smiley.mitre.org> <edelheit>
Subject: Re: orange book 
To: AIDE Hugh Hazelrigg <hazel%unm-la@lanl.gov>

The "orange book" is actually titled "Department of Defense Trusted Computer
System Evaluation Criteria."  It is a DoD standard (DOD 5200.28-STD) and is
dated December 1985.  The orange book (sometimes also called the TCSEC), is
one of a number of publications put out by the NCSC in the so-called Rainbow
Series.  Each publication has a different color cover and all deal with some
aspect of computer security.  The "red book", also called the TNI, is the
Trusted Network Interpretation of the TCSEC.  There are also books on
passwork guidelines, guide to audit, guide to discretionary access controls,
etc.

The best source is the US Government Printing Office.  There may be one near
you; otherwise, you can reach them at (202) 783-3238.  "All prices include
postage and handling" and "Use your MasterCard or VISA"  (These quotes come
from a GPO Catalog.)  The telephone number I gave is for Washington, DC
and is open from 7:30 am to 4:00 pm Eastern time.  The GPO order # for the
TCSEC is 008-000-00461-7 and costs $6.00.  The GPO should also have other
titles within the rainbow series for sale.

Jeff Edelheit		(edelheit@gateway.mitre.org)
The MITRE Corporation	7525 Colshire Drive
McLean, VA   22102		(703) 883-7586

****************

Date: Thu, 18 May 89 07:29:39 PDT
From: faigin@aerospace.aero.org
Subject: Re: orange book
To: security@rutgers.edu

The "Orange Book", also known as the Department of Defense Trusted Computer
System Evaluation Criteria, is DoD Standard DOD 5200.28-STD. You should be
able to get it via this number through the US Goverment Printing Office.

As for the other "rainbow" books... the ones I have sitting on my desk are:

Colour	   	Number          Title
Lt. Green  	CSC-STD-002-85  Department of Defense Password Management 
				Guideline
Yellow 		CSC-STD-003-85 	Computer Security Requirements
Yellow		CSC-STD-004-85	Technical Rationale Behind CSC-STD-003-85:
				Computer Security Requirements
Tan		NCSC-TG-001 v.2 A Guide to Understanding AUDIT in Trusted
				Systems
Red-Orange	NCSC-TG-003 v.1 A Guide to Understanding DISCRETIONARY ACCESS
				CONTROL in Trusted Systems
Red		NCSC-TG-005 v.1 Trusted Network Interpretation of the Trusted
				Computer System Evaluation Criteria
Peach		NCSC-TG-006 v.1 A Guide to Understanding CONFIGURATION
				MANAGEMENT in Trusted Systems
Dark Red	NCSC-TG-007 v.1 A Guide to Understanding DESIGN DOCUMENTATION
				in Trusted Systems
Grey  		NCSC-TG-009 v.1 Computer Security Subsystem Interpretation of
				the Trusted Computer System Evaluation
				Criteria

(if there are ones I am missing, I would like to know)

In terms of ordering, I would check with the US Govt Printing Office, or
directly with the NCSC. Their address is NCSC, 9800 Savage Road, Fort George
G. Meade, MD 20755-6000.

Daniel
-- 
Work :The Aerospace Corp M8/055 * POB 92957 * LA, CA 90009-2957 * 213/336-3149
Home :8333 Columbus Avenue #17  * Sepulveda CA 91343            * 818/892-8555
Email:faigin@aerospace.aero.org (or) Faigin@dockmaster.ncsc.mil               
Voicemail: 213/336-5454 Box#3149 * "Take what you like, and leave the rest"   
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 21:16:49 GMT
From:      URSJ@MARISTC.Berkeley.EDU ("John Schlosser")
To:        misc.security
Subject:   Car locks


  From what I've seen, the "club" only blocks the steering wheel
from turning more than a few degrees any way because of the way the
club is attached.  This works great if a would-be thief has the
intention of driving away with your car, but what if he/she/it
just wants to strip it bare of anything that's in it?
  A large metal pole that's attached to the steering wheel isn't
going to do much good then, will it?

John P. Schlosser (URSJ@MARISTC)
Student Staff Programmer
Marist College Computer Center
.Nothing I say in any way reflects anyone's opinion other than my own.
.I am not affiliated with THE CLUB's makers, distributors, advertisers
 or anyone else.

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 18:41:22 GMT
From:      hollombe@ttidca.tti.com (The Polymath)
To:        misc.security
Subject:   Re: car locks

} hi, have you heard of the latest lock for vehicles ... called the "Club".

Probably a little less secure than with the type of lock that runs from
the steering wheel to the brake or clutch pedal. (The "Club" just locks on
the steering wheel, making it difficult or impossible to turn completely
around).

I'd guess a large pair of bolt-cutters would get either one off in a few
seconds. (If they won't cut the lock, cut the steering wheel.  Car thieves
aren't known for finesse).

-- 
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}!ttidca!hollombe

-----------[000059][next][prev][last][first]----------------------------------------------------
From:      goldstein%star.DEC@decwrl.dec.com (Andy Goldstein)  21-MAY-1989  0:17:31
To:        misc-security@ucbvax.berkeley.edu
> The idea I am tring to present is that if a system was to use a modified
> version of crypt(3) (and install it in the libaries)

Well, the problem is that by virtue of this mail you've now announced
to the world that you're running a modified crypt(3) (or might be). So
all the crackers have to do is take your version of crypt along with
your password file.

Your best bet is to convince your users (by moral suasion or,
preferrably, software) to not use dictionary words as passwords.

					- Andy Goldstein
					  VMS Development
-----------[000060][next][prev][last][first]----------------------------------------------------
From:      "Craig Finseth" <fin@uf.msc.umn.edu>  21-MAY-1989  0:50:59
To:        shipley@tarantula.berkeley.edu
Cc:        security@pyrite.rutgers.edu
   What problems will using a modified passwd des crypt function will create.

I assume that you mean "modifed from UNIX" and not "modified from DES".

   wont this prevent the grabing of
   password files and 'grinding' on a local system.

This wouldn't stop someone from compiling the grind program on your
system and running it from afar.

I suggest putting your effort into (1) creating a shadow password file
and (2) making /bin/passwd reject "too-obvious" passwords.

Craig A. Finseth			fin@msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc.	(612) 624-3375
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 19:22:52 GMT
From:      lamaster@AMES.ARC.NASA.GOV (Hugh LaMaster)
To:        misc.security
Subject:   Re: Consensus on locks?

I have seen many postings on a variety of problems with so-called high
security standard-cylinder-type locks.  While no such lock is perfect,
it would seem that there might be a consensus that some particular
product line is the least likely to be easily picked or forced by garden-
variety burglars, and may even slow down an expert.  If there is such
a consensus on a company/product line, I would appreciate knowing what it is.

A sort of related question is:  I have seen locks with automatic "dead bolts"
 - meaning, locks in which opening the door with a key from the outside
(not in the handle) pulls back a full-sized spring loaded bolt, which closes
when the door is closed.  The obvious idea is to prevent "loiding" (I think
this is the term...), and also to provide more resistance to forcing than
the relatively narrow bars which are used on some locks for the same purpose.
Does anyone know the availability of these locks and whether they have any
advantage over the standard narrow bar type?  (I am no lock expert, in case
it isn't obvious :-)     ).  I assume that such a lock would have to be well
lubricated to allow the torque of a key to open a large bolt, but what other
disadvantages are there?

  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117       

[Moderator toss-in:  The usual way manufacturers of spring-loaded latches
prevent carding, loiding, sliding, whatever you want to call it, is to provide
an extra latch piece that is pushed into the mortise edge when the door is
closed, and engages a catch that prevents the main latch from being pushed
in.  These are well-known to, um, not work in many installations.  The sure-
fire way to lock the door is a dead bolt or better, but you can't just slam
the door closed.  If you're a chronic loser of keys, this could be good!   _H*]

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 20:24:07 GMT
From:      rwb@viusys.UUCP (Rick Butland)
To:        misc.security
Subject:   Encryption Software For PC's

As the subject says, is anyone aware of a software package that will encrypt
files on DOS?  Actually, what's desired is the ability to compose a msg
on a PC, encrypt it, and mail it to another PC user, where both PC's are
attached to a Unix host.  Most likely, though, rather than mail, the messages
will just be uploaded/downloaded.

Thanks in advance,

Rick Butland (rwb@viusys)

-----------[000063][next][prev][last][first]----------------------------------------------------
From:      Joe Wieclawek <jaw@sesun.jpl.nasa.gov>  22-MAY-1989  1:33:00
To:        security@pyrite.rutgers.edu
An article in the 6 May 1989 'Los Angeles Herald Examiner' reports:

   Attorneys said yesterday they are negotiating a second plea
bargain for computer hacker Kevin Mitnick, whose first offer
to plead guilty was scuttled by a judge because it called
for too little time in prison.
   Mitnick, 25, of Panorama City (CA) offered in March to serve
one year in prison and to plead guilty to computer fraud and
possessing unauthorized long-distance telephone codes.
-----------[000064][next][prev][last][first]----------------------------------------------------
From:      heilpern@brl.mil  22-MAY-1989  2:00:37
To:        security@pyrite.rutgers.edu
In theory, you can use any encryption you would like in place of the
crypt command (or, for that matter, no excryption whatsoever.)
The problem presented is this: All old excryptions will obviously be
incompatable with the new encryption routine, so for every user on
your system, you will have to erase their password and create another,
using the new encryption method. (This can probably be accomplished
by creating a program that is similar to 'passwd', but operates on a
copy of the /etc/passwd file, give users, say, 2 days to 'install their
future password', and after that two days, replace the login command
and the /etc/passwd file.)

However, if this is a new system you are setting up, things will be
extremely easy for you!!

	--M.
-----------[000065][next][prev][last][first]----------------------------------------------------
From:      Dr. T. Andrews <tanner@ki4pv>  22-MAY-1989  2:23:49
To:        shipley@tarantula.berkeley.edu (Pete Shipley)
Cc:        security@pyrite.rutgers.edu
I suspect that you would be OK if you made the change to crypt(3),
and assured that the few minor items mentioned below have been seen
to.

(a) Only the password encryption routine is affected.
	anyone using the standard setkey/encrypt package in
	the same module must be left unaffected!
(b) You get ALL of the programs re-built and installed
	at the same time.  That includes passwd(1), login(1),
	newgrp(1), su(1) wheel(1), wheelg(1), &c.
(c) You have some magical way to get your users to
	(1) all be logged in when you make the change, and
	(2) get them to all change their passwords NOW.
(d) You ferret out the local stuff which also depends
	on crypt(3) and re-build it.  Someone has something which
	needs a password to run, and he didn't tell you about it.
(e) Something at boot-up may want a password, too.  Don't
	forget to fix it!
(f) You replace your old back-ups with the old encryption
	in /etc/passwd and /etc/group and /etc/d_passwd and
	any other files with passwords.

Summary (too late to do you much good:-)
Considering the effort, and the danger, and the certainty that you
will miss something important, I would advise that you give up the
idea.  Otherwise, you will likely be unhappy.  Even if you think you
are happy, what happens when you get the next version of the OS?

					Dr. T. Andrews, Systems
					CompuData, Inc.  DeLand
-----------[000066][next][prev][last][first]----------------------------------------------------
From:      Michael Stack                                    <A01MES1@NIU.BITNET>  23-MAY-1989  5:25:27
To:        "David F. Lambert" <LAMBERT@mitvma.mit.edu>
Cc:        Security Topics Discussion List  <SECURITY@pyrite.rutgers.edu>
>                                                     ... I'm not sure
> if RACF or other VM security package equivalents have this feature.

"group logonids" are a standard feature of ACF2/VM and are intended to
provide accountability for the use of VMs like MAINT.

Michael Stack
Northern Illinois University
-----------[000067][next][prev][last][first]----------------------------------------------------
From:      simsong@idr.cambridge.ma.us (Simson L. Garfinkel)  23-MAY-1989  5:52:25
To:        RS@ai.ai.mit.edu
Cc:        security@rutgers.edu
Why use a 7/16" socket wrench and a butt set when you can just walk
to the next network interface?

That's the whole point of security; make it more difficult to break into
you than to break into somebody else, and more difficult than its worth.

---simson

	From: "Robert E. Seastrom" <RS@AI.ai.mit.edu>
	Subject:  Re:  Telephone line security
	To: idr!simsong@garp.mit.edu
	
	Yep.  A lot of good it will do you if someone should come
	along with a 7/16" socket wrench and a butt set.  Try it.
	
	               ---Rob
-----------[000068][next][prev][last][first]----------------------------------------------------
From:      WHMurray@dockmaster.ncsc.mil  23-MAY-1989  6:18:04
To:        security@rutgers.edu
>To be effective, the number of people who know a pw must be kept to a
>minimum.  The small department that I am associated with insures that
>each member of that small group is told the new pw, verbally, in a low
>voice.                   

(I am unable to tell whether this posting is "tongue-in-cheek."  I will
assume that it is intended to be sincere.)

In order to be effective a password must be known by no more than one
person.  In the kind of open systems in which we deal (i.e., with many
privileged users), the only way to be sure that it is known to only one
person is to use it only once.

The solution to this dilemma, dealt with many times in this forum in
One-time password generators.  This mechanism also provides for the
passing and withdrawing of high privilege, since, unlike a password, the
generator can be returned.

(The discussion by the "secure" installation where five people know the
root password and another copy is kept in a lock box is too absurd to
deal with.  If a system is so unstable that it takes five people with
privilege to keep  it up, it cannot be said to be secure in any
meaningful sense anyway, but if five people share the password any way,
then how you protect and account for the use of any copy is not
material.)

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114                          
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840                
-----------[000069][next][prev][last][first]----------------------------------------------------
From:      simsong@idr.cambridge.ma.us (Simson L. Garfinkel)  23-MAY-1989 23:48:45
To:        security@rutgers.edu
	Date: Fri, 5 May 89 16:02:57 EDT
	From: vicka@vax.ftp.com (Vicka Corey)
	To: simsong@idr.cambridge.ma.us
	Subject: security
	
	Oops, that's a paper, not an RFC.  Reference follows:
	
	ps.  For the rest of the tcp-ip community... it's an excellent paper,
	and it isn't very long.  As the add says, "if you only read one paper
	this year, make it _Security_Problems_in_the_TCP/IP_Protocol_Suite_,
	by S.M. Bellovin in the ACM Computer Communication Review, Vol. 19,
	No. 2, pp. 32-48, April 1989."
-----------[000070][next][prev][last][first]----------------------------------------------------
From:      cme@cloud9.stratus.com (Carl Ellison)  24-MAY-1989 19:43:36
To:        linus!misc-security@ursa-major.spdcc.com
You don't have to erase old encrypted passwords when you change
algorithms -- just be prepared to accept either, for a while --

ie., use both algorithms to create two strings to match against the
password file -- and if either works, the user is logged in.
If it's the wrong one which worked, you can nag or threaten....

--Carl Ellison                      UUCP::  cme@cloud9.Stratus.COM
SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752
Disclaimer::  (of course)
-----------[000071][next][prev][last][first]----------------------------------------------------
From:      nevin1@cbnewsc.att.com (nevin.j.liber)  24-MAY-1989 20:17:42
To:        misc-security@att.att.com
|So all the crackers have to do is take your version of crypt along with
|your password file.

But what if the new version of crypt is not public (the source code
does not exist on a publicly accessible machine, and the appropriate
permission bits are set so that the executables are not readable, etc.)?
Unless one is willing to apply cryptographic techniques to determine
the algorithm (in which case you probably need more security than just
password protection, anyway), this still seems like an improvement over
using the standard crypt for passwords (assuming the new algorithm is
sufficiently good, of course).
-- 
NEVIN ":-)" LIBER  AT&T Bell Laboratories  nevin1@ihlpb.ATT.COM  (312) 979-4751
-----------[000072][next][prev][last][first]----------------------------------------------------
From:      steve@polyslo.calpoly.edu (Steve DeJarnett)  24-MAY-1989 20:24:25
To:        kerchen@iris.ucdavis.edu, security@pyrite.rutgers.edu
>Hmm, what's the use in using shell scripts if they can be changed by
>whoever last used the root password?  Or, do you keep these scripts off
>line and just put them on the system when you need to make these checks?

	The version I use to check things lives in my bedroom at home.  If
these people can break into my house and modify the tape, then I guess I have
larger problems than system security :-|.

	The fact that few people (until I sent this note out :-) knew that
such scripts even existed makes it a little less likely that they'd be found
(they also live so far down in the filesystem that I occasionally have trouble
remembering where they are).  When we do check the system, though, we either 
make a visual check of the scripts before running them, or bring my tape in 
from home.  Of course, University security requirements aren't QUITE as 
stringent as those required by, say, the DoD.

	Steve DeJarnett
	Cal Poly San Luis Obispo
	steve@polyslo.CalPoly.EDU
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 19:48:27 GMT
From:      cme@cloud9.stratus.com (Carl Ellison)
To:        misc.security
Subject:   Re: password security

You don't have to erase old encrypted passwords when you change
algorithms -- just be prepared to accept either, for a while --

ie., use both algorithms to create two strings to match against the
password file -- and if either works, the user is logged in.
If it's the wrong one which worked, you can nag or threaten....

--Carl Ellison                      UUCP::  cme@cloud9.Stratus.COM
SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752
Disclaimer::  (of course)

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 20:26:13 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        misc.security
Subject:   very fast DES is near

I've just gotten the word that a substantially reworked version of
DES will soon become public.  The version eliminates the piple-line
structure of FIPS 46 and replaces many of the bit picking that slows
most computer  implementations.  I havn't been told how much of a 
speed up this will have over the FIPS 46  version of the algorithm.
The new version has eliminated some of the "rounds" structure
of the current algorithm and still computes the same DES process.  
Speculation is that it will make file and bulk based DES faster and 
less expensive and will provide a base for faster IC implementations. 
More as I find it out.

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 21:13:21 GMT
From:      gretzky@UNISON.LARC.NASA.GOV (Mr. Stanley Cup)
To:        misc.security
Subject:   password security

> You don't have to erase old encrypted passwords when you change
> algorithms -- just be prepared to accept either, for a while --

How about having both algorithms available for a "real short" time and do
this with them:

	if (strcmp(new_crypt(reply ,salt),pass) == 0) {
		/* all is ok, let 'em in */
	}
	else if (strcmp(crypt(reply, salt), pass) == 0) {
		new_version_pass = new_crypt(reply,salt);
		/* update the passwd file */
		/* let 'em in */
	}
	else {
		/* password was no good, do whatever */
	}

After all of your users have logged in at least once, you then have all of
their passwords converted to the new algorithm without ever knowing what
their password is/was and the user will not know that anything was done
to the encryption algorithm for logging in.

			-=>gretzky<=-
.mitch

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 13:17:10 GMT
From:      fred@DTIX.ARPA (Fred Blonder)
To:        misc.security
Subject:   Re: password security


	You don't have to erase old encrypted passwords when
	you change algorithms -- just be prepared to accept
	either, for a while --
	
Or just silently store the new encryption. In fact, changing the
encryption algorithm on a regular basis, combined with accepting
either the current or previous encryptions, would be one way of
implementing password aging, assuming you really want to do that.
----
					Fred Blonder <fred@dtix.arpa>
					David Taylor Research Center
					(202) 227-1428

-----------[000077][next][prev][last][first]----------------------------------------------------
From:      gwyn@brl.mil  31-MAY-1989  3:36:38
To:        security@rutgers.edu
Not long ago I got inside word that AT&T had asked for a determination
of the export status of their UNIX crypt routines, the outcome of which
was essentially that individual approval would have been readily obtained,
but not blanket "warehouse" approval.  This seems pretty silly to me..
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 03:45:16 GMT
From:      spaf@CS.PURDUE.EDU (Gene Spafford)
To:        misc.security
Subject:   Need list of names

For purposes of checking for weak passwords, I'de like to obtain a
list of common names (Al, Fred, George... Alice, Kathy, Susan...)
Does anybody have such a list online they'd be willing to share with
me?

Please e-mail -- don't post.

Thanks in advance!
-- 
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu	uucp:	...!{decwrl,gatech,ucbvax}!purdue!spaf

END OF DOCUMENT