OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: [MORE] Passwords database
From: Robert Watson (robertcyrus.watson.org)
Date: Mon Feb 07 2000 - 10:40:41 CST

On Mon, 7 Feb 2000, Richard Wackerbarth wrote:

> > and also, an /etc/passwd.conf that specified policy on available and
> > permissible algorithms to use in /etc/master.passwd.
>
> > No patches available, but it might look like this:
> >
> > algorithms_enabled=DES MD5 SHA1 OBFUSCATE
> > algorithm_user_permit=current DES MD5
>
> 1) I see no reason why the USER should know/care/control what the password
> scheme is on a particular machine.

For these base types, yes, but for types such as "rsa public key" or "skey
data" they may need or want to be aware. By default, they wouldn't need
to deal with it as passwd would select the required, and if no required is
set, then just use the current if it was permittable. Otherwise, fall
back on an algorithm_default entry.

> 2) The scheme should be controlled by login class
>
> I wouuld suggest that we KISS this one.
> Use a "core" command to actually set passwords as:
>
> set-passwd [ -u <user> ] <encoded_passwd>
> eg: set-passwd "$1$AbcT4wof$ze2FtHcb6aR5GEf3CgaB9/"
>
> but don't allow the user to access that command. Instead, wrap it
> in a shell which actually does the logic of selecting and encoding
> based on the user class and current password type and the site policy.

Hmm. If this is a going to be a UNIX command with restricted permissions,
you'll want to provide the password entry via stdin, not the command line,
as command lines are viewable by all users, by default. :-) A lot of
utilities foolishly allow secrets to be provided either as comand line
parameters, or environment variables. This should *not* be done, for the
obvious reason (ps). Indirection via a secret file is fine, as is stdin
or the like.

I'd be more tempted to provide a support library than a shell/command, as
you can imagine other code wanting access to this kind of functionality --
user managers, etc, and for the purposes of auditing and verification,
avoiding spurious execs/etc in a privileged environment is a good idea.
You could imagine an encode_secret() call that accepted a policy
reference, an old secret entry from spwd.db, and a new secret to encode,
along with user selection criteria. The encode_secret would either return
the new encoded form, or an error indicating an invalid encoding
mechanism, weak secret, whatever.

I'm not sure how this fits into the PAM scheme of things, btw.

  Robert N M Watson

robertfledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message