Subject: Alternate password file?

From: [email-masked] (John G. Thompson)
Date: Tue, 17 Oct 1995 12:59:52 -0700 (PDT)

Has anyone considered implementing an alternate or secondary
password strategy?

This is a strategy whereby there are two (or more) password and 
shadows files.  The idea being that if a user isn't found in the
primay password set, look for that id in the secondary.

Why?  To reduce the number of general user accounts on the system.
If I have only those userids in the standard password file set that
can actually login via telnet, getty or rlogin and the secondary 
contains the wu-ftpd only userids, then I reduce the number of 
accounts that can be hammered from 'not nice' people. :)

Yes, this does add some more administrative tasks, like adding users
to the secondary password set, sync'ing the two sets regard uids and 
gids, and managing passwords in the secondary set (hmm, look like
SITE UPASS <password>).

Comments? Interest?

JGT
firewall system and security admin @amdahl.com
-- 
John G. Thompson    [email-masked]      1-408-992-2088
Amdahl Corporation, P.O. Box 3470 MS 383, Sunnyvale, CA 94088-3470

[The opinions expressed are MINE. They do not necessarily reflect the 
policies, procedures, press releases or opionions of the Amdahl Corporation.]

---

From: Michael Brennen <[email-masked]>
Date: Tue, 17 Oct 1995 17:06:35 -0500 (CDT)

> gids, and managing passwords in the secondary set (hmm, look like

Well, I have considered this exact function but for a different purpose. 
I am considering an application for this in a password protected Web
directory that is also set up for guest ftp.  Certainly it would be
possible just to feed the Web browser the URL of the file and let it
download the file, but there may be people that need to come in via FTP
to get files also.  For this application I would want ftpd to do its 
*primary* authentication on the same password file that the Web server 
would use for authentication.  This would allow a user to come in either 
was as it would be most convenient.

This should be fairly easy to do, but I just have not been forced by need 
to sit down and do it yet.  Do you see an overlap in these two functions 
such that one implementation would do it?  I think I do, but the reversal 
of primary and secondary password file checking may throw off what you 
have in mind.

Michael Brennen

---

From: Mitch Wright <[email-masked]>
Date: Wed, 18 Oct 1995 02:00:36 -0700

/* John G. Thompson [[email-masked]] writes: */

>Has anyone considered implementing an alternate or secondary
I still think a better strategy is to incorporate something like
the TIS authserv, RADIUS, or TACACS+ to do this.  If you were
using something like latter two, you could even limit the
commands based on user by setting up appropriate AV-pairs.

I will be building in the TIS support shortly (this weekend) which
will not only give me the SKEY stuff that is there, but crypto
calculator support as well.  As I did for /bin/login, the fallback
will be the system password file.  I may go ahead and even make
the authserv code only kick in for certain "groups" defined in
the ftpaccess file as well.  This way an internal connection could
be straight user/password, while coming in via the "net" might
require SKey, SNK, whatever...

>can actually login via telnet, getty or rlogin and the secondary 
Just change their shells.  I typically have a small script called
/FTPonly which basically tells the user that the account is for
FTP use only and exits.

-- 
do svidaniya,

  ~mitch

---

From: [email-masked] (John G. Thompson)
Date: Wed, 18 Oct 1995 09:10:33 -0700 (PDT)

> commands based on user by setting up appropriate AV-pairs.

I do too, however, I have neither the expertise, nor the resources
to put any of the above in place.  It would be wonderful, and something we 
do want to do in the future, to serve the ids and acl list off an auth
server behind the firewall.

> /FTPonly which basically tells the user that the account is for

I understand the idea of a stub shell.  If the userid isn't needed
for direct login, it just doesn't belong in the file.

--
To Michael Brennen and his idea for using the secondary for password
secured web directories.  I see no conflict at all.  If anything it
points out to me a need to generalize this idea.

Allow for the specification of password sets and their order of 
use.  Maybe using the <class> concept or definition.

i.e.:

class local real,guest,anonymous *.inside.com
class remote real,guest,anonymous !*.inside.com !nameserved

password local /etc/password:/shadow ~ftp/etc/passwd:shadow \
/usr/local/etc/www/passwd:shadow

password remote /usr/local/etc/www/passwd:shadow /etc/password:/shadow \
~ftp/etc/passwd:shadow

---

From: Mitch Wright <[email-masked]>
Date: Wed, 18 Oct 1995 10:12:00 -0700

>to put any of the above in place.  It would be wonderful, and something
>
I will be doing the TIS stuff shortly.  This is an interim solution
until I can fully understand both RADIUS and TACACS+ to decide which
one I will do.

>for direct login, it just doesn't belong in the file.
In which file?  passwd?  The password file is simply that... a password
file which stores some information about the user.  Don't think of it
as a place which lists only direct login accounts.  You already have a
bunch in there that aren't (daemon, bin, sys, ...) and star'ing them
out is roughly equivalent to changing their shell to something useless
except you can enable/disable other functionality as you want.  Two
services come to mind ... FTP and POP.

Now my blabbering above is somewhat hypocritical since I sort of hacked
wu-ftpd-2.3 to use the ftpgroup mechanism as a pseudo second password
file, but our requirements were considerably different.  Mine couldn't
be met by using a simple second password file.

A simple illustration... you have a user that needs FTP access only.
He needs access to files owned by group "alpha" and "beta".  Using
a second password file you can only pick one.  If you add additional
groups to /etc/group you will now have entries which do not match up
with the "real" password file.  If you synchronize, why bother having
the second?  Just a thought.

I've been munging my ftpgroups file into web password files via a
cron job.

Anyway... my feeling, for what it's worth, is that if any significant
effort is going to go into adding more sophisticated authentication
to this we should go with a more general mechanism like the IETF's
RADIUS or Cisco's TACACS+.  I understand the expertise and time
issues quite well.  I've been planning on doing this for quite some
time too -- Now I just have someone that is paying me to add TIS support
to it!

-- 
do svidaniya,

  ~mitch