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

Re: pam_crypt design changes



> IMHO, PAM is good, but didn't go far enough. A new API is needed that
> unifies the functionality of PAM, NSS, and things like GSS and SASL.
>
> But this is academic. Noone will undertake such an API at this point.

Neither will I :)

>
> > > In short:
> > >  - provide a modular crypt() API
> >
> > Basically done.  Just needs some slight changes regardless of what I
decide
> > to do.
>
> Can you describe the API?

erm. It's in the API file in pam_crypt-0.0.x.tar.gz
I'm going to change a few things. I don't like having the modules call
the function to update the password file, for example.  Having a function
to get random data is pretty stupid too.  Also, there isn't any real reason
to have the algorithm name in the symbol in the shared object file.

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

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

> I think that PAM is best left as is.
ok:).

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

> If it's really so useful then it'll happen.
It only appears useful if there is something in existance to use it with.


> > - Adam Slattery
> > http://www.sunriselinux.com/pam_crypt/
>
> Nico

- Adam Slattery





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