Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!cit-vax!usc-oberon!sdcrdcf!otto!jimi!asci!brian
From: brian@asci.UUCP (brian)
Newsgroups: comp.unix.wizards
Subject: Re: Unix userid conventions
Message-ID: <124@asci.UUCP>
Date: Tue, 10-Mar-87 18:32:41 EST
Article-I.D.: asci.124
Posted: Tue Mar 10 18:32:41 1987
Date-Received: Sat, 14-Mar-87 05:59:50 EST
References: <4788@brl-adm.ARPA>
Reply-To: brian@asci.UUCP (BRIAN DOUGLASS)
Organization: Applied Systems Consultants, Inc.  Las Vegas
Lines: 60
Summary: There is a time and place for cryptic userids

Expires:

Sender:

Followup-To:

Distribution:

Keywords:


Our company does a large amount of consulting & programming on systems from
PC's to IBM main frames, with 90% of the work under Unix, which is divided
up about 70-30 between DoD and Private enterprises.  Every system can be
considered to contain sensitive information to somebody somewhere, whether it
be government or private.  Generally speaking, under Unix using the user's
name is the only good method for userids for the many reasons already
mentioned (i.e.  e-mail), and most large systems do generate their own account
names for their own convenience. However, there are times and systems when a
cryptic password, and/or userid is necessary.

When a name is used for the userid, and the user is allowed to assign their
own password, 90% of the time they will use passwords of some familiarity,
their child's name (alla Wargames), religious affiliation, names of great
ships.  For a great many systems this is no problem.  But in large corporate
structures, the most pervasive security issue facing Administrators today
arises using such a passwording and userid scheme.  This is the Internal
Infiltrator (I.I.).

These security violator, under Unix particularly, usually have no interest
getting to the master account (root).  Rather, the I.I.  is usually interested
in viewing data he has no business looking at.  For example, a manager writes
a confidential memo to another manager that a recently transfered employee was
suspected of using cocaine on the job, and for the new manager to keep an eye
on him.  Later the employee is fired for whatever reason, only to produce a
copy of the memo.  Legally explosive.  Other examples include viewing a
competitor's accounting files.  An unscrupulous colleague damaging your work
for his own gain in the work place.  These have and continue to happen in the
corporate world, and if an I.I.  knows something about you, and your method
for passwording, he's already cut down the number of password bangs from
hundreds of thousands to tens, or maybe even a few thousand.  He probably
doesn't even care about root's password.  The I.I.  is the #1 threat to
security in the corporate Unix world.

For those situations our method of generating a password is to open a
dictionary, point to a word, and take the first letter.  Then close the
dictionary, open again, p-t-a-w, and take the second letter, etc., etc.,
through the maximum allowable characters.  From, there, it is absolutely
forbidden to write down the password, instead a mnemonic is developed (i.e.
qazxsw is quite all zebras x-ray session writing).  This is drilled into the
user.  We now are back to hundreds of thousands of possibilities.

Under Unix, it makes no sense to be cryptic for the userids, for all the I.I.
would have to do is print the passwd file, and then bang on the password to
get in under the account desired.  Using mnemonic userids is the only viable
method to assign these.  However, on non-Unix machines, without these types of
security deficiencies, cryptic userids do become a powerful tool for internal
security.

Lastly, the best security method of all is put the system in a TEMPEST
approved vault, with all the terminals in the vault, and make everybody sign
in and out.  But then again, anybody that really wants in can always pull out
the most trusted tool of any system penetrator.  The time honored practice of
bribery.  A very hard method to defend against.


Brian Douglass
Applied Systems Consultants, Inc. (ASCI)
P.O. Box 13301
Las Vegas NV  89112
(702) 733-6761