> 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
