Subject: Re: Centralized User and Password Management
To: Tillman Hodgson <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 12/05/2004 17:20:40
[ On Thursday, November 25, 2004 at 16:18:25 (-0600), Tillman Hodgson wrote: ]
> Subject: Re: Centralized User and Password Management
> On Thu, Nov 25, 2004 at 04:50:50PM -0500, Greg A. Woods wrote:
> > If I'm not mistaken you also need to keep all your system clocks in sync
> > for NIS (or Kerberos) to be trusted.... Or am I thinking of NIS+?
> Kerberos. But it's only "in sync" to within a 5 minute window, and even
> that is configurable in the config file.
No, it's definitely one of NIS or NIS+ or both that's also highly
reliant on clock synchronisation. NIS+ probalby since it's usually
crypto key stuff that's got timestamps in it -- just as in Kerberos.
Hmmm... yes, anything with Secure RPC needs close clock
synchronisation as there's an encrypted timestamp in the client's
I seem to remember Sun had a security problem with their initial
implementation not checking the time sync carefully enough too. Rather
embarrassing it was. I can't find a reference to it at the moment
though, but IIRC it was discovered very early after NIS+ was first
And with NIS+ it's only a 15-second window too!
> > Oh -- perhaps you mean that other meaning of "single sign on" -- the one
> > which actually reduces your overall security unless (and even sometimes
> > if) your users are extremely and consiously aware of all security issues
> > at all times.
> No, I mean that Kerberos uses a ticket-based system. I log "into the
> network" in the morning, and am not required to enter my password again
> until my ticket expires (defaults to 10 hours, just long enough to cover
> a working day.
Hmmm... yes, that's exactly the problematic definition of "single sign
on" that I thought you meant. :-)
In a secure computing environment it's not uncommon to have the tickets
expire every ten _minutes_, and even that is a huge window if _every_
user is not careful and aware enough to manually invalidate it
themselves each and _every_ time they _might_ leave their terminal
The "other" definition of single sign on is the one where you use the
same password on every host -- e.g. the one you get with NIS/NIS+, LDAP,
or similar centralized authentication systems that are _not_ ticket
> Have you worked with Kerberos at all?
More than enough (though I'm no expert at it).
> Kerberos isn't rocket science, seriously.
No, not rocket science exactly, but the requirements for correct and
secure implementation and operation are very strict and rather detailed.
I'm expert enough at it to know that I wouldn't dare tackle a
from-scratch setup of it without first learning a heck of a lot more
about how to do it right! :-)
> I use an old SparcStation 10 running NetBSD to act as my KDC. Securing
> it is dirt simple: I run no services on it other than the KDC itself and
> access it through a serial console. Your slowest, oldest machine is more
> than adequate to the task. A 25Mhz DECStation (ah, I miss mine) will
> easily support tens of thousands of users.
Yeah, OK, but try that in the typical IT shop that doesn't even know how
to write a proper security policy in the first place. It's rarely, if
_ever_, done right. I've seen the dregs more than once. I've even seen
a KDC sitting in a guy's cubicle -- the same guy who was usually off
visiting some other desk to help someone.
The problem is when it's done wrong then it's worse (i.e. far less
secure) than just using the old-fashioned passwords on every system.
(and almost infinitely less secure than properly using unique one-time
passwords on every system).
(and yes I mean "unique one-time" -- I've seen people set up systems so
that the _same_ "one-time" password works on different systems!)
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>