Emmanuel Dreyfus wrote:
Sure, I'm very interested by feedback on the actual content on the document. Here are the feedbacks I gathered so far:
- I used deprecated features, but I was not told which was the
deprecated features
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. etc...
- I document only a small part of SASL capacities. I'm aware of that.
The scope of the document was just to explain how to validate a login/password against a random PAM authentication source. It's better than nothing.
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).
- 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.