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 (1990)
DOCUMENT: Rutgers 'Security List' for July 1990 (62 messages, 38366 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1990/07.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
From:      antonyc@chamber.cco.caltech.edu (Bill T. Cat)  3-JUL-1990 20:21:28
To:        security@rutgers.edu
but as the number of masters increases, so does the ease of picking the lock
-----------[000001][next][prev][last][first]----------------------------------------------------
From:      kuras@josef.enet.dec.com  3-JUL-1990 21:00:26
To:        misc-security@decwrl.dec.com
The dates of the workshop are August 27 & 28, 1990.  Sorry, I don't have
location or other particulars at this time, other than it's in Portland,
Oregon. 

The organizer of the workshop is Matt Bishop,  Dept of Mathematics &
Computer Science, Bradley Hall, Dartmouth College, Hanover, NH 03755 (603)
646-2415 
-----------[000002][next][prev][last][first]----------------------------------------------------
From:      optilink!cramer@uunet.uu.net (Clayton Cramer)  3-JUL-1990 21:37:46
To:        misc-security@uunet.uu.net
There's a much more low-tech version of this scam, that worked
successfully in Culver City, CA, a few years ago.

There was a bank heavily used by merchants in Fox Hills Mall.  Of
course, merchants usually make night deposits filled with cash and
coin.  A sign was placed on the night deposit box that said, "Out
of order".  An armed security guard, in uniform, stood next to it,
with a large wooden box.

Yup!  You guessed it!  Few merchants questioned it -- they just
dropped their night deposits in the box.  The next day at the
bank must have been pandemonium.  "There's nothing wrong with our
night deposit box.  What guard?"
-- 
Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer
Amtrak subsidies: adults playing with choo-choos.
----------------------------------------------------------------------------
Disclaimer?  You must be kidding!  No company would hold opinions like mine!
-----------[000003][next][prev][last][first]----------------------------------------------------
From:      jearly@lehi3b15.csee.lehigh.edu (John Early)  3-JUL-1990 22:14:21
To:        misc-security@rutgers.edu
The CC and CSEE here at Lehigh are going to set up a Sun SPACRstation *public*
site (hopefully in time for the fall semester) and I'm trying to find out
what is available as far as physical security systems.  All we really need
to do is bolt the CPU and monitor down (we will have both the 16 inch color
and the 19 inch mono) and cable the keyboard and mouse to the CPU.  (The
optical mouse will be interesting...while there is no ball for people to steal
the pad will certainly walk if not glued down, yet if I glue it down our
left-handed users are screwed--and don't ask me to ask for money to buy two
per station.)
So if anybody knows of any systems for Suns please e-mail me.  If people want
I can let you know how things work out in the fall.
Thanks,
John.

----------------------------------------
John Early                             |
jearly@lehi3b15.csee.lehigh.edu        |  I was just a child then;
JPE1@Lehigh.Bitnet                     |  now I'm only a man.  [pf]
LUJPE@VAX1.cc.lehigh.edu               |
-----------[000004][next][prev][last][first]----------------------------------------------------
From:      *Hobbit* <hobbit@pyrite.rutgers.edu>  3-JUL-1990 22:54:58
To:        security
It would be REALLY GREAT if makers of "real" locks made drop-in replacements
for car doors, complete with reinforcing plates and good pin cylinders and a
mechanism that works such that once you turn the key a certain way the little
lever is locked toward one direction and won't move at all.  This would prevent
use of a slim-jim.  Unfortunately for the kind of car-door latch that doesn't
work when the lock is locked, it could also trap people inside the car.  Given
that one would have to explicitly lock the door from the outside with such a
rig, I think that I'd personally rather have that small risk than what, for
instance, I have now, which is a car that's frighteningly easy to break into.

I recently tore my door apart to investigate the possibility of doing this.
The cylinder has a limit stop which prevents motion much more than 60 degrees
either way from center, and this stop is somewhere underneath the stupid
press-fit front bezel, which if bent apart and then back again will probably
be rather weakened.  So for the moment I've given up on the idea of redoing it
so it could be turned 180 degrees and then the key pulled.  If someone knows of
a type of car cylinder whose limit stops are on the *back*, where I could
get at them and file them down, please holler, and I could go off to a junkyard
and find that kind of car.  Yes, even with all that glass sitting there
saying "break me", I still want to do this just for hack value.

_H*
-----------[000005][next][prev][last][first]----------------------------------------------------
From:      Doug Gwyn <gwyn@smoke.brl.mil>  3-JUL-1990 23:16:41
To:        misc-security@rutgers.edu
>...  The two of us who confronted them were threatened with instant
>expulsion if we were ever caught USING such knowledge; we didn't tell
>them about the others...

That seems to be fairly typical of administrations.  Lock hackers can
be quite concerned about perceived weaknesses in the institution's
security systems, but the administration often prefers to act on the
principle that knowledge is bliss, rather than tackling the objectively
significant problem.  Anyway, one generally meets with the sort of
response that you reported, when trying to bring the attention of the
authorities to a real problem.  That's one of the reasons that
vigilantes come into existence.  At Rice, I sat in on SDS meetings just
to keep an eye on the radicals, and when they planned to blow up a
building on campus, some of us were ready to foil their plans by
entering through the steam tunnels; we didn't want our school destroyed.
(I heard that later the local SDS leader, Karolyn Kendrick, was wanted
"to help the authorities with their investigations", as the British
would put it, in connection with a similar attempt.)

>The cores had those convenient holes for picking the core sleeve.

Of course that's not what they were intended for; they're for a small
pin punch to push the pins out of the columns in case they're sticky.

(You can also drive out the pins, cap and all, but it spoils the spring.)

If you file the end of a 1/8" (I think it was) pin punch to a 45-degree
angle, it makes removing the caps without damage a breeze.

>The locks, by the way, had a master key cut for the deepest pin, even
>though the school didn't use it.  (Maybe the police or Best co?)

Best locks are pinned either by the factory or by a local Best rep.
It is NOT standard practice to add any levels of masterkeying for use
other than as part of the customer's masterkeying system.  It may be
that your school was indeed required to provide a master key to police
etc.  I don't think Best would dare build in a key for their own use.

>Someone let themselves into the locksmith's shop and stole the key
>machine the next year; very crude, they should have used it on 
>the premises so no one would have suspected.

There's always someone who doesn't have any sense of judgement and
steps beyond the bounds of harmless activity.  Stealing equipment is
certainly beyond the bounds.  At Rice, our lock hacking had to be
toned down because some idiot started stealing stuff through the
steam tunnels, and the administration threatened to expel anyone
found exploring the steam tunnels no matter what their intentions
were.  That pretty much ended a major hobby for several students.

One wonders why the school's official educational practices are so
stifling or boring that students find themselves turning to such
hobbies instead.

I've never heard of a technically-oriented college or university,
Best-using or not, where lock hacking didn't occur.  Too bad some
sort of locksmithing course credit isn't normally offered.
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 90 15:29:15 GMT
From:      mchinni@PICA.ARMY.MIL ("Michael J. Chinni, SMCAR-CCS-E")
To:        misc.security
Subject:   [Theodore Lee:  The F9 factoring result]

FYI ... (this is a long message: 155+ lines)

Date: Wed, 27 Jun 90 22:19:44 -0400
>From: Theodore Lee <lee@TIS.COM>
Subject: The F9 factoring result

MESSAGE FROM RON RIVEST VIA JIM BIDZOS VIA STEVE KENT VIA STEVE CROCKER:
Thanks to Robert Silverman for keeping many people honest.
As an additional effort to that end, I attach an analysis of
the recent factoring effort, done by Ron Rivest.  The early 
reports of RSA's demise have been greatly exaggerated...
Note: Be sure and read the end of Rivest's note.
Jim Bidzos, RSA Data Security

To:	Whom It May Interest (Feel free to distribute further...)
>From:	Ronald L. Rivest
Date:	June 21, 1990
Re:	Recent Factoring Achievement
	(Preliminary draft; may contain typos or other inaccuracies.
	Please send corrections to rivest@theory.lcs.mit.edu)

This note is in response to the numerous inquiries I've received regarding
the recent factoring of a 155-digit number by A. Lenstra, M. Manasse, and
others.  (See the New York Times article of 6/20/1990 by G. Kolata.) 
This note attempts specifically to correct some of the misimpressions that
may arise from a reading of such popular press articles.

Using an ingenious new algorithm, Lenstra, Manasse, and others have
factored the 155-digit number known as "F9", the ninth Fermat number:
		F9 = 2^(2^9) + 1 = 2^(512) + 1 .
In binary, this number has the form
		100000....000000001
where there are 511 zeros altogether.  (F9 is a 513-bit number.)
This is a fascinating development, and the researchers involved are to be
congratulated for this accomplishment.

The algorithm used is known as the "number field sieve", or "NFS" (not
to be confused with a network protocol of the same acronym!).  The NFS
algorithm is described in the Proceedings of the 1990 ACM STOC Conference.
The NFS algorithm is based on an idea due to Pollard, as developed further by
Arjen Lenstra, Hendrik W. Lenstra, and Mark S. Manasse.

The NFS algorithm is specifically designed to factor numbers that,
like F9, have a very simple structure: they are of the form
		a^b + c 
where c is relatively small.  (For F9, we have a=2, b=512, and c=1.)
Some simple extensions of this algorithm are also possible, to handle
numbers whose binary representation has many zeros, and related kinds
of numbers (ternary, etc.)  Numbers that have such a special structure are
extremely rare and are unlikely to be encountered by chance.  That is,
the NFS algorithm does not apply to the kind of "ordinary" numbers that
arise in practical cryptography, such as using RSA.  They only apply to
numbers with "sparse" representations having few nonzero components.
(Let us call such numbers "rarefied".)

When working on a rarefied number, the NFS algorithm has an estimated
running time of the form (for an input number n):
		exp(1.56 (ln n)^1/3 (ln ln n)^2/3)			(1)
For n = F9, this evaluates to 
		4.1 x 10^15 operations,
which, at 3.15 x 10^13 operations/year for a 1 MIP/sec machine (i.e. a
MIP-year), gives a workload estimate of
		130 MIP-years,
only off by a factor of two from the actual work of 275 MIP-years. (That is,
formula (1) may be roughly too low by a factor of two.)

It is instructive to see the effect of doubling the size of the number
being dealt with.  A 1024-bit (332-digit) rarefied number requires an estimated
		1.54 x 10^21 operations
	=	4.9 x 10^7 MIP-years,
a dramatic increase in difficulty.  The NFS algorithm algorithm is not a
"polynomial-time" algorithm; the difficulty of factoring still grows
**exponentially** with a polynomial function of the length of the input.

What has this to do with RSA and cryptography?  I think there are three
basic points:
	-- This development indicates that the status of factoring is
	   still subject to further developments, and it is wise to be
	   conservative in one's choice of key-length.
	-- The NFS algorithm may yet be generalized to handle "ordinary"
	   numbers, and the potential impact of this should be considered.
	-- Factoring is still a very hard problem, despite everyone's best
	   efforts to master it.

Regarding the further extensions of NFS to handle ordinary numbers, this is
judged to be a reasonable possibility by those working on NFS, so it is 
helpful to consider what impact this may have.

It is conjectured (see the ACM STOC paper referenced above) that a successful
extension of the NFS algorithm to ordinary numbers would have a running time
of the form:
		exp(2.08 (ln n)^1/3 (ln ln n)^2/3)			(2)
This is similar to equation (1) except that the constant 1.56 is
replaced by the constant 2.08.  Note that a practical version of such
an extension does NOT yet currently exist (to the best of my
knowledge), but even granting its plausibility we arrive at an
estimate of the tie required to factor a 512-bit number of
		6.5 x 10^20 operations
	= 	2 x 10^7 MIP-years
which (in my opinion) is a substantial degree of security.  It is 
interesting to note that this work factor is actually GREATER than that
required by the ``standard'' factoring algorithms (e.g., the quadratic sieve),
which have a running time of
		exp((ln n)^1/2 (ln ln n)^1/2);
for a 512-bit number, this gives a work-factor estimate of only
		6.7 x 10^19 operations.
Indeed, the NFS algorithm (when extended) will be asymptotically superior than
the quadratic sieve algorithm, but will be slower for numbers with less 
than about 200 digits.  That is, assuming that (2) is indeed the correct
running-time estimate for any extension of NFS, then NFS will not affect the
security of any numbers of less than about 215 digits.  So any "standards"
that have been considered using 512-bit RSA moduli are not likely to be
affected by any NFS extensions.  (At most, one could imagine that the
RSA key-generation process might be extended to check that the resulting
modulus n is not a rarefied number.)

In the truly worst-case scenario, we would have that an extension of
NFS would be found that allows ordinary numbers to be factored with a
work-factor that is governed by equation (1); in this case one would
need to adjust the sizes of moduli used by RSA upwards by a factor of
less than two to more than offset the new algorithm.  A factor of two
in size affects the running time of public-key encryption (or
signature verification) by a factor of four and the running time of
private-key encryption (or signature generation) by a factor of eight.
Noting that the speed of workstations has increased by a factor of
over 100 in the last decade (indeed, such factors have been the
technological advance that made the successful implementation of NFS
possible!), such performance penalties, if necessary, seem to be
easily absorbed by expected technological advances in the speeds of
the underlying RSA implementation technologies.  That is, the NFS-like
factoring algorithms do not, even in this worst-case scenario, prevent
successful implementations of the RSA cryptosystem.

As a cryptographer, I am actually very happy with all the effort that
is being spent trying to determine the exact level of difficulty of
factoring.  Achievements such as the recent development of NFS help to
pin down the best-possible rate of growth of the difficulty of
factoring, so that users of cryptographic schemes can pick key sizes
with an increased degree of confidence that unforeseen developments
are unlikely to occur.  The best way to ensure confidence in a
cryptographic system is to have it attacked vigorously and
continuously (but unsuccessfully) by well-qualified attackers.  If,
despite their best efforts, the difficulty of cracking the system
remains intrinsically exponential, then one can have a reasonably high
degree of confidence that the system is actually secure.  This is the
process we have been seeing at work in the recent work on factoring.
The results of the attacks can be used to guide the selection of the
necessary key size for a desired level of security (with an
appropriate margin of safety built in, of course).

(As a closing note, here's a prediction: I expect that the 128-digit
``challenge RSA cipher'' published in the August 1977 issue of
Scientific American to be cracked (probably by the quadratic sieve
algorithm or a variant, not NFS) during the next 1-3 years.  This
accomplishment will require substantially more computer time than the
275 MIP-years required to factor F9.)

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 19:47:52 GMT
From:      09nilles%cuavax.dnet@NETCON.CUA.EDU (Fiver Toadflax)
To:        misc.security
Subject:   re: SPARCstation Security

What you might try doing is to take and glue/fasten the pad to a steel sheet.
This sheet is then secured via cable to the same thing as the monitor or CPU.
The pad is now moviable, and yet is unlikely to walk out the door.

	     Dave

     09nilles@cua.bitnet
   Documentation Assistant
Catholic University of America

-----------[000008][next][prev][last][first]----------------------------------------------------
From:      Doug Gwyn <gwyn@smoke.brl.mil>  5-JUL-1990 13:50:38
To:        misc-security@rutgers.edu
>The NSA produces several pamphlets describing what they do.

They even have a Public Affairs office, and their non-classified
documents are subject to the Freedom Of Information Act.

However, I haven't heard of any guided tours for sightseers, yet.
-----------[000009][next][prev][last][first]----------------------------------------------------
From:      levine@csd4.csd.uwm.edu (Leonard P Levine)  5-JUL-1990 14:20:58
To:        misc-security@uunet.uu.net
> Sorry Leonard.  You must not be aware of any professionally designed
> master keying systems that were set up according to common locksmithing
> industry standards.

Don't I wish.  I spoke at length to our locking staff, as well as the 
building designers.  They did not even believe that this really bad design
was not the norm.  I agree with Seth that this is dangerous, but never
could get lock people to follow the problem.

Seth, are you speaking from theory or do you have a high masterkey in 
your posession?  I really want to know.

len levine
-----------[000010][next][prev][last][first]----------------------------------------------------
From:      mlindsey@x102c.ess.harris.com (Lindsey MS 04396)  5-JUL-1990 14:48:08
To:        misc-security@ucsd.edu
Sorry if this is a dead horse ...

I just bought a house and would like to put dead-bolts on every exterior door,
and have all of them work from one key.  Does anyone out there have any
advice about which models/brands to buy or avoid.  I'm looking for:

	- good security
	- easy installation
	- dependability (will it last a long time)
	- reasonable price

Please email.  If there is enough interest I will post a summary.

Thanks.

"Waste your brain, wax your board, and pray for waves!"   Woody in E.G.A.E.
/earth is 98% full!  Please delete anyone you can!	 (anonymous)
$teve Lindsey		|-)	uunet!x102a!mlindsey
(407) 727-5893		:-)	mlindsey@x102a.ess.harris.com
-----------[000011][next][prev][last][first]----------------------------------------------------
From:      mark%beowulf@ucsd.edu (Mark Anderson)  5-JUL-1990 15:32:00
To:        misc-security@sdcc6.ucsd.edu
>A properly selected master key must be impossible to create by filing
>a change key.  That means it must contain at least one cut that is
>taller than the corresponding cut in every change key.

I don't know about "common locksmithing industry standards", but the 
Foley-Belsaw training course doesn't mention any such concern in their
lessons.  Almost everywhere I've ever been you could find a change key 
to convert to a master.  I think you are overestimating the 
training/concerns of most locksmiths.  Or perhaps is just that 
facilities outgrew the original "correct" design.

And who really cares about the master key shear line, any old shear 
line will work, even for keys that don't exist.  I've always had 
the best luck picking locks on a master key system.

And if you are in a position where you can request legitimate keys, 
you can often order masterkeys through the same office just by knowing 
the code (which you get by watching a janitor).

mark
-----------[000012][next][prev][last][first]----------------------------------------------------
From:      Carl DeFranco <DEFRANCO@tops20.radc.af.mil>  5-JUL-1990 16:24:37
To:        security@pyrite.rutgers.edu
Recently, someone asked how to put together a system to provide protection
for a computer system operation through a packet switch using some type
of "box" for encryption.  It's not that easy.  Remember how packet swtiching
works?  Each packet contains address information that directs it on its way
to a destination.  Since the packet switch expects clear text information,
the "box" must have some method of extracting the address data from the 
packet, encrypting the remainder, then restoring the address data to the
packet.  This process cannot be done once at the establishment of a comm
session - it must be done for each packet that will pass through the packet
switch.  The Government has invested a lot of money in accomplishing just
this type of operation.  I am not aware of any commercial sources of
equipment that do what you want using commercial encryption methods such as
DES.

The problem comes from using the "connectionless" networking provided by
packet switching.  IF you modify your system to one which allows "nailed
down" communication, the "connection-oriented" method, you can do just what
you mention - establish the connection in the clear, then "go secure".
You will also need some method of exchanging encryption keys and managing
them on some periodic basis.

SO, as you can see, the problem is solvable, but it isn't a simple one.
Sorry to be the bearer of less than encouraging news.

Carl DeFranco
defranco@tops20.radc.af.mil
-------
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 90 10:31:00 GMT
From:      MISS026@ecncdc.BITNET (GREENY)
To:        misc.security
Subject:   re: Failed: attempt #1 at securing the vehicle

Forget it.  Just put a decent alarm system on the car, with an ignition kill
and jack-up/motion sensor (and maybe an audio discriminator in case the glass
breaks), and a nice loud siren (maybe the traditional "flashing" LED), and
park in a lighted area.

For the most part, reinforcing the locks, and making them "slim-jim" proof
is next to impossible.  There isn't a car around, that a qualified locksmith
(or car repo. man, or car thief) cant get into quickly.  And the tools are
widely available, as are the instructions for the individual cars.

Besides, you sorta want your car to be slim-jim-able so that when you lock your
keys in it, or lose the things, then a locksmith can get you in!

If you really wanna go nuts, get a 4 channel programmable voice driver from
Oregon Scientific (no # readily available...), and use the different inputs
from the alarm to trigger different voice outputs...).

My car says "ILLEGAL TOWING IN PROGRESS" when jacked up/towed, yells "I'M
BEING STOLEN" when the door/trunk/hook is being opened, yells "YOU BROKE
MY WINDOW" when the glass gets broken....the 4th one I havent used...Also,
I have a remote control (RF) to arm/disarm, have capabilities for passive
arming, and have a pager linked into the alarm that will find me within 2
miles when the alarm goes off.....

So far, it has saved me at least once.  I had a crook trying to break into
the car on campus during the summer, when not too many people would hear
the siren, and my pager went off.  I went off after the damn guy with a
baseball bat.  He didnt get in, and I didnt get any whacks in, but the cops
found him shortly (seems that they heard the siren and were on the way...).

at any rate, had he gotten in, I have purposely used multi-colored wires
wrapped in seemingly insane configurations to confuse a crook, hidden
the relays that trigger the pager/ign. cutout in a radio shack project
box labeled HIGH VOLTAGE.  CAUTION. under the dash.  So it would take
this "genius" of crime a longggggg time to start my car, and steal it.

At most he would get the radio, and being a standard Ford install, he could
have it with my compliments....

bye for now but not for long
Greeny

BITNET: MISS026@ECNCDC
Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU
GEnie: GREENY
AOL: GREENY1
Compu$erve: 72567,457
Disclaimer: U use it, U B responsible fer it!

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 90 12:23:13 GMT
From:      levine@CSD4.CSD.UWM.EDU (Leonard P Levine)
To:        misc.security
Subject:   Re: Best Locks

The reason for the low cut master is simply laziness on the part of
the locksmith, I believe.  When a lock is assembled, does not the
locksmith build up the pins in the rotating part by dropping in pieces
and then slide the assembly together?  If so, then there must be a key
in the lock to make the top of the pins level with the top of the
rotating part in order to let the system slide easily.  Similarly,
removal is done by the same method.  Put in a key, and remove the part
with the key in place.

If the Master is not the lowest key, a separate key would have to be
made for each lock assembled.  If the Master is the lowest, it may be
used for the assembly of each lock in turn.  Thus any locksmith paid
by the month will set up a Masterkey that is the lowest key in the
system.  Not good, but surely easy to work with.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                    e-mail levine@cs.uwm.edu |
| Professor, Computer Science             Office (414) 229-5170 |
| University of Wisconsin-Milwaukee       Home   (414) 962-4719 |
| Milwaukee, WI 53201 U.S.A.              FAX    (414) 229-6958 |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

[Moderator tack-on:  Not necessarily.  You don't need a key present to
*assemble* a lock at all; the plug can be inserted slightly offset and
everything will just drop into place when it's turned to locked position.
Also, any valid key will allow disassembly; you just have to retain all the
other parts in the shell with a thing referred to as a "following tool".
You can pick the rest of the parts out one by one afterward.  _H*]

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 15:30:33 GMT
From:      shz@packard.att.com (Seth Zirin)
To:        misc.security
Subject:   Re: Security and Masterkeys

>Seth, are you speaking from theory or do you have a high masterkey in 
>your posession?  I really want to know.

Both.

My home is master-keyed with Medeco Biaxial removable core locks.  The locks
are D-10 and D-11 deadbolts and Embassy cylindrical locksets.  The layout
is four level: GGMK, GMK, MK & CK.

	1) Each core has a separate combination (CK).
	2) There is a MK per side of each door (i.e., deadbolt and lockset)
	   and the MK that fits the inside cores on a door does not fit the
	   outside.  This prevents a delivery person from stealing an "exit"
	   key and using it to obtain entry.
	3) The outside cores are grouped under GMKs to provide "entry via the
	   front", "entry via the garage" or a "entry via the back" keys.
	4) All inside cores are grouped under a "fire egress" GMK so a
	   single key may be used to exit via any path.
	5) Every core opens with the Great Grand Master Key.

This system allows the change key (CK) for the front door lockset to be
left with a neighbor in case of a lockout, prevents a visitor from gaining
entry with a stolen "inside" key, and allows someone to enter to water
plants without letting them into the garage.

I set-up the master-keying system myself, including the calculations,
installation of the locks, pinning of the cores and cutting of the keys.
It turns out that only a few different keys were cut: the GGMK and several
GMKs, MKs and CKs.  No key in the system can be altered into a higher
level key and each key (including the GGMK and every GMK and MK) has
a wide range of cuts.  Each key has at least two cuts that differ by
the MACS (Maximum Adjacent Cut Separation) which varies from cut to
cut because of the fore and aft biaxial Medeco pins.

Seth Zirin, CPL

Member Associated Locksmiths of America
Member Safe and Vault Technicians Association

-----------[000016][next][prev][last][first]----------------------------------------------------
From:      deronwal@tybalt.caltech.edu (Deron Walters)  10-JUL-1990 11:23:05
To:        security@rutgers.edu
>On a recent visit I noticed they had rekeyed with Medeco Bi-axial locks, but
                                                   ^^^^^^^^^^^^^^^^^^^^^

Huh?  Bi-axial?  I'm familiar with regular Medeco locks, but I've never heard
of these.  Please describe them in more detail!

Deron A. Walters

[Moderator explanatory tack-on: Biaxial refers to Medeco's offset-chisel-tip
pin design, in which the bottom edge of the pin is offset forward or back
by .025".  Thus the bottom of the keycut has to not only be at the right
height and twist, it also has to be at the correct offset along the key bit.
_H*]
-----------[000017][next][prev][last][first]----------------------------------------------------
From:      shz@packard.att.com (Seth Zirin)  10-JUL-1990 11:57:43
To:        security@rutgers.edu
The Foley-Belsaw lesson plan is outdated.  I say this from experience
because I took the course a few years ago.  Check with the NY School
of Locksmithing or with Lockmasters.

The Associated Locksmiths of America (ALOA) Proficiency Registration
Program (PRP) in which I hold the certification of Certified Professional
Locksmith (CPL, I'm one elective away from Certified Master Locksmith, CML)
has sections on "Master-Keying" and "Advanced Master-Keying."  Both
of these sections and every book on master-keying repeatedly state
that no key should be alterable to a higher level.

You are correct about many improperly setup master-keying systems.  There
are way too many curbside commandos that call themselves locksmiths.

Seth Zirin
-----------[000018][next][prev][last][first]----------------------------------------------------
From:      "Chuck Sechler" <TS0258@ohstvma.bitnet>  11-JUL-1990 21:08:21
To:        SECURITY@MARIST, BIG-LAN@SUVM
Some breakins to a computer at a university in Ohio has prompted us at Ohio
State to look into enforcing use of more obscure passwords on our systems.

Basically, Iwould like to know if there has been any work on MVS and/or CMS
platforms to keep users from picking obvious passwords, like their name,
password same as userid, password is a word, etc. On MVS we are working on Top
Secret software, and it has some interesting capabilities for restriction,
including generating random passwords, when a user is forced to change their
password, but it is not ready for full implementation yet. Some UNIX platfors
check against large lists of restricted words(like 50000 or more). Any
thoughts? Please respond to me. Thanks.
-----------[000019][next][prev][last][first]----------------------------------------------------
From:      "Jacques Beland (a.k.a. Mickey) Trent University" <BELANDJ@trentu.ca>  11-JUL-1990 21:40:07
To:        security@UBVM
Can someone please show me what the different "security levels" mean in
terms of operating system. What I mean is one sees that "xxx's o/s is a
B2 rating". What is B2 and what are the different availale levels? And
is there somewhere  one can look up what o/s are rated at what level?
For example, VMS is B1, Novell is K9 etc?? Thanks.
-----------[000020][next][prev][last][first]----------------------------------------------------
From:      "Kees de Groot, Information Systems Security" <DEGROOT@rcl.wau.nl>  11-JUL-1990 22:01:27
To:        security@pyrite.rutgers.edu
Bob,

        Intel's micro-controllers in the MCS-51-series
        have a feature in which you can program a sort of
        hashing or mask. The effect is that it is impossible
        to read directly from the EPROM, but you can erase
        the whole device and reprogram it.
        This is al from between my ears. if you want
        more detailed information I can try to find some docs.

Tel. +31-8370-  .KeesdeGroot   (DEGROOT@RCL.WAU.NL)   o\/o  THERE AINT NO
     (8)3557/   Computer Systems Security              []   SUCH THING AS
        4030    Inform. & Datacomm.  Dreijenplein 2   .==.  A FREE LUNCH!
                6703 HB  Wageningen, the Netherlands
                X25:    PSI%(+204)18802031937::DEGROOT
disclaimer:     I always speak for myself
- if you go too far to the east, you find yourself in the west ..  -
-----------[000021][next][prev][last][first]----------------------------------------------------
From:      David Haimson <dmh@cnd.hp.com>  11-JUL-1990 22:27:55
To:        security@pyrite.rutgers.edu
 from Science News, June 2, 1990

Bits of Uncertainty: Quantum Security, by I. Peterson

    The trouble with sending a secret message is that the recipient must
have a key for deciphering it.  This means the two parties must
initially either meet in person or risk sending the key by some less
secure communications channel, and that invites interception.  Inspired
by an idea first proposed nearly a decade ago, a group of researchers
has now designed and constructed a device that uses the uncertainty
principle of quantum physics to provide a safe but public means for
transmitting vital, secret information.

    The device uses extremely faint flashes of light -- only one photon
per flash -- to carry messages.  Each photon has a certain linear
polarization (whether the electric field associated with the light is
oscillating horizontally or vertically) and a certain circular
polarization (whether the electric field is rotating in a right-handed
or left-handed sense about its direction of travel).  According to the
uncertainty principle, there's no way to measure a photon's linear and
circular polarizations simultaneously.  Measuring one disturbs the
other.

    A sender can use the polarizations of individual photons to send a
sequence of signals to the receiver, randomly choosing whether to encode
a bit of information as a specific linear or circular polarization.  For
each photon detected, the receiver chooses randomly which type of
polarization to measure.  About half the polarization measurements would
match the values the sender transmitted.  By ascertaining which photons
were correctly measured, the sender and receiver could derive a code,
known only to them, which would serve as a key for encrypting and
deciphering messages.

    Because any measurement attempted by a third party would
unpredictably alter a photon's polarization, an eavesdropper couldn't
intercept the transmission without irrevocably scrambling the message
and alerting both the sender and receiver to the surreptitious
surveillance.  To check for eavesdropping, the receiver would simply
compare notes with the sender, ascertaining what the results for a
number of selected measurements should have been.  Statistical
deviations from the expected results would signal an eavesdropper's
presence.

    This so-called "quantum public key distribution system" is the first
communications system ever built to depend on the uncertainty principle
to ensure secrecy, say its inventors, Charles H. Bennett of the IBM
Thomas J. Watson Research Center in Yorktown Heights, N.Y., and Gilles
Brassard of the University of Montreal.  "The system relies on the
uncertainty principle to enable its users to detect eavesdropping on the
quantum channel, even by an opponent with superior technology, and
reject the compromised transmissions."

    After playing with the idea for several years, Bennett and a
colleague constructed a working model of the system last summer.  The
device consists of tiny diode lasers for generating faint light flashes
and detectors for picking up the signals.  The entire apparatus sits
within a light-tight box about 13 inches long.  A computer program
controls the apparatus, tallies the signals sent, received and
intercepted, and displays the results.

    Because it is relatively slow and can be used only for communicating
random bits, the apparatus is best suited for transmitting cryptographic
keys.  Once the two users establish a key, they can exchange secret
messages by way of a faster, conventional communications channel.

    However, the device's present size severely limits its usefulness.
Bennett, who described his demonstration model at last week's Eurocrypt
conference in Aarhus, Denmark, now plans to build an improved device
using an optical-fiber cable for transmitting light pulses over
distances up to 500 meters.  Going to greater lengths is tricky because
the light pulses must necessarily be weak, which means they travel only
a limited distance along optical fibers before fading away.
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 14:01:00 GMT
From:      UCCXNCS@osucc.BITNET
To:        misc.security
Subject:   Userid maintenance Automation


  Since userid maintenance and security seem to go hand-in-hand, I
thought I might be able to get some ideas on how to go about
attacking a problem we are facing here at OSU.  If you know of a
list that addresses this sort of thing, please let me know.
Userid creation and maintenance is one of our biggest headaches.
   We have an IBM 3090 on which we run VM/SP with MVS running
as a guest under it.  The MVS system is used mainly by our
administrative users.  We have only had VM a few months and are
wanting to open it up to our academic users who, for the most
part, abhor MVS and JCL.  The idea is for the VM system to be
"friendlier", not requiring password changes, etc.
   So, we are looking for ideas on how to automate the setup
and maintenance of permanent (faculty) and temporary (student)
userids on the VM system.  Right now we are managing the few
VM userids that we have set up through DIRMAINT.  However, we
do have VMSECURE setting on the shelf.
  It seems to me that DIRMAINT is rather cumbersome, and I'm
not sure how we could set up an automated process that would
create several hundred userids using DIRMAINT.  Anyone that
has dealt with this problem and would be willing to give us
some suggestions is welcome to respond.
   Nancy C. Stevens  (405) 744-6301
   uccxncs@osucc.bitnet

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 90 15:56:11 GMT
From:      nagle@well.sf.ca.us (John Nagle)
To:        misc.security
Subject:   Re: Password Checking

>Basically, Iwould like to know if there has been any work on MVS and/or CMS
>platforms to keep users from picking obvious passwords, like their name,

       I first posted a simple solution to this problem back in 1984.  The
technique used does not require any dictionary or large tables; it relies
on some statistics of letter sequence usage in English which allow one to
determine whether something is a likely English word.  The code can be obtained
from the comp.sources.unix archive, or I can send a copy to interested parties.
The code is in C, but there is no UNIX dependency; in fact, I wrote the
original code on a DECsystem 2060, in C.  The archive reference appears below.

						John Nagle

Newsgroups: comp.sources.unix
Subject: v16i060:  Tell if a password is "obvious"
Date: 10 Nov 88 14:47:09 GMT
Submitted-by: "John B. Nagle" <jbn@glacier.stanford.edu>
Posting-number: Volume 16, Issue 60
Archive-name: obvious-pw

[  This program does NOT try brute-force methods to guess passwords,
   but instead tells if a password is an "obvious" one likely to be
   guessed by such a program. ]

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 90 18:13:51 GMT
From:      lorence@SCTC.COM (Len Lorence)
To:        misc.security
Subject:   Re: Different security ratings

>Can someone please show me what the different "security levels" mean in 
>terms of operating system. What I mean is one sees that "xxx's o/s is a
>B2 rating". What is B2 and what are the different availale levels?

What you want is a copy of the DOD Trusted Computer System Evaluation
Criteria (DOD 5200.28-STD) from the National Computer Security Center.
It sets the criteria for a system to meet each of the evaluation
ratings (D, C1, C2, B1-3, and A1.)  You also want a copy of the
Evaluated Products List, available from the same people.  You may be
disappointed to find that there are not many products which have
successfully made it through the evaluation process, and some that
have are no longer available.  Ask your librarian if they can get you
copies, ask a friend who has a Dockmaster account, or write to NCSC.

Len Lorence
Secure Computing Technology Corp.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 14:45:32 GMT
From:      corey@esl.com (Corey Yee)
To:        misc.security
Subject:   Re: Different security ratings

There's an article titled "Certifying A System's Security" in the
June 25th edition of "Unix Today!" that discusses the NCSC security ratings.

-----------[000026][next][prev][last][first]----------------------------------------------------
From:      Pete Nielsen                         <CSMSPCN@oac.ucla.edu>  15-JUL-1990  4:14:09
To:        security@pyrite.rutgers.edu
I'd ask a bank, I believe wired funds include an authentication
code.

RSA is an interesting question.  I heard that some mathematician
recently factored a 155 digit number, and that they are consequently
recommending at least 200 digit primes for the RSA stuff.
-----------[000027][next][prev][last][first]----------------------------------------------------
From:      owen blevins <blevinso@silver.ucs.indiana.edu>  15-JUL-1990  4:48:39
To:        security@ohstvma.bitnet
Need to find out if it is possible to obtain copy of YOUR record.
i.e. if i've been accused,convicted, etc. of a federal (or for that
matter state) crime.....I assume the FBI keeps it online somewhere--
is it possible (it probably is) to get a copy, and logically, how/who
do I contact to get a copy of my criminal record.

thanks!

blevinso@silver.ucs.indiana.edu
-----------[000028][next][prev][last][first]----------------------------------------------------
From:      09nilles%cuavax.dnet@netcon.cua.edu (Fiver Toadflax)  15-JUL-1990  5:23:52
To:        security@netcon.cua.edu
What you might try doing is to take and glue/fasten the pad to a steel sheet.
This sheet is then secured via cable to the same thing as the monitor or CPU.
The pad is now moviable, and yet is unlikely to walk out the door.

	     Dave

     09nilles@cua.bitnet
   Documentation Assistant
Catholic University of America
-----------[000029][next][prev][last][first]----------------------------------------------------
From:      smb@ulysses.att.com (Steven Bellovin)  15-JUL-1990  5:57:20
To:        misc-security@att.att.com
There was a paper published in Cryptologia Vol 11, no. 4, on cracking
Word Perfect 4.2; I have no idea if they changed the encryption
algorithm.  It was reprinted in ``Cryptology:  Machines, History,
and Methods''.  That same volume has a another reprint ``Survey of
Data Insecurity Packages'' that doesn't include Word Perfect; however,
the same author did a followup report on some other bad encryption
programs that you may want to look for.
-----------[000030][next][prev][last][first]----------------------------------------------------
From:      Stacey Son 377_4965 <sson%remus.Berkeley.EDU%@rutgers.edu>  15-JUL-1990  6:25:36
To:        misc-security@ucbvax.berkeley.edu
I have a friend who has a company that specializes in data recovery.
He markets a program that will recover crypted Word Perfect documents.
He also decrypts other programs such as Lotus, Microsoft Excel, etc.
You can reach him at the following address:

	Access Data Recovery
	% Eric Thompson
	87 E 600 S 
	Orem, UT 84058
	(801) 224-6970

-----------------------------------------------------------------------------
Stacey D. Son                         | "I think there is a world market for
Network Manager, Supercomputer Center | about five computers" -- Thomas J. 
Brigham Young University              | Watson, CEO, IBM Corporation, 1947
Dept. of Electrical/Computer Eng.     |
459 Clyde Building                    | "The number of UNIX installations has
Provo, UT 84602                       | grown to ten, with more expected." 
Voice:(801)378-5950 FAX:(801)378-6586 | -- UNIX Programmers Manual, 2nd 
Email: sson@ee.byu.edu                | Edition, June, 1972 
-----------------------------------------------------------------------------
-----------[000031][next][prev][last][first]----------------------------------------------------
From:      mii@philabs.philips.com (Melik I. Isbara)  15-JUL-1990  6:59:19
To:        misc-security@uunet.uu.net
I am posting this article to inform the netters about a problem with
Citibank ATM machines and to ask for any information and suggestions.
Please bear with me.

When I received my last bank statement, I have noticed three transactions
in which $900 dollars were withdrawn from my accounts from a Citibank
ATM machine at a downtown NYC branch which I have never used. 

FACTS:
	1.  I did not do those transactions.
	2.  When they took place I was at work out of NYC.
	3.  I did not lose my bankcard or give it to anyone.
	4.  I did not write down my password or tell it to anyone.

After I received my statement I went to my branch and talked to a customer
representative.  After a couple of days I got two letters from Citibank
saying that results of their investigation (which consists only of looking
at the ATM machine records for those specific transactions) showed that
for those transactions my bankcard and my password were used therefore
they could not honor my claim.

Now my guess is that this is most probably a software problem because last 
weekend I went to the branch where money was withdrawn and there was a sign 
on the door saying that the ATM machines there were out of order. I also
learned that they have been out of order for about a week.

I am goig to take a legal action against to Citibank therefore
I would like to know if anybody is aware of a similar situation or if anyone
has any ideas on how this might have happened.  I would appreciate any 
information and suggestions that can help me to fight Citibank to recover my 
money and to explain how this event might have happened.

Please e-mail to 
		  mii@briar.philips.com
		  isbara@cs.columbia.edu 
Thanks in advance.

Melik Isbara
Columbia University
Dept. of Electrical Eng.
-----------[000032][next][prev][last][first]----------------------------------------------------
From:      GREENY <MISS026@ecncdc.bitnet>  15-JUL-1990  7:30:46
To:        <security@pyrite.rutgers.edu>
Forget it.  Just put a decent alarm system on the car, with an ignition kill
and jack-up/motion sensor (and maybe an audio discriminator in case the glass
breaks), and a nice loud siren (maybe the traditional "flashing" LED), and
park in a lighted area.

For the most part, reinforcing the locks, and making them "slim-jim" proof
is next to impossible.  There isn't a car around, that a qualified locksmith
(or car repo. man, or car thief) cant get into quickly.  And the tools are
widely available, as are the instructions for the individual cars.

Besides, you sorta want your car to be slim-jim-able so that when you lock your
keys in it, or lose the things, then a locksmith can get you in!

If you really wanna go nuts, get a 4 channel programmable voice driver from
Oregon Scientific (no # readily available...), and use the different inputs
from the alarm to trigger different voice outputs...).

My car says "ILLEGAL TOWING IN PROGRESS" when jacked up/towed, yells "I'M
BEING STOLEN" when the door/trunk/hook is being opened, yells "YOU BROKE
MY WINDOW" when the glass gets broken....the 4th one I havent used...Also,
I have a remote control (RF) to arm/disarm, have capabilities for passive
arming, and have a pager linked into the alarm that will find me within 2
miles when the alarm goes off.....

So far, it has saved me at least once.  I had a crook trying to break into
the car on campus during the summer, when not too many people would hear
the siren, and my pager went off.  I went off after the damn guy with a
baseball bat.  He didnt get in, and I didnt get any whacks in, but the cops
found him shortly (seems that they heard the siren and were on the way...).

at any rate, had he gotten in, I have purposely used multi-colored wires
wrapped in seemingly insane configurations to confuse a crook, hidden
the relays that trigger the pager/ign. cutout in a radio shack project
box labeled HIGH VOLTAGE.  CAUTION. under the dash.  So it would take
this "genius" of crime a longggggg time to start my car, and steal it.

At most he would get the radio, and being a standard Ford install, he could
have it with my compliments....

bye for now but not for long
Greeny

BITNET: MISS026@ECNCDC
Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU
GEnie: GREENY
AOL: GREENY1
Compu$erve: 72567,457
Disclaimer: U use it, U B responsible fer it!
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 22:38:03 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        misc.security
Subject:   Re: Quantum Security

>     Because any measurement attempted by a third party would
> unpredictably alter a photon's polarization, an eavesdropper couldn't
> intercept the transmission without irrevocably scrambling the message

I don't see how this really gains you anything.  An eavesdropper can still
get in by cutting the line and putting in a complete receiver/transmitter
station.  The legitimate receiver will never see any tapped bits because
they can all be completely regenerated by the eavesdropper's transmitter.

Under some circumstances, the eavesdropper might have to receive a complete
message and do whatever ECC is necessary to compensate for the 50% error
rate on the line before forwarding the message on, but the legitimate
receiver should never know the difference.

> To check for eavesdropping, the receiver would simply
> compare notes with the sender

This implies an out-of-band communication.  If you have such a thing in
the first place, why use quantum signalling?  If the comparisons are
going over the quantum link, the eavesdropper can modify them in transit
to hide his own presence.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

-----------[000034][next][prev][last][first]----------------------------------------------------
From:      shz@packard.att.com (Seth Zirin)  17-JUL-1990  1:51:30
To:        security@rutgers.edu
>but as the number of masters increases, so does the ease of picking the lock

This is not necessarily correct.  It depends on the master keying algorithm
used.  I've rekeyed locks, changing them from a 2 level (1 level of MK) to
a 3 level (GMK, MK) and wound up with fewer pins in each lock.  Some would
say that with fewer pins in some of the stacks, the lock was more difficult to 
pick...

Seth Zirin, CPL
-----------[000035][next][prev][last][first]----------------------------------------------------
From:      levine@csd4.csd.uwm.edu (Leonard P Levine)  17-JUL-1990  2:26:38
To:        misc-security@uunet.uu.net
The reason for the low cut master is simply laziness on the part of
the locksmith, I believe.  When a lock is assembled, does not the
locksmith build up the pins in the rotating part by dropping in pieces
and then slide the assembly together?  If so, then there must be a key
in the lock to make the top of the pins level with the top of the
rotating part in order to let the system slide easily.  Similarly,
removal is done by the same method.  Put in a key, and remove the part
with the key in place.

If the Master is not the lowest key, a separate key would have to be
made for each lock assembled.  If the Master is the lowest, it may be
used for the assembly of each lock in turn.  Thus any locksmith paid
by the month will set up a Masterkey that is the lowest key in the
system.  Not good, but surely easy to work with.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                    e-mail levine@cs.uwm.edu |
| Professor, Computer Science             Office (414) 229-5170 |
| University of Wisconsin-Milwaukee       Home   (414) 962-4719 |
| Milwaukee, WI 53201 U.S.A.              FAX    (414) 229-6958 |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

[Moderator tack-on:  Not necessarily.  You don't need a key present to
*assemble* a lock at all; the plug can be inserted slightly offset and
everything will just drop into place when it's turned to locked position.
Also, any valid key will allow disassembly; you just have to retain all the
other parts in the shell with a thing referred to as a "following tool".
You can pick the rest of the parts out one by one afterward.  _H*]
-----------[000036][next][prev][last][first]----------------------------------------------------
From:      "Larry Margolis" <MARGOLI@ibm.com>  17-JUL-1990  2:59:28
To:        security@pyrite.rutgers.edu
> as the number of masters increases, so does the ease of picking the lock

Not necessarily.  You can have a sectional master section, where each pin
chamber has at the most one master pin.

Assume a 7-pin lock.  Pins 1 and 2 could be the site-wide master, pins
3 and 4 the building master, and pins 5 to 7 the floor master.  So, on
each floor, all the change keys will have pins 1 - 4 the same, and pins
5 - 7 different.  A floor master key would have cuts 1 - 4 the same as
the change keys for that floor, with cuts 5 - 7 cut to the master levels.
Each floor in the building be done similarly, with pins 1 and 2 the same
and pins 3 and 4 differing by floor.  The building master then has cuts
1 and 2 the same as all the other keys for that building, with cuts 3 to
7 cut to the master levels.  Finally, each building has pins 1 and 2
different, and the grand master key has all cuts cut to the master levels.

The one thing you *don't* want to do is put too many master pins in a
lock.  I once came across some Best padlocks that were meant to be opened
by any <company> serviceman in the state.  The locks had 2 or 3 master
pins in the first and last chambers, and chambers 2 - 6 had master pins
for *every level* !!!  The things practically fell open in my hands.
And, of course, once I had one in my posession, it was trivial to make a
control key for it so I could have gained access to any of their
buildings.  (What surprised me was that their locksmiths told them this
couldn't be done.)

Larry Margolis, MARGOLI@YKTVMV (bitnet), MARGOLI@IBM.COM (csnet)
-----------[000037][next][prev][last][first]----------------------------------------------------
From:      shz@packard.att.com (Seth Zirin)  17-JUL-1990  3:36:30
To:        security@rutgers.edu
>Seth, are you speaking from theory or do you have a high masterkey in 
>your posession?  I really want to know.

Both.

My home is master-keyed with Medeco Biaxial removable core locks.  The locks
are D-10 and D-11 deadbolts and Embassy cylindrical locksets.  The layout
is four level: GGMK, GMK, MK & CK.

	1) Each core has a separate combination (CK).
	2) There is a MK per side of each door (i.e., deadbolt and lockset)
	   and the MK that fits the inside cores on a door does not fit the
	   outside.  This prevents a delivery person from stealing an "exit"
	   key and using it to obtain entry.
	3) The outside cores are grouped under GMKs to provide "entry via the
	   front", "entry via the garage" or a "entry via the back" keys.
	4) All inside cores are grouped under a "fire egress" GMK so a
	   single key may be used to exit via any path.
	5) Every core opens with the Great Grand Master Key.

This system allows the change key (CK) for the front door lockset to be
left with a neighbor in case of a lockout, prevents a visitor from gaining
entry with a stolen "inside" key, and allows someone to enter to water
plants without letting them into the garage.

I set-up the master-keying system myself, including the calculations,
installation of the locks, pinning of the cores and cutting of the keys.
It turns out that only a few different keys were cut: the GGMK and several
GMKs, MKs and CKs.  No key in the system can be altered into a higher
level key and each key (including the GGMK and every GMK and MK) has
a wide range of cuts.  Each key has at least two cuts that differ by
the MACS (Maximum Adjacent Cut Separation) which varies from cut to
cut because of the fore and aft biaxial Medeco pins.

Seth Zirin, CPL

Member Associated Locksmiths of America
Member Safe and Vault Technicians Association
-----------[000038][next][prev][last][first]----------------------------------------------------
From:      mark%beowulf@ucsd.edu (Mark Anderson)  17-JUL-1990  4:11:24
To:        misc-security@sdcc6.ucsd.edu
Chapter 8.5 of the California "Business and Professions Code" is
the section relevant to Locksmiths. You'll have to check your
city charter for any local rules.

It is really most interested in people who work for hire to the general
public.

Some general definitions from the code
"Key duplicator" means an operator of a key duplicating machine who
merely duplicates keys for retail customers and who does not perform
an other functions of a locksmith.

"Locksmith" means a person, other than a key duplicator, who installs,
repairs, opens and modifies locks and who makes keys for locks.

Some relevant rules:
Permits.
On and after April 1, 1988, it is unlawful for any person to practice as
a locksmith without first obtaining a permit from the bureau.

Locksmiths working for hire; person exempt

(a) This chapter applies only to locksmiths working for hire.

(b) This chapter does not apply to the following persons:
 (1) Any person, or his or her agent or employee, who is the manufacturer
 of a product, other than locks and keys, and who installs, repairs, opens
 or modifies locks or who makes keys for the locks of that product as a 
 normal incident to its marketing.

 (2) Key duplicators.

 (3) Employees who are industrial or institutional locksmiths and whose
 services are provided only to an employer who does not provide locksmith
 services for hire to the public.

-------

You should be able to set yourself up as a key duplicator without any
problem.  You might stop by some key duplicating center and find someone
who will tell you how they go about ordering keys.

If you are interested in just a few blanks, I'm sure you can find a
key duplication place that will sell them to you uncut.

Another route is to take a mail correspondence locksmithing course.  
At the time I took mine, the cost was $400.  In the deal I got to keep 
a key making machine and can order locksmithing supplies (picks, blanks,
cutting machines, code books, etc) thru the mail order company.  I wouldn't 
recommend it unless you don't really care about the money. The first 
lesson was something like match like keys together in pairs.  

 From experience I know you can buy stuff and subscribe to trade journals
as a "student of locksmithing".

mark anderson
~
-----------[000039][next][prev][last][first]----------------------------------------------------
From:      "Michael J. Chinni, SMCAR_CCS_E" <mchinni@pica.army.mil>  17-JUL-1990  5:41:33
To:        security@pyrite.rutgers.edu
FYI ... (this is a long message: 155+ lines)

Date: Wed, 27 Jun 90 22:19:44 -0400
From: Theodore Lee <lee@TIS.COM>
Subject: The F9 factoring result

MESSAGE FROM RON RIVEST VIA JIM BIDZOS VIA STEVE KENT VIA STEVE CROCKER:
Thanks to Robert Silverman for keeping many people honest.
As an additional effort to that end, I attach an analysis of
the recent factoring effort, done by Ron Rivest.  The early 
reports of RSA's demise have been greatly exaggerated...
Note: Be sure and read the end of Rivest's note.
Jim Bidzos, RSA Data Security

To:	Whom It May Interest (Feel free to distribute further...)
From:	Ronald L. Rivest
Date:	June 21, 1990
Re:	Recent Factoring Achievement
	(Preliminary draft; may contain typos or other inaccuracies.
	Please send corrections to rivest@theory.lcs.mit.edu)

This note is in response to the numerous inquiries I've received regarding
the recent factoring of a 155-digit number by A. Lenstra, M. Manasse, and
others.  (See the New York Times article of 6/20/1990 by G. Kolata.) 
This note attempts specifically to correct some of the misimpressions that
may arise from a reading of such popular press articles.

Using an ingenious new algorithm, Lenstra, Manasse, and others have
factored the 155-digit number known as "F9", the ninth Fermat number:
		F9 = 2^(2^9) + 1 = 2^(512) + 1 .
In binary, this number has the form
		100000....000000001
where there are 511 zeros altogether.  (F9 is a 513-bit number.)
This is a fascinating development, and the researchers involved are to be
congratulated for this accomplishment.

The algorithm used is known as the "number field sieve", or "NFS" (not
to be confused with a network protocol of the same acronym!).  The NFS
algorithm is described in the Proceedings of the 1990 ACM STOC Conference.
The NFS algorithm is based on an idea due to Pollard, as developed further by
Arjen Lenstra, Hendrik W. Lenstra, and Mark S. Manasse.

The NFS algorithm is specifically designed to factor numbers that,
like F9, have a very simple structure: they are of the form
		a^b + c 
where c is relatively small.  (For F9, we have a=2, b=512, and c=1.)
Some simple extensions of this algorithm are also possible, to handle
numbers whose binary representation has many zeros, and related kinds
of numbers (ternary, etc.)  Numbers that have such a special structure are
extremely rare and are unlikely to be encountered by chance.  That is,
the NFS algorithm does not apply to the kind of "ordinary" numbers that
arise in practical cryptography, such as using RSA.  They only apply to
numbers with "sparse" representations having few nonzero components.
(Let us call such numbers "rarefied".)

When working on a rarefied number, the NFS algorithm has an estimated
running time of the form (for an input number n):
		exp(1.56 (ln n)^1/3 (ln ln n)^2/3)			(1)
For n = F9, this evaluates to 
		4.1 x 10^15 operations,
which, at 3.15 x 10^13 operations/year for a 1 MIP/sec machine (i.e. a
MIP-year), gives a workload estimate of
		130 MIP-years,
only off by a factor of two from the actual work of 275 MIP-years. (That is,
formula (1) may be roughly too low by a factor of two.)

It is instructive to see the effect of doubling the size of the number
being dealt with.  A 1024-bit (332-digit) rarefied number requires an estimated
		1.54 x 10^21 operations
	=	4.9 x 10^7 MIP-years,
a dramatic increase in difficulty.  The NFS algorithm algorithm is not a
"polynomial-time" algorithm; the difficulty of factoring still grows
**exponentially** with a polynomial function of the length of the input.

What has this to do with RSA and cryptography?  I think there are three
basic points:
	-- This development indicates that the status of factoring is
	   still subject to further developments, and it is wise to be
	   conservative in one's choice of key-length.
	-- The NFS algorithm may yet be generalized to handle "ordinary"
	   numbers, and the potential impact of this should be considered.
	-- Factoring is still a very hard problem, despite everyone's best
	   efforts to master it.

Regarding the further extensions of NFS to handle ordinary numbers, this is
judged to be a reasonable possibility by those working on NFS, so it is 
helpful to consider what impact this may have.

It is conjectured (see the ACM STOC paper referenced above) that a successful
extension of the NFS algorithm to ordinary numbers would have a running time
of the form:
		exp(2.08 (ln n)^1/3 (ln ln n)^2/3)			(2)
This is similar to equation (1) except that the constant 1.56 is
replaced by the constant 2.08.  Note that a practical version of such
an extension does NOT yet currently exist (to the best of my
knowledge), but even granting its plausibility we arrive at an
estimate of the tie required to factor a 512-bit number of
		6.5 x 10^20 operations
	= 	2 x 10^7 MIP-years
which (in my opinion) is a substantial degree of security.  It is 
interesting to note that this work factor is actually GREATER than that
required by the ``standard'' factoring algorithms (e.g., the quadratic sieve),
which have a running time of
		exp((ln n)^1/2 (ln ln n)^1/2);
for a 512-bit number, this gives a work-factor estimate of only
		6.7 x 10^19 operations.
Indeed, the NFS algorithm (when extended) will be asymptotically superior than
the quadratic sieve algorithm, but will be slower for numbers with less 
than about 200 digits.  That is, assuming that (2) is indeed the correct
running-time estimate for any extension of NFS, then NFS will not affect the
security of any numbers of less than about 215 digits.  So any "standards"
that have been considered using 512-bit RSA moduli are not likely to be
affected by any NFS extensions.  (At most, one could imagine that the
RSA key-generation process might be extended to check that the resulting
modulus n is not a rarefied number.)

In the truly worst-case scenario, we would have that an extension of
NFS would be found that allows ordinary numbers to be factored with a
work-factor that is governed by equation (1); in this case one would
need to adjust the sizes of moduli used by RSA upwards by a factor of
less than two to more than offset the new algorithm.  A factor of two
in size affects the running time of public-key encryption (or
signature verification) by a factor of four and the running time of
private-key encryption (or signature generation) by a factor of eight.
Noting that the speed of workstations has increased by a factor of
over 100 in the last decade (indeed, such factors have been the
technological advance that made the successful implementation of NFS
possible!), such performance penalties, if necessary, seem to be
easily absorbed by expected technological advances in the speeds of
the underlying RSA implementation technologies.  That is, the NFS-like
factoring algorithms do not, even in this worst-case scenario, prevent
successful implementations of the RSA cryptosystem.

As a cryptographer, I am actually very happy with all the effort that
is being spent trying to determine the exact level of difficulty of
factoring.  Achievements such as the recent development of NFS help to
pin down the best-possible rate of growth of the difficulty of
factoring, so that users of cryptographic schemes can pick key sizes
with an increased degree of confidence that unforeseen developments
are unlikely to occur.  The best way to ensure confidence in a
cryptographic system is to have it attacked vigorously and
continuously (but unsuccessfully) by well-qualified attackers.  If,
despite their best efforts, the difficulty of cracking the system
remains intrinsically exponential, then one can have a reasonably high
degree of confidence that the system is actually secure.  This is the
process we have been seeing at work in the recent work on factoring.
The results of the attacks can be used to guide the selection of the
necessary key size for a desired level of security (with an
appropriate margin of safety built in, of course).

(As a closing note, here's a prediction: I expect that the 128-digit
``challenge RSA cipher'' published in the August 1977 issue of
Scientific American to be cracked (probably by the quadratic sieve
algorithm or a variant, not NFS) during the next 1-3 years.  This
accomplishment will require substantially more computer time than the
275 MIP-years required to factor F9.)
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 01:01:22 GMT
From:      bishop@BEAR.DARTMOUTH.EDU (Matt Bishop)
To:        misc.security
Subject:   UNIX Security Workshop

I don't read this list, but the following message was pointed out to me:

> The organizer of the workshop is Matt Bishop,  Dept of Mathematics &
> Computer Science, Bradley Hall, Dartmouth College, Hanover, NH 03755 (603)
> 646-2415

Here is the complete blurb, with the program and other relevant information.
If you have any questions, please contact me (Matt.Bishop@dartmouth.edu) or
the USENIX office.  I'm handling the technical end (program, panels, etc.);
they are doing everything else (thank goodness!)

Matt

-----

UNIX Security Workshop
Marriott Hotel, Portland, OR, August 27-28, 1990

     The Second USENIX UNIX Security Workshop will be held in Portland, Oregon
on Monday and Tuesday, August 27-28, 1990.  The workshop is organized to bring
researchers, system administrators and others together to discuss their needs
and interests in the many aspects of computer security as they relate to the
UNIX Operating System.

     This meeting will have elements of both a conference and a workshop; the
former in that there will be presentations, the latter in that discussion and
audience participation are expected.  Speakers will discuss work in progress
and/or work that is planned and will solicit opinions, comments and sugges-
tions from other participants.   There will be at least three panel sessions.

Tentative Program

Monday, August 27

9-10:30  Authentication I

David Goldberg, MITRE
The MITRE User Authentication System

Daniel Klein, Software Engineering Institute, CMU
A Survey of, and Improvements to, Password Security

Matt Bishop, Dartmouth College
An Extensible Password Changing Program

Michele Crabb, NASA Ames Research Center
Password Security in a Large Distributed Environment

11-12  Potpourri I

Maria Pozzo, UCLA Computer Science Dept.
An Automatic Policy Checker for Controlling Undesirable Program Behaviors

John Linn, DEC
Generic Security Service Application Program Interface

Henry Teng, DEC, and David Brown, Worchester Polytechnic Institute
An Expert Systems Approach to Security Inspection of UNIX

1:30-2:30  Secure Systems and Tools

Raymond Wong, Oracle
A Survey of Secure UNIX Operating Systems

David Gill, MITRE
Roles for Users and Privileges for System Processes:
High Trust Mechanisms for Low Trust Systems

Pat Bahn, GTE
Beyond Bell-LaPadula:  A Security Model for Real Applications

3:00-5:00  Access Control

Marshall Abrams, Leonard LaPadula, & Ingrid Olson, MITRE
Building Generalized Access Control on UNIX

David Wichers, ARCA Systems, and Douglas Cook, Ronald Olsson, John Crossley,
Paul Kerchen, Karl Levitt, & Raymond Lo, University of California at Davis
An Access Control List Approach to Anti-Viral Security

Frank Kardel, Friedrich Alexander University
Frozen Files

Hermann Strack, University of Karlsruhe
to be arranged

Panel and discussion on access control

Tuesday, August 28

9-10:30  Authentication II

Ana Maria De Alvare, Lawrence Livermore National Laboratory
How Crackers Crack Passwords

Steven Lunt, Bellcore
Experiences with Kerberos

Joe Tardo, Kannan Alagappan, & Richard Pitkin, DEC
Public Key-based Authentication using Internet Certificates

Panel and discussion on authentication

11-12  Security Considerations and the Environment

Richard Neely, Ford Aerospace
System Design and Verification for Secure Applications Under UNIX

Gary Christoph, Los Alamos National Laboratory
Security Considerations of Going to a UNIX Based
Supercomputer Operating System

Bjorn Satdeva, /sys/admin, inc.
to be arranged

1:30-3:15  Networked Systems

Mark Carson, Janet Cugini, Sohail Malik, Mythili Kannan, & Wen-Der Jiang, IBM
Networked UNIX without the Superuser

Jeffrey Roth, Defense Logistics Agency
Hardening Anonymous FTP

Jerry Carlin, Pacific Bell
Gateway Security Measures

Eugene Schultz, Lawrence Livermore National Laboratory
UNIX Network Naivete

Panel and discussion on network security

3:45-5  Potpourri II

Fuat Baran, Howard Kaye, & Margarita Suarez, Columbia University
Security Breaches:  Five Recent Incidents at Columbia University

Panel and discussion on security in Large installations
______________________________

Program Chair:  Matt Bishop, Dept. of Mathematics & Computer Science, Dart-
mouth College

Full-time students please note:  a limited number of scholarships are avail-
able.  For an application form contact office@usenix.org

For registration information, contact:

	USENIX Conference Office
	22672 Lambert Street, Suite 613
	El Toro, CA 92630
	(714) 588-8649
	(714) 588-9706 (FAX)

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 14:54:52 GMT
From:      pyron@skvax1.csc.ti.com (If Clayton's an Aggie, I'm not!)
To:        misc.security
Subject:   Re: Authentication of electronic commercial documents

>recently factored a 155 digit number, and that they are consequently
>recommending at least 200 digit primes for the RSA stuff.

The original article in CACM recommended 200 digit numbers, but made note of
the fact that factor these larges numbers was difficult, which is both a
blessing and a curse.  Of course, difficult in 1977 is a breeze in 1991?

Dillon Pyron                         | The opinions are mine, the facts 
TI/DSEG VAX Systems Support          | probably belong to the company.
pyron@skvax1.ti.com                  |
(214)575-3087                        | Jim Henson - Now that was talent
                                     | 

-----------[000042][next][prev][last][first]----------------------------------------------------
From:      simsong@next.cambridge.ma.us (Simson L. Garfinkel)  22-JUL-1990  1:42:32
To:        security@pyrite.rutgers.edu
Has anybody heard about this, Sun's new NFS authentication system that
uses public key encryption?
-----------[000043][next][prev][last][first]----------------------------------------------------
From:      lorence@sctc.com (Len Lorence)  22-JUL-1990 10:55:42
To:        misc-security@uunet.uu.net
>Can someone please show me what the different "security levels" mean in 
>terms of operating system. What I mean is one sees that "xxx's o/s is a
>B2 rating". What is B2 and what are the different availale levels?

What you want is a copy of the DOD Trusted Computer System Evaluation
Criteria (DOD 5200.28-STD) from the National Computer Security Center.
It sets the criteria for a system to meet each of the evaluation
ratings (D, C1, C2, B1-3, and A1.)  You also want a copy of the
Evaluated Products List, available from the same people.  You may be
disappointed to find that there are not many products which have
successfully made it through the evaluation process, and some that
have are no longer available.  Ask your librarian if they can get you
copies, ask a friend who has a Dockmaster account, or write to NCSC.

Len Lorence
Secure Computing Technology Corp.
-----------[000044][next][prev][last][first]----------------------------------------------------
From:      srt@grad19.cs.duke.edu (Stephen R. Tate)  22-JUL-1990 11:19:51
To:        misc-security@mcnc.org
> RSA is an interesting question.  I heard that some mathematician
> recently factored a 155 digit number, and that they are consequently
> recommending at least 200 digit primes for the RSA stuff.

AARRGGHH!!!  You would not believe how many people I have heard say this
lately, and is proof that a little information is a dangerous thing.
The "popular press" (Washington Post, New York Times,...) ran a story
saying exactly the above, so it's no wonder that people have this impression.

Now the REAL story:  the number factored was of a very special form,
and the algorithm used excelled for numbers of that form (in fact, the
algorithm was originally developed *only* for numbers of that form).
The RSA algorithm does not use numbers of this form (it uses the product
of two randomly generated large primes), and so public keys of the form
used by RSA are in NO DANGER from the new algorithm.

Steve Tate			ARPA:  srt@duke.cs.duke.edu
				UUCP: ..!decvax!duke!srt
-----------[000045][next][prev][last][first]----------------------------------------------------
From:      nagle@well.sf.ca.us (John Nagle)  22-JUL-1990 11:49:15
To:        misc-security@uunet.uu.net
>Basically, Iwould like to know if there has been any work on MVS and/or CMS
>platforms to keep users from picking obvious passwords, like their name,

       I first posted a simple solution to this problem back in 1984.  The
technique used does not require any dictionary or large tables; it relies
on some statistics of letter sequence usage in English which allow one to
determine whether something is a likely English word.  The code can be obtained
from the comp.sources.unix archive, or I can send a copy to interested parties.
The code is in C, but there is no UNIX dependency; in fact, I wrote the
original code on a DECsystem 2060, in C.  The archive reference appears below.

						John Nagle

Newsgroups: comp.sources.unix
Subject: v16i060:  Tell if a password is "obvious"
Date: 10 Nov 88 14:47:09 GMT
Submitted-by: "John B. Nagle" <jbn@glacier.stanford.edu>
Posting-number: Volume 16, Issue 60
Archive-name: obvious-pw

[  This program does NOT try brute-force methods to guess passwords,
   but instead tells if a password is an "obvious" one likely to be
   guessed by such a program. ]
-----------[000046][next][prev][last][first]----------------------------------------------------
From:      Will Martin <wmartin@stl_06sima.army.mil>  22-JUL-1990 12:13:13
To:        owen blevins <blevinso@silver.ucs.indiana.edu>
Cc:        security@pyrite.rutgers.edu
Here in St. Louis, getting a copy of your "criminal record" or police
record is part of the pistol-permit process. It appears there is no
restriction on any individual getting a copy; it costs $10 and I suppose
it is a nice source of extra income for the city or the department. All
you need is $10 cash or money order (no checks) and ID, like a drivers
license. You go to an office at the main downtown police station and
fill out a short request form, and hand over your ID & money. They keep
the money and give back the ID. :-) You wait 10 minutes or so. If you
have no record, all you get in return is a form with a big purple stamp
on it that says something like "NO RECORD FOUND". If you have a record,
you get some sort of printout with the data on it. (All I got back was
the stamped form, so I can't offer details on what a record-printout
is like... :-) Most of the other people there getting records seemed to
be getting them for security-guard job applications.

Regards, Will Martin
-----------[000047][next][prev][last][first]----------------------------------------------------
From:      fitz@wang.com (Tom Fitzgerald)  22-JUL-1990 12:38:39
To:        misc-security@uunet.uu.net
>     Because any measurement attempted by a third party would
> unpredictably alter a photon's polarization, an eavesdropper couldn't
> intercept the transmission without irrevocably scrambling the message

I don't see how this really gains you anything.  An eavesdropper can still
get in by cutting the line and putting in a complete receiver/transmitter
station.  The legitimate receiver will never see any tapped bits because
they can all be completely regenerated by the eavesdropper's transmitter.

Under some circumstances, the eavesdropper might have to receive a complete
message and do whatever ECC is necessary to compensate for the 50% error
rate on the line before forwarding the message on, but the legitimate
receiver should never know the difference.

> To check for eavesdropping, the receiver would simply
> compare notes with the sender

This implies an out-of-band communication.  If you have such a thing in
the first place, why use quantum signalling?  If the comparisons are
going over the quantum link, the eavesdropper can modify them in transit
to hide his own presence.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz
-----------[000048][next][prev][last][first]----------------------------------------------------
From:      mccurley@cs.sandia.gov (Kevin McCurley)  22-JUL-1990 13:01:13
To:        security@pyrite.rutgers.edu
The recent factorization of a 155 digit number was a remarkable feat, but
it holds less interest for RSA than meets the eye.  The number that
was factored was 2^512+1.  This number has binary representation

100000000000000000000000  ...  00000000000000000000001

which is of course rather special.  In fact, the method at present
works only for numbers of a very special form, and a much better gauge
of current factoring progress is provided by the RSA challenge number
that was published in Scientific American years ago.  This number has
"only" 129 decimal digits, but it has never been factored, in spite of
the obvious publicity that would result from this.  It is estimated
that the RSA challenge number might take 10 times as much work to
factor as the 155 digit number factored recently.

The moral of the story is that as a result of many people working on the
problem, we have seen a steady improvement in what numbers can be factored.
We are NOT yet to a point where generic 155 digit numbers can be factored,
but future advances may allow us to do so.  If it's a question of adopting
a system for which the modulus must be good for ten years, then I might be
skeptical about a 155 digit modulus.  For a 200 digit modulus, we will need
a significant new idea to be able to factor those.  We stand a far greater
risk from a total collapse of the banking system!

Kevin McCurley
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 90 13:37:32 GMT
From:      ah0i+@ANDREW.CMU.EDU ("Andrew A. Houghton")
To:        misc.security
Subject:   locksmithing schools

I know this subject has probably been run into the ground, but could
people please send me the addresses for good locksmithing schools,
along with any thoughts they have about them (like relative merits,
etcetera)

Please e-mail, no need to post on the net.

Andrew Houghton
(ah0i@andrew.cmu.edu)

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 90 15:42:12 GMT
From:      de5@STC06.CTD.ORNL.GOV (SILL D E)
To:        misc.security
Subject:   Re: Authentication of electronic commercial documents

>Now the REAL story:  the number factored was of a very special form,

AARRGGHH!!  Apparently you missed the recently posted article
(comp.risks?) by Ron Rivest (the `R' in RSA) that gave the REAL story.
Actually, both of the above posters are (in)correct.  The number
factored was of the form 10000...00001 (binary).  Such numbers are
used by RSA only by coincidence, that is to say very rarely.

Rivest further conjectured that that and other developments in
factoring would lead to the breaking of some short-key RSA within a
couple years, I believe (this is from memory, I forget the numbers).
He also said they were recommending longer keys for paranoids...er...
folks wanting utmost security.

Anybody save that article?  How 'bout posting it or sending me a copy?

-- 
--
Dave Sill (de5@ornl.gov)		These are my opinions.
Martin Marietta Energy Systems
Workstation Support

-----------[000051][next][prev][last][first]----------------------------------------------------
From:      UCCXNCS@osucc.bitnet  26-JUL-1990  6:45:00
To:        security@ohstvma.bitnet
  Since userid maintenance and security seem to go hand-in-hand, I
thought I might be able to get some ideas on how to go about
attacking a problem we are facing here at OSU.  If you know of a
list that addresses this sort of thing, please let me know.
Userid creation and maintenance is one of our biggest headaches.
   We have an IBM 3090 on which we run VM/SP with MVS running
as a guest under it.  The MVS system is used mainly by our
administrative users.  We have only had VM a few months and are
wanting to open it up to our academic users who, for the most
part, abhor MVS and JCL.  The idea is for the VM system to be
"friendlier", not requiring password changes, etc.
   So, we are looking for ideas on how to automate the setup
and maintenance of permanent (faculty) and temporary (student)
userids on the VM system.  Right now we are managing the few
VM userids that we have set up through DIRMAINT.  However, we
do have VMSECURE setting on the shelf.
  It seems to me that DIRMAINT is rather cumbersome, and I'm
not sure how we could set up an automated process that would
create several hundred userids using DIRMAINT.  Anyone that
has dealt with this problem and would be willing to give us
some suggestions is welcome to respond.
   Nancy C. Stevens  (405) 744-6301
   uccxncs@osucc.bitnet
-----------[000052][next][prev][last][first]----------------------------------------------------
From:      Hoffman.es@xerox.com  26-JUL-1990  7:13:40
To:        SECURITY@rutgers.edu
[Moderator injection: Apologies to those who have already seen this sixteen
times, but there might be folks out there who haven't yet.  Use your D key
or local equivalent.  _H*]

          COMPUTER PROFESSIONALS FOR SOCIAL RESPONSIBILITY

                           PRESS RELEASE

Embargoed for release on July 10, 1990

CPSR TO UNDERTAKE EXPANDED CIVIL LIBERTIES PROGRAM

CPSR, a national computing organization, announced today that it would
receive a two-year grant in the amount of $275,000 for its Computing and
Civil Liberties Project.  The Electronic Frontier Foundation, founded by
Mitchell Kapor and John Barlow, made the grant to expand ongoing CPSR
work on civil liberties protections for computer users.

At a press conference in Washington today, Mr. Kapor praised CPSR's
work.  "CPSR plays an important role in the computer community.  For the
last several years, it has sought to extend civil liberties protections
to new information technologies.  Now we want to help CPSR expand that
work."

Marc Rotenberg, director of the CPSR Washington Office said, "We are
obviously very happy about the grant from the EFF.  There is a lot of
work that needs to be done to ensure that our civil liberties
protections are not lost amidst policy confusion about the use of new
computer technologies."

CPSR said that it will host a series of policy round tables in
Washington, DC, during the next two years with lawmakers, computer users
including "hackers," the FBI, industry representatives, and members of
the computer security community.  Mr. Rotenberg said that the purpose of
the meetings will be to "begin a dialogue about the new uses of
electronic media and the protection of the public interest."

CPSR also plans to develop policy papers on computers and civil
liberties, to oversee the Government's handling of computer crime
investigations, and to act as an information resource for organizations
and individuals interested in civil liberties issues.

The CPSR Computing and Civil Liberties project began in 1985 after
President Reagan attempted to restrict access to government computer
systems through the creation of new classification authority.  In 1988
CPSR prepared a report on the proposed expansion of the FBI's computer
system, the National Crime Information Center.  The report found serious
threats to privacy and civil liberties.  Shortly after the report was
issued, the FBI announced that it would drop a proposed computer feature
to track the movements of people across the country who had not been
charged with any crime.

"We need to build bridges between the technical community and the policy
community," said Dr. Eric Roberts, CPSR President and a research
scientist at Digital Equipment Corporation in Palo Alto, California.
"There is simply too much misinformation about how computer networks
operate.  This could produce terribly misguided public policy."

CPSR representatives have testified several times before Congressional
committees on matters involving civil liberties and computer policy.
Last year CPSR urged a House Committee to avoid poorly conceived
computer crime laws that could criminalize a wide range of computer
activity.  "In the rush to criminalize the malicious acts of the few we
may discourage the beneficial acts of the many," warned CPSR.  A House
subcommittee recently followed CPSR's recommendations on computer crime
amendments.

Dr. Ronni Rosenberg, an expert on the role of computer scientists and
public policy, praised the new initiative.  She said, "It's clear that
there is an information gap that needs to be filled.  This an important
opportunity for computer scientists to help fill that gap."

CPSR is a national membership organization of computer professionals,
based in Palo Alto, California.  CPSR has over 2,000 members and 21
chapters across the country.  In addition to the civil liberties
project, CPSR conducts research, advises policy makers and educates the
public about computers in the workplace, computer risk and reliability,
and international security.

For more information contact:

     Marc Rotenberg
     CPSR Washington Office
     1025 Connecticut Avenue NW
     Suite 1015
     Washington, DC  20036
     (202) 775-1588

     Gary Chapman
     CPSR National Office
     P.O. Box 717
     Palo Alto, CA  94302
     (415) 322-3778
-----------[000053][next][prev][last][first]----------------------------------------------------
From:      corey@esl.com (Corey Yee)  27-JUL-1990 12:17:55
To:        misc-security@ames.arc.nasa.gov
There's an article titled "Certifying A System's Security" in the
June 25th edition of "Unix Today!" that discusses the NCSC security ratings.
-----------[000054][next][prev][last][first]----------------------------------------------------
From:      Don Irmiger <don@delta.com>  27-JUL-1990 12:42:23
To:        SECURITY@ohstvma.ircc.ohio-state.edu
These are rating systems per the DOD as defined in "the Orange Book".  UNIX
Sys V is classified at a C2 rating (poor).  Some O/S extensions can improve
this to about B2-B1.  I've not heard of an out-of-the-box implementation in
the A classification...
--
Donald K. Irmiger III                                 UUCP: uunet!delta.com!don
Data Systems Coordinator                          Internet: don@delta.com
Michiana Rehabilitation Institute's Data Systems Center \ Altos 2086/Xenix 3.4b
-----------[000055][next][prev][last][first]----------------------------------------------------
From:      Matt Bishop <bishop@bear.dartmouth.edu>  27-JUL-1990 13:06:22
To:        security@marist.bitnet
I don't read this list, but the following message was pointed out to me:

> The organizer of the workshop is Matt Bishop,  Dept of Mathematics &
> Computer Science, Bradley Hall, Dartmouth College, Hanover, NH 03755 (603)
> 646-2415

Here is the complete blurb, with the program and other relevant information.
If you have any questions, please contact me (Matt.Bishop@dartmouth.edu) or
the USENIX office.  I'm handling the technical end (program, panels, etc.);
they are doing everything else (thank goodness!)

Matt

-----

UNIX Security Workshop
Marriott Hotel, Portland, OR, August 27-28, 1990

     The Second USENIX UNIX Security Workshop will be held in Portland, Oregon
on Monday and Tuesday, August 27-28, 1990.  The workshop is organized to bring
researchers, system administrators and others together to discuss their needs
and interests in the many aspects of computer security as they relate to the
UNIX Operating System.

     This meeting will have elements of both a conference and a workshop; the
former in that there will be presentations, the latter in that discussion and
audience participation are expected.  Speakers will discuss work in progress
and/or work that is planned and will solicit opinions, comments and sugges-
tions from other participants.   There will be at least three panel sessions.

Tentative Program

Monday, August 27

9-10:30  Authentication I

David Goldberg, MITRE
The MITRE User Authentication System

Daniel Klein, Software Engineering Institute, CMU
A Survey of, and Improvements to, Password Security

Matt Bishop, Dartmouth College
An Extensible Password Changing Program

Michele Crabb, NASA Ames Research Center
Password Security in a Large Distributed Environment

11-12  Potpourri I

Maria Pozzo, UCLA Computer Science Dept.
An Automatic Policy Checker for Controlling Undesirable Program Behaviors

John Linn, DEC
Generic Security Service Application Program Interface

Henry Teng, DEC, and David Brown, Worchester Polytechnic Institute
An Expert Systems Approach to Security Inspection of UNIX

1:30-2:30  Secure Systems and Tools

Raymond Wong, Oracle
A Survey of Secure UNIX Operating Systems

David Gill, MITRE
Roles for Users and Privileges for System Processes:
High Trust Mechanisms for Low Trust Systems

Pat Bahn, GTE
Beyond Bell-LaPadula:  A Security Model for Real Applications

3:00-5:00  Access Control

Marshall Abrams, Leonard LaPadula, & Ingrid Olson, MITRE
Building Generalized Access Control on UNIX

David Wichers, ARCA Systems, and Douglas Cook, Ronald Olsson, John Crossley,
Paul Kerchen, Karl Levitt, & Raymond Lo, University of California at Davis
An Access Control List Approach to Anti-Viral Security

Frank Kardel, Friedrich Alexander University
Frozen Files

Hermann Strack, University of Karlsruhe
to be arranged

Panel and discussion on access control

Tuesday, August 28

9-10:30  Authentication II

Ana Maria De Alvare, Lawrence Livermore National Laboratory
How Crackers Crack Passwords

Steven Lunt, Bellcore
Experiences with Kerberos

Joe Tardo, Kannan Alagappan, & Richard Pitkin, DEC
Public Key-based Authentication using Internet Certificates

Panel and discussion on authentication

11-12  Security Considerations and the Environment

Richard Neely, Ford Aerospace
System Design and Verification for Secure Applications Under UNIX

Gary Christoph, Los Alamos National Laboratory
Security Considerations of Going to a UNIX Based
Supercomputer Operating System

Bjorn Satdeva, /sys/admin, inc.
to be arranged

1:30-3:15  Networked Systems

Mark Carson, Janet Cugini, Sohail Malik, Mythili Kannan, & Wen-Der Jiang, IBM
Networked UNIX without the Superuser

Jeffrey Roth, Defense Logistics Agency
Hardening Anonymous FTP

Jerry Carlin, Pacific Bell
Gateway Security Measures

Eugene Schultz, Lawrence Livermore National Laboratory
UNIX Network Naivete

Panel and discussion on network security

3:45-5  Potpourri II

Fuat Baran, Howard Kaye, & Margarita Suarez, Columbia University
Security Breaches:  Five Recent Incidents at Columbia University

Panel and discussion on security in Large installations
______________________________

Program Chair:  Matt Bishop, Dept. of Mathematics & Computer Science, Dart-
mouth College

Full-time students please note:  a limited number of scholarships are avail-
able.  For an application form contact office@usenix.org

For registration information, contact:

	USENIX Conference Office
	22672 Lambert Street, Suite 613
	El Toro, CA 92630
	(714) 588-8649
	(714) 588-9706 (FAX)
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 14:28:00 GMT
From:      EVERHART@arisia.dnet.ge.com
To:        misc.security
Subject:   "secure nfs"

If looking for a secure distributed file system, I'd suggest checking
out AFS, from Transarc. It uses Kerebros authentication, and supplies
tools for maintenance of large networks. It was designed for 10,000+
workstation environments and scales much better than NFS; also tends
to avoid eating networks for lunch as NFS can and does. Transarc is
in Pittsburgh; 412 338 4400; their domain name is transarc.com.
Glenn

-----------[000057][next][prev][last][first]----------------------------------------------------
From:      "Richard B. August" <AUGUST@vlsi.jpl.nasa.gov>  28-JUL-1990 10:11:24
To:        SECURITY-REQUEST@pyrite.rutgers.edu
In a posting, sometime within the last couple of years, there was mention
of the existence of an article purported to have been published in the
Soviet Academy of Applied Sciences.  The posting went on to describe
how someone at this Academy had developed a "table" with which one could
break DES.  This subject came up recently and I "quoted" the posting.
Naturaly those skeptics in the audience want "proof".  If anyone out there
remembers the posting or (even better) the publication in which this appeared,
please let me know.

Thanks in advance.

Richard B. August
august@vlsi.jpl.nasa.gov
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 17:28:04 GMT
From:      tep@tots.logicon.com (Tom Perrine)
To:        misc.security
Subject:   cheap Master combo lock

I have one of those cheap Master combination locks that I need to
remove, and the combination is long gone.

The options I can think of are (in order of preference):
	get combination from Master (from serial number)
	bolt cutters
	hacksaw

Of course, the cheaper the better, so a locksmith is out. I'm not in
any hurry, can I just call (or write) to Master and get the
combination? I really don't care about the lock, but if I can get the
combo, thats easier than finding some bolt cutters or spending an
hour? with a hacksaw....

Any recommendations?

Tom Perrine (tep)

-----------[000059][next][prev][last][first]----------------------------------------------------
From:      nitrex!rbl@uunet.uu.net ( Dr. Robin Lake )  1-AUG-1990 22:22:09
To:        misc-security@uunet.uu.net
It is possible to write to the FBI and ask them if they have a folder on
you and to send you a copy of the contents of the folder if the folder does
exist.
-----------[000060][next][prev][last][first]----------------------------------------------------
From:      *Hobbit* <security_request@pyrite.rutgers.edu>  1-AUG-1990 23:43:16
To:        security@pyrite.rutgers.edu
[Crunched into a "digest" to save a little network bandwidth.  _H*]

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: 19 Jun 90 11:49:49 GMT
From: Doug Gwyn <gwyn@smoke.brl.mil>
To: misc-security@rutgers.edu

The solution is so obvious that I wonder that you don't see it --
Stop gratuitously requiring people to change their passwords.
If the password is not thought to have been compromised, there
is more reason to continue using it than to change it.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: 19 Jun 90 20:08:41 GMT
From: levine@csd4.csd.uwm.edu (Leonard P Levine)
To: misc-security@uunet.uu.net

I carefully examied the material on making Unix more secure (Improving the 
security of your Unix System by David Curry, SRI International) in hopes 
of finding just why changing the password makes a system secure.  Curry's 
well thought out work has many good suggestions but he says about changing
passwords only the following: (page 7)

"Finally it is important to establish a policy that users must change 
their passwords from time to time, say twice a year."

He gives no reason for such a need, although all of the other problems 
he discusses are couched in terms of speed of cracking and methods of
penetration.

He (correctly) points out that users should never write down their 
passwords, should not use easy to guess words, and the like, but somehow 
feels that a user who has a good password, who never allows him/herself 
to be observed logging in, who sees no history of problems, should 
nevertheless change the password fairly often.

Why twice a year?  Why not twice a day?  I think it would be better
to have a good password that you do not have to write down because 
you know it (from long and careful use) than to have a password 
that you write down because you easily forget it, or to have a
password that is easy to crack because you do not want to write it 
down.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date:    Wed, 20 Jun 1990 10:19:42  +0200
From: "UFOBI2::RMEYER"  <U0018@dgogwdg5.bitnet>
To: security@pyrite.rutgers.edu

I know some people, who change their password like:
blahmmyy
blah = 4 character unique password
mm   = month
yy   = year

( or blmmyyyy, yymmblah, ........)

I think it's better, if they changed the password sometimes to
a "really new" password. Password lifetime must be long. A user
should have a chance to use an old password again, if she/he thinks
that it is not known to other people.

If the expiring period is short an you cannot use the same password
again, people will write their password on a piece of paper....
This is the real problem.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date:  Thu, 21 Jun 90 13:05 EDT
From: Kilgallen@dockmaster.ncsc.mil
To: hobbit@pyrite.rutgers.edu

Well I am not in an environment which requires dealing with academic freedom,
but it would seem simply a matter of offering the alternative of signing a
form in which they agree to financial liability to any damage to the computer
system (including time and effort to repair) due to break-ins over their
account.

By the way DEC says they have fixed this problem (with a password history
file consulted by the Set Password command) in VMS V5.4.  For those who
use Unix, presumably the answer is to write your own modifications to Unix
following that model.

As a security practice, I would say you should *never* tolerate people
changing their password back to the same thing.  If you think keeping a
password for a long period of time is permissible, then change your
permissible password lifetime parameter.  To set a short lifetime and
then permit people getting around it (look for two successive password
changes in the pre-V5.4 VMS audit alarms), just sends the message that
system administrators are not serious about the rules they lay down.
It is better to change the rules.

Larry Kilgallen

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Sun, 1 Jul 90 21:17:44 EST
From: Don Irmiger <don@delta.com>
To: SECURITY@ohstvma.ircc.ohio-state.edu

> I have heard the argument made that forcing frequent password changes is
> counterproductive

I agree with the counterproductive argument.  I'm running a Unix box which
allows the user to reset their own passwords.  If I were more sensitive, this
would be restricted to system administrator use.  I've used two methods of
password generation:
	1) alternating series of consonants and vowels.  This produces only
	   marginally pronouncable passwords, but served its purposes.  Most
	   users made written copies which is frowned upon as a whole.
	2) an english word of 3-4 characters in length, a digit(0-9), and
	   another English word of 4-3 characters in length.  My Unix box
	   only allows 8 character max passwords and this satifies it.  I
	   choose the words randomly the the set of 3-4 character words in
	   my spelling checker dictionaly (/usr/dict/words).  I wrote a
	   program that generated about 200 of them (40 users on my box)
	   and I pick the topmost from the list, assign it and delete the
	   line from the file (highly restricted access to the file, BTW).

   Particularly with naive users, you have to *stress* that these passwords
are priviledged bits of information as they should not be distributed or
shared in any way.  I can't hold them responsible for security flaws if they
don't know the rules...

--
Donald K. Irmiger III                                 UUCP: uunet!delta.com!don
Data Systems Coordinator                          Internet: don@delta.com
Michiana Rehabilitation Institute's Data Systems Center \ Altos 2086/Xenix 3.4b

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Tue, 3 Jul 90 22:08:48 EDT
From: retants@rodan.acs.syr.edu

Just to pass along my experience with the password generators, we had
a lot of people writing things down.  the ones that didn't would spend 
literally hours flipping through the password generator until it came
up with something vaguely english (example being SUNNDUG...not a real
world, but something easy to remember).  THis was a waste of time in
general, but which is worse...writing down passwords or spending an 
hour finding one that can be remembered.

one suggestion made was that each time a person changed thier password,
they were given a randomized number for the space they had to put a
numeral into.  example: place a number as the 6 character of a password.
then the person could make up a password, and the system would check
to make sure that 1) there was a number in the 6th position, and 2) it
was not the same number as the position number.  Passwords would look
like DOGHO1USE which is easy to remember as a word that you add your
number to, and a bit harder to break.

any comments on that one?

      Becki Tants    RETANTS@SUNRISE.BITNET RETANTS@RODAN.ACS.SYR.EDU   

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Mon, 23 Jul 90 22:58:00 EST
From: zik@bruce.cs.monash.oz.au (Michael Saleeba)
To: misc-security@munnari.oz.au

On the subject of passord checking, I am doing a project on password
security for my honours comp. sci. unit "Security in Computing". I'd
be grateful if anyone with password guessing or checking programs
would sendfile them to me or direct me to the appropriate archives.
Also, I'd welcome any general comments that people have on password
security and its flaws.
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 23:40:06 GMT
From:      security-request@PYRITE.RUTGERS.EDU (*Hobbit*)
To:        misc.security
Subject:   Leftover msgs about password expiration

[Crunched into a "digest" to save a little network bandwidth.  _H*]

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: 19 Jun 90 11:49:49 GMT
>From: Doug Gwyn <gwyn@smoke.brl.mil>
To: misc-security@rutgers.edu

The solution is so obvious that I wonder that you don't see it --
Stop gratuitously requiring people to change their passwords.
If the password is not thought to have been compromised, there
is more reason to continue using it than to change it.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: 19 Jun 90 20:08:41 GMT
>From: levine@csd4.csd.uwm.edu (Leonard P Levine)
To: misc-security@uunet.uu.net

I carefully examied the material on making Unix more secure (Improving the 
security of your Unix System by David Curry, SRI International) in hopes 
of finding just why changing the password makes a system secure.  Curry's 
well thought out work has many good suggestions but he says about changing
passwords only the following: (page 7)

"Finally it is important to establish a policy that users must change 
their passwords from time to time, say twice a year."

He gives no reason for such a need, although all of the other problems 
he discusses are couched in terms of speed of cracking and methods of
penetration.

He (correctly) points out that users should never write down their 
passwords, should not use easy to guess words, and the like, but somehow 
feels that a user who has a good password, who never allows him/herself 
to be observed logging in, who sees no history of problems, should 
nevertheless change the password fairly often.

Why twice a year?  Why not twice a day?  I think it would be better
to have a good password that you do not have to write down because 
you know it (from long and careful use) than to have a password 
that you write down because you easily forget it, or to have a
password that is easy to crack because you do not want to write it 
down.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date:    Wed, 20 Jun 1990 10:19:42  +0200
>From: "UFOBI2::RMEYER"  <U0018@dgogwdg5.bitnet>
To: security@pyrite.rutgers.edu

I know some people, who change their password like:
blahmmyy
blah = 4 character unique password
mm   = month
yy   = year

( or blmmyyyy, yymmblah, ........)

I think it's better, if they changed the password sometimes to
a "really new" password. Password lifetime must be long. A user
should have a chance to use an old password again, if she/he thinks
that it is not known to other people.

If the expiring period is short an you cannot use the same password
again, people will write their password on a piece of paper....
This is the real problem.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date:  Thu, 21 Jun 90 13:05 EDT
>From: Kilgallen@dockmaster.ncsc.mil
To: hobbit@pyrite.rutgers.edu

Well I am not in an environment which requires dealing with academic freedom,
but it would seem simply a matter of offering the alternative of signing a
form in which they agree to financial liability to any damage to the computer
system (including time and effort to repair) due to break-ins over their
account.

By the way DEC says they have fixed this problem (with a password history
file consulted by the Set Password command) in VMS V5.4.  For those who
use Unix, presumably the answer is to write your own modifications to Unix
following that model.

As a security practice, I would say you should *never* tolerate people
changing their password back to the same thing.  If you think keeping a
password for a long period of time is permissible, then change your
permissible password lifetime parameter.  To set a short lifetime and
then permit people getting around it (look for two successive password
changes in the pre-V5.4 VMS audit alarms), just sends the message that
system administrators are not serious about the rules they lay down.
It is better to change the rules.

Larry Kilgallen

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Sun, 1 Jul 90 21:17:44 EST
>From: Don Irmiger <don@delta.com>
To: SECURITY@ohstvma.ircc.ohio-state.edu

> I have heard the argument made that forcing frequent password changes is
> counterproductive

I agree with the counterproductive argument.  I'm running a Unix box which
allows the user to reset their own passwords.  If I were more sensitive, this
would be restricted to system administrator use.  I've used two methods of
password generation:
	1) alternating series of consonants and vowels.  This produces only
	   marginally pronouncable passwords, but served its purposes.  Most
	   users made written copies which is frowned upon as a whole.
	2) an english word of 3-4 characters in length, a digit(0-9), and
	   another English word of 4-3 characters in length.  My Unix box
	   only allows 8 character max passwords and this satifies it.  I
	   choose the words randomly the the set of 3-4 character words in
	   my spelling checker dictionaly (/usr/dict/words).  I wrote a
	   program that generated about 200 of them (40 users on my box)
	   and I pick the topmost from the list, assign it and delete the
	   line from the file (highly restricted access to the file, BTW).

   Particularly with naive users, you have to *stress* that these passwords
are priviledged bits of information as they should not be distributed or
shared in any way.  I can't hold them responsible for security flaws if they
don't know the rules...

--
Donald K. Irmiger III                                 UUCP: uunet!delta.com!don
Data Systems Coordinator                          Internet: don@delta.com
Michiana Rehabilitation Institute's Data Systems Center \ Altos 2086/Xenix 3.4b

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Tue, 3 Jul 90 22:08:48 EDT
>From: retants@rodan.acs.syr.edu

Just to pass along my experience with the password generators, we had
a lot of people writing things down.  the ones that didn't would spend 
literally hours flipping through the password generator until it came
up with something vaguely english (example being SUNNDUG...not a real
world, but something easy to remember).  THis was a waste of time in
general, but which is worse...writing down passwords or spending an 
hour finding one that can be remembered.

one suggestion made was that each time a person changed thier password,
they were given a randomized number for the space they had to put a
numeral into.  example: place a number as the 6 character of a password.
then the person could make up a password, and the system would check
to make sure that 1) there was a number in the 6th position, and 2) it
was not the same number as the position number.  Passwords would look
like DOGHO1USE which is easy to remember as a word that you add your
number to, and a bit harder to break.

any comments on that one?

      Becki Tants    RETANTS@SUNRISE.BITNET RETANTS@RODAN.ACS.SYR.EDU   

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Mon, 23 Jul 90 22:58:00 EST
>From: zik@bruce.cs.monash.oz.au (Michael Saleeba)
To: misc-security@munnari.oz.au

On the subject of passord checking, I am doing a project on password
security for my honours comp. sci. unit "Security in Computing". I'd
be grateful if anyone with password guessing or checking programs
would sendfile them to me or direct me to the appropriate archives.
Also, I'd welcome any general comments that people have on password
security and its flaws.

END OF DOCUMENT