new password idea

[Martin Weitzel]

In article <1991Apr24.004539.3881 at mp.cs.niu.edu> bennett at mp.cs.niu.edu (Scott Bennett) writes:
>In article <1991Apr23.182654.22452 at odin.corp.sgi.com> jeffs at soul.esd.sgi.com (Jeff Smith) writes:

>     On some of our non-UNIX systems we use a security package that has
>another useful feature:  after a certain number of bad passwords are
>given consecutively for a logonid, the logonid is suspended.

Looks nice on first glance but needs refinements. Note that someone
can deliberately lock out someone else from the system! Given some bad
guy found by chance the password of someone else. What would you the bad
guy do if he wants to be sure that this other person will not disturb him?
Assume Joe Hacker has just exploitet some security hole in the system
and now wants to be undisturbed from the administrator for some time?

A better way to go is to establish a period of waiting between consecutive
bad logins, that doubles with every attempt. (After the first bad atempt
you have to wait 1 second, after the second bad attempt 2 seconds, etc.
This not only amounts to about 20 minutes after ten bad attempts, it also
means that you need this long for 10 consecutive (bad) attempts.

>Most users are further required to change their passwords
>at least once every {insert desired time period}.

Who will more likely pick a "good" (ie. hard to guess) password? The
user who can think a little about it or the user who is forced at login
time to select a new password because the old one just expired. Consider
that said user may be in a hurry this particular day ...

>Users can set up or
>modify any access rules regarding their own files.  If no explicit rule
>is currently defined when the system checks for one, the default is that
>the user has full access (i.e. read, write, allocate, execute) and
>nobody else gets anything.

Can you edit your .profile to contain a line: `umask 077' ?

>The entire data base used by the security
>system is accessible, but only by the systems programmers (i.e. us:-)
>or, conceivably, the computer operators with great bother, and the
>passwords are all encrypted anyway.

Yeah, yeah we heard all this allready: Know that everybody who has the
ability to install system programs can break any security barrier.
BTW: Did you know that even `crypt(3)'ed files are not 100% protected
from beeing read by the superuser (clear-text, I imply here)?
Maybe the superuser changed the installed crypt-command a little so that it
mails the clear-text of anything that is run through crypt to him or her!

Many systems simlply `appear' to be secure because people do not have
enough phantasy! Have I told you about that little board, maybe 2 by 2
inches sized and with a little electronic circuitry on it? That board
finds easily some space in nearly any terminal and it takes not more
than a few minutes to install it there and tap pins 2 and 3 of the famous
RS 232 connector. Whenever it watches the strings "login:" and "password:"
flow in, it stores the next few characters that flow out in some non-
volatile memory. To remove this board from the terminal some weeks
later also takes only a few minutes ... (and if you have a sufficiently
intelligent terminal with it's own builtin microprocessor and little
more NV-RAM than needed to keep the terminal's setup: Simply plant some
new firmware into it, walk over there in the evening and, after entering you
own special key combination, the terminal will nicely display all the
passwords of the dayly users.

To put it in other words: I know that many companies feel uncomfortable
if there is not a number nifty-super-security-features built into their
software. But do the same companies care to watch those people who
clean their office in the evening? ("Why care - of course our computer is
shut down during this hours and of course the room were the CPU is located
is locked and not entered by the cleaning people ...")
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83