login security package
Bud Hovell
bbh at whizz.uucp
Thu Dec 1 05:42:25 AEST 1988
In article <10062 at watdragon.waterloo.edu>, hjespersen at trillium.waterloo.edu (Hans Jespersen) writes:
> In article <185 at loci.UUCP> clb at loci.UUCP (Charles Brunow) writes:
> > I know this guy and his software and I wouldn't touch it with
> > a stick. This stuff is developed (loosely interpreted) on a
> > xenix box and I recommend that you go through it very carefully
> > before you put on real Unix.
>
> I would hope that most people would go through code they pull off the net
> regardless of who wrote it. The easiest way to spread a worm/virus is
> by having others carry it for you. I would insist on source code and
> go through it carefully. I don't think this is paranoid, in fact, one
> can learn alot from looking at the junk that other people write ;-).
Understood. Acknowledged. Confirmed.
I may be entirely wrong here, but it seems to me that there are a couple of
problems with the current spin of these responses to the original posting.
First, let me make it clear that I am no unix guru. (If there is any doubt
on this point, a significant number of qualified people would eagerly
certify that it is so :-)
However...
While the recent unpleasantries have generated much heat (and a modicum of
light) regarding the dangers of worms, viruses, and Trojan horses, it seems
to me that we should not overlook Pogo's rightly famous words:
"We have met the enemy, and he is US!".
Quite.
The primary threat to security is simple ignorance or indifference. Period.
Most security breaches (physical or electronic) are successful because of
the many opportunities generated consequent to these human frailties.
This primary threat (unlike RTM, et al) can be addressed in one of three ways:
1. Ignore it (join forces with the cause of the threat).
2. Bitch alot about how stupid and ignorant people really are. (This
one has enjoyed great recent popularity on the net, though it is
hardly news to any but the newborn).
3. Do something to alter the mechanics of the process so that
ignorant or indifferent people must at least exercise some moderate
level of creativity in order to bungle minimum security.
For the most part, many systems have been strategically conceived and
created by people who are fond of choice two...
And are often administered by people who rely on choice one. This is often
driven by their realization that they don't have access to choice three,
since the owner of the code is exercising choice one, and recommending that
the administrator exercise choice two. Which is tiresome after awhile, so
the long-term default is (there you are) choice one. The continuing crisis.
The 'login' package includes /etc/shadow concealment of the encrypted
passwords, denial of "obvious" passwords (or passwords that are too similar
to their predecessors), and forcing of periodic change of passwords.
It is intended to better provide the option to enjoy choice three, above
cited. It will not be recognized as potentially valuable to any who are stuck
on one or two.
First, I have in no way attempted to certify the work of John Haugh, nor to
condemn it. If I *were* a wizard with the knowledge to carry forward with
review/correction/conversion of this code for use on the UNIXPC, then there
would have been little reason for making the original posting seeking same.
I simply report the fact that he (and others) are producing such a package.
I learn more recently that it is completed and will be sent to Rich $alz for
posting to the archives. If this is a fact, as I believe it to be, it may be
of more than academic interest whether it is or is not a *good* package.
Why? Well, to begin with, no one else has stepped forward to do this PD job,
so far as I know. I also do not know that it is, in this particular instance,
a lousy job on the part of its creators. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
If it is, then it can be dismissed and advertised as such on the net.
If it has only those flaws which can be expected in any first-cut programming
effort - and quickly identified and corrected by others - then that's a step
forward, I would think, toward some meaningful choices that are not vendor-
dependent. Which is different than the present case for the vast majority of
us.
Either way, it seems to me that the community at large will have been well
served.
And, after some personal experience with the stuff that has been written by
aces at ATT, I must offer the observation that even skilled programmers have
been known to produce code with the occasional bug or faulty concept. Some-
times more often than occasionally! :-) And with no malicious intent. Human
frailty, unfortunately, exists in moderate degree even amongst programmers.
While one should not confuse expenditure of energy with the obtaining of good
results, it is also important to continue to encourage those who are willing
to make these efforts - even if they are imperfect people who did not emerge
from the womb fully gifted with the all the knowledge and experience possessed
by others after a lifetime of experience.
And without willing creators, how could critics perform their equally-valuable
function of bringing us all to a final state of perfection?
OVERTURE SYSTEMS CORP.
Bud Hovell Operations Specialists
Lake Oswego, Oregon
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: USENET: {attmail! | tektronix!tessi!bucket! | pacbell!safari!} whizz!bbh :
: TELEX: 152258436 (Whizz/Bud Hovell) VOICE: 503-636-3000 :
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
"Follow your bliss" - Joseph Campbell
More information about the Unix-pc.general
mailing list