I asked Solar Desinger for advantages and disadvantages between master.passwd and tcb, and between md5 and blowfish password format. I forward his request to this lists.
On Sun, 18 Mar 2007 23:09:52 +0300, Solar Designer wrote: > On Sun, Mar 18, 2007 at 02:12:12PM +0100, [EMAIL PROTECTED] wrote: > > I am a DragonFly BSD commiter, and we currently debate about implementation > tcb in our system. > > Good idea! > > > We think that in tcb should be possible to store not only password related > record, but all user related informations eg. user dir and shell. > > This is questionable. I think that we're going to keep /etc/passwd on > most systems anyway, so that would result in the same information > getting stored in two places - but you already have that with passwd and > master.passwd. > > Another concern is that this way tcb might become sort of an LDAP (as > [EMAIL PROTECTED] put it in a related discussion), getting expanded to store > more > and more information (e.g., mailbox locations) - and we probably don't > want that. > > On the other hand, on Linux the tcb files store more than just usernames > and hashes - they store whatever would normally go into /etc/shadow, > including password aging information. So it would be logical to move > entire master.passwd lines into tcb files on *BSD. > > > In DragonFly we have /etc/passwd file only for linux compatibility, but > master > file is /etc/master.passwd, to see it via cvsweb: > > http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/src/etc/master.passwd > > It contains all user information and crypted password (which is not set on > installation CD). > > I think it be easy to change tcb in that way. > > It might be. Other changes might be more complicated: > > You don't seem to have NSS. Would you be patching libc instead? > > Also, you'll probably need to be changing from getsp*() to getpw*(), but > that might be easy. > > As an alternative to your suggestion, you can choose to keep both > /etc/passwd and /etc/master.passwd, but add /etc/tcb with only the > hashes (replacing them with "x" in master.passwd). That way, you might > reduce the amount of patching for user management tools. > > When you work on these changes, please keep in mind that certain > precautions need to be taken when accessing /etc/tcb subdirectories as > root. In our security model, these subdirectories are not supposed to > be fully trusted. This is what libtcb is for - it knows how to access > /etc/tcb safely while running with elevated privileges. Our PAM and NSS > modules, as well as the user management tools patches, use libtcb. > > > Second debate is about change default password format from md5 to blowfish, > > Well, you'll need to integrate the password hashing framework introduced > with our crypt_blowfish as it is used by our tcb suite. (Of course, you > may avoid that with more patching for tcb, but it's better to just do it.) > > As it relates to the choice between phk's FreeBSD MD5-based crypt(3) and > bcrypt, the latter is obviously superior. > > > because it's known algoritm of collisions for md5. > > The MD5 collisions are irrelevant to its use for password hashing (and > especially to phk's higher-level algorithm), so that's not a valid argument. > > > Can I please you to post all advantages and disadvantages between > master.password and tcb, > > and between md5 and blowfish to [EMAIL PROTECTED] mailing list. > > I'd rather let you forward this message to the list if you find that > appropriate - please do. I haven't seen this topic previously discussed > on [EMAIL PROTECTED] (I've just browsed the web-based archives), I'm not > subscribed, and I'm not familiar with DragonFlyBSD. If you do forward > the message, please keep me CC'ed. > > tcb pros: > > - Reduced privileges for password changes (primarily the "passwd" > command), so the risk impact of potential vulnerabilities in the > corresponding code paths is much lower (would have been root compromise, > now reduced to ability to bypass password policy enforcement for one's > own password). > > - Usually faster access. > > tcb cons: > > - You'll have to be patching stuff. > > - Your sysadmins might have to learn a few new things, especially during > the initial migration to tcb. > > bcrypt pros: > > - Higher and future-adjustable processing cost, with no need to break > compatibility with older hashes when you increase the cost in the future - > so your password hashes are much harder to crack (if stolen). The move > to bcrypt might mean one word shorter passphrases (say, 3-4 instead of > 4-5 words, or 40 instead of 50 bits) are needed for equivalent security. > > bcrypt cons: > > - Timing leaks (does this username exist?) become more apparent as the > hash computations are purposefully slower. Our tcb suite, when it is > used properly, deals with this kind of timing leaks, but fixes to other > code such as in OpenSSH might be required if you care (we have some). > No perfect way has been proposed to deal with timing leaks resulting > from the use of mixed hash types or mixed bcrypt cost parameters on a > single system. > > - The hashes won't work on many older systems - e.g., if you need to > have them shared with another machine running another Unix-like OS; this > is hardly a reason to not use bcrypt by default - a sysadmin is supposed > to know to appropriately downgrade the hash type used on a particular > system as it might be needed (usually it is not). > > To me, it is obvious that you should go for bcrypt despite of the > downsides above. The timing leaks are already there - it's just that > they become easier to notice. > > -- > Alexander Peslyak <solar at openwall.com> > GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 > http://www.openwall.com - bringing security into open computing environments > > Was I helpful? Please give your feedback here: http://rate.affero.net/solar > > ____________________________________________________________________________ > Czas wybrac dobra nazwe! > www.nazwa.pl > ____________________________________________________________________________ Serwery za 1 zł! www.nazwa.pl
