Emmanuel Dreyfus wrote:
Sure, I'm very interested by feedback on the actual content on
document. Here are the feedbacks I gathered so far:
1) I used deprecated features, but I was not told which was the
The use of plaintext passwords to authenticate to "strong" authentication
systems is discouraged. Browsing through the mailing list archives will turn
up this point in discussions time and time again. The use of Simple Bind to
authenticate against SASL, instead of using actual SASL Binds, is deprecated.
The use of Simple Bind to authenticate against Kerberos is deprecated. etc.
2) I document only a small part of SASL capacities. I'm aware of
The scope of the document was just to explain how to validate a
login/password against a random PAM authentication source. It's better
Are you so sure it's better than nothing? With "nothing" the integrity of
your site's security policy remains intact. (Granted, no work gets done right
away.) With "something" your site's security policy may crumble to nothing
(and then down the road, no work may get done, but for worse reasons).
3) Doing authentication that way is The Wrong Way, I should
authentitcate against LDAP or Kerberos. Well, it would certainly be
better to do that, but is it completely unreasonnable to start using
OpenLDAP without refactoring the world around it? Migration paths can go
through harsh flag days or through softer incremental steps. I'm
convinced that setting up an LDAP authentication against PAM can help
people that try to make a small incremental step.
You are trading off security for expedience. That's almost always a poor
trade. If you have convinced yourself that you've weighed all of the pros and
cons, go ahead, but we will never encourage such a thing.
You have to step back and consider - what is authentication for? What is
being secured? What are the consequences of insecure access to the data? What
are the consequences of giving away a "secure" password? Can you actually
enumerate all of them?
Taking very simple examples - the directory either contains highly sensitive
information, or it contains completely public information. In the public
case, there is no need for enforcement of authentication at all. If the
system is public anyway, then you should use no passwords, or you should use
low-value passwords - e.g., passwords that are only valid in the context of
the directory server itself.
If you use a password to a "strong" security system, and the directory
service is breached, you have very likely given away the keys to a lot of
much more important systems, that were all protected by that same "strong"
key. Can you afford such a possibility?
Using SSL/TLS to encrypt the sessions isn't a fool-proof solution. If you
still have a cleartext LDAP port enabled on the server, anybody can perform a
plaintext Simple Bind. Even though the server security policy may reject such
a Bind, the damage is already done because the plaintext password has already
been sent across the network. Do you really want to risk that?
In short - don't use Simple Binds unless both the passwords and the directory
content are of low importance. Once you connect Simple Bind to a "strong"
security system (like Kerberos, RADIUS, whatever) you jeopardize every other
service on the network that also uses those systems.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/