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 happen. > 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. Ok. > - Adam Slattery Cheers, Nico --
