On Tue, Apr 15, 1997 at 08:20:17PM -0500, Adam Slattery wrote: > > Have you seen my discussion with Michael Tokarev which was on this > > list a few months ago (there were several related threads)? He was > > designing a pam_unix replacement, and I was advocating making it > > transparent for arbitrary password hash types. The module would > > contain no crypto code at all and would have no need to know about the > > possible password hashing methods. > I'll have to go look for it. pam_crypt has no knowledge of the algorithms > hard coded. All outside support and information is handled through > dynamically loadable modules and a config file. Theoretically I will never > have to update pam_crypt, only the modules contained within the tarball and > the config file. > I don't know how you were thinking of implementing this concept, I'd have to > go read the thread (I just subscribed to the pam list today :). I'm not so sure it's time to get the password hashing code out of libcrypt, so I was passing the two crypt_gensalt() arguments from pam_pwdb down to libcrypt. Support for dynamic password hashing modules could be added as a feature of libcrypt. > > As I've mentioned in the thread, this is currently implemented as a > > patch to glibc's libcrypt and a patch to pam_pwdb -- and I am using > > that in a distribution. > When I started thinking about this project I wanted to do a glibc patch, but > Jeremiah Johnson recommended I use a pam module. Authentication doesn't > belong in libc anyway, as pam has shown. Then I looked at patching pam_unix So far PAM hasn't shown that. NSS isn't a part of PAM, but is a part of glibc. Some Linux-PAM modules have password hashing code in them, but that has to be duplicated in libcrypt for other parts of the system to work (sulogin, gpasswd). PAM isn't good for large virtual hosting setups. It's inefficient, doesn't have established virtual domain support, and common PAM modules aren't MT-safe. If you implement a framework for password hashing modules, it should be separate from PAM. > (or pam_pwdb, it's basically the same thing). I decided it would be better > to just start with a clean code-base for various reasons, so that's what I > did. The existing pam_pwdb/pam_unix modules aren't as clean as I'd like them to be, but the same applies to your current code (I've just read some of it). Sorry. > > I'm sorry to say that, but I'd want you to drop VCBlowfish until its > > better researched and shown to be _significantly_ better than bcrypt > > and about as good as we can get at this stage. > > Ok, that is definately a logical and reasonable argument. Several people > heard I was working on a blowfish based crypt() and encouraged me to include > it in pam_crypt. I think this is because they've heard that Blowfish is "cool". In reality, it's primarily things other than the choice of an underlying cipher which make a good or a bad password hashing method. > You are correct though, it has "not" been researched and I > know for a fact it can be optimized a lot. Sorry I left it as the default It's not just optimization. > algorithm in the config file, that was "not" intentional. My reason for > including it was mainly to foster discussion of some of the ideas I > implemented and how I implemented them (I probably should have finished the I think there're other ways to do that, and I think that you will want to drop your current algorithm entirely quite soon. ;-) > white paper before I released vcblowfish). I think I will still include it > in pam_crypt, but I will recommend against using it. Does this sound ok, or > would you rather see it distributed seperately? I'd rather see it distributed separately, but of course it's up to you to decide. > > I myself have some > > concerns regarding bcrypt (what about yours?), and I have some ideas BTW, my opinion after a brief look at your vcblowfish code is that it's definitely no better than bcrypt. I could have missed something which you think is an advantage, so some documentation would help. > >The addition of yet another password hashing method only makes > > things worse. > Actually I think it makes things better if there is a clear, well-written > white paper to go along with the implementation and it is geared towards the I agree. But it may be a bit too early for writing a white paper as I expect you to make significant changes (actually, start from scratch) after initial discussion of the desired properties. ;-) > discussion of specific ideas and how they are implemented rather than the > design goals of the "method". Why would anyone need a description of some ideas when they aren't meant to achieve any goals? I don't think I understand you. > > Now this sounds more similar to the framework Sun (Alec Muffett et. al.) > > are preparing (not sure if they've released it yet). > I didn't here about that. Hopefully Sun didn't patent it. It was going to be released under Sun Public License or weaker. BTW, it's up to you, but I think your pam_crypt package should be under a license weaker than GPL. You could make it "GPL or BSD" similarly to the rest of Linux-PAM. > Sorry for taking so long to respond, I'm sure you were anxious for my > response. I had some non-computer related stuff that came up this afternoon. It's OK, and it often takes me much longer to reply to my e-mails. There's nothing urgent about this. We didn't have a framework like this for years. You don't really have to make it ready for release with Linux-PAM 0.76. In fact, you could want to let it stabilize before you submit it for Linux-PAM. -- /sd
