Path: utzoo!mnetor!uunet!nbires!hao!husc6!bu-cs!madd
From: madd@bu-cs.BU.EDU (Jim Frost)
Newsgroups: sci.crypt
Subject: Re: Unix Password Hacker (insecurities in security)
Message-ID: <20250@bu-cs.BU.EDU>
Date: 28 Feb 88 21:12:57 GMT
References: <731@ddsw1.UUCP> <657@morningdew.BBN.COM> <1368@homxc.UUCP> <739@ddsw1.UUCP> <1118@uop.edu> <2584@crash.cts.com> <5877@netsys.UUCP>
Reply-To: madd@bu-it.bu.edu (Jim Frost)
Followup-To: sci.crypt
Distribution: na
Organization: Boston University Distributed Systems Group
Lines: 60

In article <5877@netsys.UUCP> tsl@netsys.UUCP (Tom Livingston) writes:
>In article <2584@crash.cts.com> jkimble@crash.CTS.COM (Jim Kimble) writes:
>>The first time the owners of the accounts
>>try to login and find they can't, they're going to make a phone call to the
>>data processing people who will just assign a new password right there over
>>the phone.
>
>They would assign a new password over the phone?  I doubt this,
>as 'anyone' could just call up, claiming to be someone else, and have their
>password changed.  Bingo, they have the account.

This is quite a security hole in a *lot* of so-called "secure"
systems.  During the time I worked for the Admissions department for
Boston University, they installed a "more secure" system on top of the
old.  The new system required the changing of passwords every 30 days
and wouldn't let you use the same one again for 2 changings.  After 3
failed password attempts, the account was disabled.  To management,
this must have seemed dramatically more secure.

What did this accomplish?  It made account disablings VERY
commonplace.  In order to make the system workable (so that employees
wouldn't have to spend large amounts of time running all over the
place each time their account was disabled), a phone number was
set up which you could call to get your account reset to a predefined
password, which you could get from your supervisor.  The predefined
password is of course public knowledge the moment one employee goofs
his/her login, and indeed immediately since we needed to know it for
the initial login.  What their more secure system did was create a
security hole so large as to make cracking the system not only easier,
but simple and commonplace.  When I needed access to an account, I'd
screw up the password, call the (well publicized and often used)
number, identify myself as the user who's account I needed, and log in
with the default password.  Cracking the security took less than a
minute, and usually went undetected since the user who's account you
used would goof the password three times, get it reset, and just
assume they'd mistyped it or forgotten that they'd changed it.

There are inherent insecurities in any kind of password changing
that does not require absolute identification of the user.  This is
obvious to begin with, but often overlooked.  Additionally, any kind
of security system that disables an account after n accesses (where n
is a small number) leads to security holes, since after a few hundred
disables in a short amount of time, the staff is going to start to
take shortcuts with procedure (if indeed the procedure was secure to
begin with).  Additionally, password schemes that require "odd"
passwords (requiring a digit, for example) combined with account
disabling are REALLY insecure, since the oddity makes it probable that
users will goof it more often than otherwise, and increase the number
of incorrect disablings.

A note to the interested:  the security system used on Boston
University's University Information System (UIS) is called Top Secret
and is supposedly "state of the art".  I would not recommend using
this system at all, or if you do use it, tweak the number of invalid
passwords needed to disable the account to something like 20 or 30.
This will kill brute force approaches without making disables
commonplace.

jim frost
madd@bu-it.bu.edu