Discussion on:

Migrating from shadow passwords to tcb in Linux

This doesn't provide either of the two things I tend to look for in an article like this:

1. a reasonably complete explanation of why a piece of software is good, how it works, and what decisions need to be made about using it (or not)

2. a clear and detailed explanation of how to implement a solution for practical use

With either of these elements, it could be a really good article. As it is, the article does little more than say "Here's the name of something you should probably use. Go look it up." While that can be helpful to some small degree, informing me of something to look into, it's not nearly as helpful as I'd like.

Perhaps, in addition to describing the shortcomings of shadow passwords with MD5 encryption, we could have some information about what makes tcb good -- more to the point, what makes it worth the effort of recompiling and/or patching a bunch of software, potentially forcing removal of some packages from the platform's comprehensive software management system.

I agree with apotheon - this article in no way provides any details as to why I should change my existing, working openSUSE 10.1 installations that already use blowfish encryption to tcb.

Articles like this degrade the value of TechRepublic for IT professionals.

I found the article to provide what I would expect from a TR article: it's short, gives a very basic overview of a product I've never heard of before and leads me to more information about the product. I don't really need or want you to provide every single details. Those are the kinds of needs you see from users, not IT folks.

The problem with these little TechMail articles is their length.
When I was writing full-length articles for TechRepublic years
ago, I could really dig and dissect things and use a much
broader brush to paint the picture, so to speak.

With these little 300 word techmails, that kind of detail isn't
possible. So, sure, it would be fantastic if I could dig down and
get into the nitty-gritty, but it's just not possible in this
particular medium. =)

Now, having said that, yes, it's lightweight (they all pretty much
are) but it's not supposed to hold your hand and tell you the
how and why (although it would be great if I could)... it's
supposed to get you thinking, possibly get you interested, and
then move on... the references to Openwall and Annvix should
be sufficient to peek at what tcb is all about. And the link the to
the tcb page itself should take you to a slide presentation that
you can look at to see the how-and-why of using tcb over
traditional shadow files.

Bottom line... think of tcb as the next progression. Remember
when we used to have crypt passwords in /etc/passwd and there
was no shadow file? The natural progression there was to a) use
something stronger (md5) and protect the passwords (the
shadow file). tcb goes even further. Blowfish by default
(nevermind that SUSE uses blowfish in the shadow file... that's
only half the battle), but also separating passwd entries per-user
so that at any given time someone can only obtain access to
their own password and no one else's.

Keep in mind that if you have some software that needs to look
up an authentication token (password) you're reading the entire
shadow file, which has everyone's password in it. If there's a
problem/bug/vuln in the program, you could potentially get
everyone's password (well, the md5 of it anyways, but john the
ripper can help there). With tcb you can only *ever* get the
calling user's password because instead of reading in a single
shadow file with everyone's password, you can only ever read
your own shadow file which only contains your password.

The benefits of tcb should be obvious.

Sorry, I'm not entirely sure what you mean by TechMail in this context.

As for the benefits of tcb, these things could certainly be inferred from the article by someone who has done professional IT security work like me, but it's far from explicit. A single paragraph could have clarified that tcb provides these benefits. It was probably just an oversight, but an oversight I would have preferred didn't happen. That alone would have doubled the value of the article, in my opinion.

EDIT: Actually, a short bulleted list of summaries of the benefits of tcb over shadow passwords would probably have been ideal.

This is better than LDAP how?

Seems like TCB is merely reinventing many of the LDAP security schemas, esp as there's a PAM module from LDAP so apps don't have to modiefied in either case.

LDAP can't replace the passwd file 100%. Where does the root account live? What about the account that slapd runs under? At the absolute barest of minimums, even on an LDAP-based system, you need two accounts in passwd and they're the ones that need the most securing. On top of that, LDAP is a bit of overkill for a simple desktop. This provides a simpler solution for those not wanting to implement a directory just to log in to their own machine.

Unfortunately, while it's simpler in concept, it's currently more complex to implement in most cases.

TCB isn't a reimplementation of LDAP. Granted, LDAP is an
excellent NIS replacement and works great in a network... I use it
here on my network because it makes managing my vmware
workstations and other servers so much easier.

TCB, on the other hand, is a replacement for a local
authentication system (like shadow), not a distributed
authentication system (like LDAP or NIS). Running LDAP on my
one colo server is nonsense and has absolutely no benefit (and a
whole lot of drawbacks). TCB, on the other hand, makes a lot of
sense there. Nevermind home use desktops and laptops
(although, TCB's greatest strengths are in multi-user systems,
but that doesn't require a multi-user/multi-system network
topology).

Two very different things. And, FWIW, LDAP and TCB can co-
exist just as nicely as LDAP and shadow.