new password idea

[Gordon Burditt]

>If you're really worried about kids getting into your account (an adult who
>tries to pick people's passwords is considered a child in my book), then
>write a password program for yourself and run it from .cshrc (or
>whatever).  That way, even if someone breaks into your account, they

This won't work.  All the popular shells (csh, sh, ksh, tcsh) will *QUIT
PROCESSING THE FILE* (whatever it's named:  .cshrc, .login, .profile, etc.)
and *GO INTO INTERACTIVE MODE* if they receive an interrupt character while
they are processing the file.  This weakness was also present in the
old v7 restricted shell ("rsh", unrelated to the BSD remote-execution
shell).  This means that by pounding on the interrupt key, I can (eventually, 
it may not work every time) get a shell prompt without any of the file
having been executed.  It doesn't matter how many "trap" statements,
invocations of "stty", or other such things there are in the file.
The next thing the cracker probably does is delete the file.  While there
are ways of preventing a user from deleting files in his home directory,
this will only annoy someone who has already successfully broken in.

If you want to have secondary security, have the security program named
in the shell field of the password file.  The security program can demand
all the passwords it wants, do challenge-response, try to time your keystrokes,
etc.  (Obviously this program needs its own database of users, passwords,
encryption keys, preferred shell, etc., and this database probably should be 
both encrypted and kept secret.  It also needs some commands to manipulate
the database.)  If you overwhelm it with interrupt characters and it hasn't 
ignored them, *YOU GET LOGGED OUT*.  Most other things you can do:  send 
a variety of signals, BREAK sequences, rapid fluctuations of carrier, 
cause the program to dump core with funny input, etc. will log you out.
If you satisfy the program that you're the real user, the program sets up 
various environment variables suitably (if $SHELL is defined, it shouldn't 
point at /etc/challenge-response, but at /bin/csh, /bin/ksh, or whatever).

It's even OK if a non-admin user wants to own and maintain his own security
shell.  The admin may have to bail out the user if the security shell
ever gets deleted, corrupted, or a new version has bugs in it.  If a 
cracker gets in, he can take over the account (of course, with or without a
security shell, the cracker could just change the primary password).

For both the useless "security-in-startup-file" scheme and the "security
shell" scheme, you have to prevent the users from changing their shell.
Disable 'chsh' or remove it.  In the "security shell" approach, a
command similar to chsh (and set-uid root:  with all the requirements for
care in coding that that implies) could let a user select which interactive 
shell they wanted, assuming they are authorized for an interactive shell
(and not something limited like a menu system or uucico) at all.

Access to the account by means other than through the specified login
shell bypasses the secondary security.  Worry about the 'su' command and
remote access over a network.

					Gordon L. Burditt
					sneaky.lonestar.org!gordon