> This is interesting, but I strongly dislike some of your design > decisions. Ok. Thanks for saying so, this is the kind of feedback that is most helpful. I hope others will follow suit. > 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 :). > 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 (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. This is going to be used in a distribution too. Sunrise linux. Jeremiah Johnson said you were interested in it but unable to help because of openwall. It's a small world :). >> (currently 3, this will increase significantly when other people > > submit algorithm modules or I adapt a few more algorithms). > > "submit algorithms" sounds bad enough for me already. New algorithms > may be supported without that, and I'd prefer a very good reason for > adding each new algorithm regardless of how easy that is with a framework > we pick. One algorithm(*) change in 5 to 10 years is what we should try > to achieve. Yes, I worded that incorrectly. What I am talking about is if somebody were to implement an AES based crypt(), this module would reduce the work load "significantly" in order to put the algorithm to use. At the moment I would like to get a bcrypt module as soon as possible (I believe you did a c implementation for an obsd password cracker and was thinking about using it...:). In the next week or so it will probably be added, right now I've just been getting the framework done. And now that it is pretty much full-featured I can focus on other aspects (such as a bcrypt module). > 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. 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 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 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 myself have some > concerns regarding bcrypt (what about yours?), and I have some ideas > on how to improve some of the properties I'd like it to have. But I'm > not releasing such unfinished thoughts for deployment (for three years > now). We should get together at defcon or something... After hearing your thoughts about this topic, I think I probably should have waited as well. >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 discussion of specific ideas and how they are implemented rather than the design goals of the "method". I am not yet finished with the white paper for vcblowfish, and I don't have any date in mind of when I will finish it > Designing a good password hashing method is a non-trivial task, and > making it better than one of the best (bcrypt) is even harder. Most definately. > 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. > OK, this is better than I thought your "submit algorithms" implied. > Perhaps just my reading of it then. :-) No, it wasn't your reading of it. It was "my" writing of it. Hopefully my above response clarifies what I was refering to when I said "submit algorithms." If this still bothers you I'd be happy to discuss it further. 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. Thank you, Adam Slattery aslattery@whstechs.org
