Fwd: tcb, crypt_blowfish for DragonFlyBSD

[grzela@xxxxxxxxxxxxx]

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, grzela@seculture.com 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
> ldv@owl 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 kernel@lists.dragonflybsd.org 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 kernel@lists (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