[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_crypt design changes

On Sat, Apr 19, 1997 at 07:15:36PM -0500, Adam Slattery wrote:
> > See above. I think NSS stinks and needs to be replaced with something
> > more generic. I don't think PAM, as it is, is the right place to worry
> > about "retrieving/storing password hashes".
> Well honestly I don't see any better place right now.  Glibc would be the
> place, but like I mentioned in my last message, changes come slowly. This is
> probably good because stability is very important.  Pam is so flexible that
> I believe it is the right place to do it (for now, at least).

PAM modules can certainly take care of updating authentication tokens --
no changes are needed here, but PAM isn't a "store/retrieve" interface.

> > And by the way, I don't think it's worth worrying much about crypt
> > password hashes. There are better password validation (initial
> > authentication) technologies, such as SRP, Kerberos, PKI, etc...
> > And guess what: Kerberos is the way of the future at this point -- all
> > the major OS vendors are gravitating to it. Makes password hashing look
> > like child's play.
> 5-10 years in the future that may be the case.  As above, I think pam is

Kerberos is here today. Now. Most Windows shops most certainly will be
using it within a year, if they aren't now. And MS is not the only
vendor to embrace Kerberos, just the one best positioned to make it

> flexible enough that these technologies will fit in well with it.  With this
> said, I'm looking more towards using the modular recovery/setting of
> password hashes (my original idea) with pam_crypt being a standalone module
> to support legacy (current :) authentication methods, and I want let it
> stabalize to the point where people would rather use it than pam_unix and
> friends for flexability as well as stability.  This way there would be one
> unified and flexible method for "legacy" authentication.  I don't want to
> force pam_crypt on people unless it is really good.  I don't care if anybody
> wants it or not, people want windows.  And yes, password hashing is child's
> play:).

Again, I don't think a new PAM module is needed. Just an API that
modules can use to do crypt() without hardcoding knowledge of specific
crypt() types and with configurable run-time modularity with respect to
crypt() implementations.

> > Why can't you write a generic, modular crypt() API and let others
> > migrate to it as they wish?
> I'm sticking with pam_crypt. I probably sound stubborn but I feel the
> concept has a lot of potential to be really useful.  I think I will make a
> generic library without the pam functions that can be linked to by non-pam
> applications.


> - Adam Slattery



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []