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: Richard Wackerbarth (rkwdataplex.net)
Date: Mon Feb 07 2000 - 11:03:42 CST


On Mon, 07 Feb 2000, Robert Watson wrote:
> 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.

OK. Then what we need is the ability for the user to SUGGEST the scheme and
site policy to accept/reject/modify the request.

> > 2) The scheme should be controlled by login class

> > 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
Good Point. We can still do that in the wrapper.

echo ${secret} | encode-${scheme}-secret | set-passwd

> 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.

I would hope that CHANGING passwords is sufficiently infrequent that an extra
exec is not a killer.

I worry with the "library" approach is that it is not very extensible. I
presume that we could use an interface library to switch to actual scheme
implementation libraries and, within the interface library, weak symbols to stub
off the missing methodologies.

However, how do we add a new type of password without recompiling?

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