[SATLUG] RE: kerberos

[Justizin]

On 12/1/06, K. Spoon <kell at spoonix.com> wrote:
> On Fri, Dec 01, 2006 at 09:55:34AM -0600, Justizin wrote:
> > On 12/1/06, K. Spoon <kell at spoonix.com> wrote:
> > >How does an md5 hash not satisfy this requirement?  You don't have to
> > >store passwords in LDAP in the clear... md5 and crypt are supported out
> > >of the box.
> >
> > Well, this means I have to hand out a private key to a thousand
> > application developers, right? :/
>
> What?  No.
>
> http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html
>
> The basic gist is that you take a string, run it through the md5
> algorithm, and store the hash that's created somewhere... like, the
> /etc/passwd file or say, an LDAP server.  Only the hash is saved...
> password is dropped after the hash is created.

Oh, duh, I've known this for years.  For some reason I was thinking of
the way we used to encrypt passwords at Rackspace which strained the
trust network, which was not an md5 hash but some key-based
encryption.  The goal is different because we needed to actually see
people's passwords so that we could remind them, though an md5
hash-based system which could automatically *reset* the password on
someone's server would be far more secure. ;)

> Whenever a user wants to authenticate, the application that they type
> their password into computes another md5 hash which is then sent back to
> the authentication server for it to compare against what's stored using some
> mathemagical formula I won't even pretend to understand.

I also won't pretend to understand this bit. ;)

> If the 2 hashes match up, the server sends back a thumbs up and the
> application awards authentication to the user... if not, try again, Beavis.
>
> No common cert is needed (because the md5 algorithm is what's shared),
> and the only thing sent over the wire is the hash, not the password
> itself.  This is why everything from login to apache uses it, and
> because there's no (easy) way to "decrypt" the password from the hash
> it's why so many authentication systems require the admin to reset
> instead of resend passwords.
>
> Also.. I happen to know for a fact that Plone in 2003 was indeed capable
> of handling not only authentication via LDAP, but could even speak md5.
> In addition, we used posixGroups to establish user authorization to
> various parts of the site.

Plone and LDAP have issues, and python-ldap hangs Zope threads for
some reason that noone seems to care about.  I'm glad to write "fixing
python-ldap" into my proposal, but I'd like to nail down what all
python libs I'm going to need before offering to take up
maintainership of all of them.

FWIW, plone.org runs on a single machine, which is not going to happen
with acm.org.  That is the only reason plone.org does not hang from
its' LDAP authentication, and I think there are too many small Plone
clients who don't care about this for some reason, even though at
least half of the reason of using Plone is to scale better than PHP.
The ACM is probably a good organization to step in and improve some
things here, but maybe some parts of the architecture are weak and we
don't want to take ownership of them.

I will already be configuring PAM+LDAP on all of the Plone servers so
that, for instance, members of the "System Managers" group will have
ssh.  It does seem like a wise suggestion which I got not only from my
friend Sean, but from Nick Borko, to hand credentials to PAM instead
of owning some python code which is architecturally similar - in fact,
this code in Zope is called PAS.  Are they "pluggable modules" or
"plugins for an authentication service" ?

Fun. :)

-- 
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/