Could you elaborate on your attack scenarios?

Maybe I am wrong, but can you not have multiple LDAP server in a hierarchical relationship?

So, for a hackathon, a child LDAP server would be used, but if compromised, would be limited to the administrative capacities of the role created for the hackathon LDAP admin/authentication roles?

Yes, I totally messed up by not explaining the scenarios, so here's two I can think of:

- Someone naively sets up error reporting that takes the POST data and logs it somewhere. Employees can now see the passwords from POST data and impersonate each other, or in an even worse case, a vulnerability with the error reporting software can leak the passwords to the public.

- Employees will just leak their own passwords like any human would. LDAP locks you into using one password for everything, making this a much larger risk.

> Someone naively sets up error reporting that takes the POST data and logs it somewhere

If you are not securing your logs, you may have a much bigger problem than just exposing user passwords.

> Employees can now see the passwords from POST data and impersonate each other

Than either don't give them access to logs (where they can find far more dangerous information than a password) or simply accept that (common for developers) they have to be trusted, and your auth protocol really doesn't matter in that case.

> a vulnerability with the error reporting software can leak the passwords to the public

Again, if your logs become public, passwords really may not be the worst of your problems.

Keep in mind that main benefit of having LDAP server is centralized user management. Once you have that, you are free to use whatever auth protocol you wish - LDAP, OAuth, whatever the apps will support. LDAP is particularly easy to use, but if you don't like it and have control over your applications, use something else.

How is this not true of any other centralized authentication system?

I don't know, this is why I'm asking. I don't know if the issue even really exists or if there are workarounds.

But OAuth tokens for instance are bound to services, aren't they? If I'm correct, that would make that sort of centralized auth resilient to apps leaking credentials.

There could be a bug in the OAuth server, where tokens are issued. Credentials could be logged there.

My biggest peeve with LDAP is the fact that it does anonymous login by default if no password is supplied.

This combined with the fact that many libaries for LDAP is basicly wrappers for C libaries you have the perfect vector for attack in many places such as PHP and node.js where a null byte in a string doesn't mark the end of a string, because it will usually be trivial to inject a nullbyte character and most devs just check for string length...

I have found nullbyte injection flaws in both our node and PHP apps that talk directly to our LDAP server, even code from very competent devs, because no one seems to think that node.js would have the same flaw as PHP in regards to null byte injection in library calls.

> and some being just quick hackathon projects that needed authentication, a bug ...

The solution here is not to 'fix' LDAP, it's to have proper processes for testing, change management, and deployment. It's to have non-production environments you can use, etc.

I know it's not particularly popular or trendy in startups, but these processes don't have to be onerous. Just some control over what you put into production. I'm not suggesting you wan avoid bugs, but there are in-depth mitigation you can take to help prevent this.

> a bug in any of these services (no matter how unimportant) would compromise everything

No it wouldn't.

My bad, I forgot to include that I meant a bug that leaks the password.

Basically my problem is with having one password for everything. Set up a package index with LDAP auth, and people will just carelessly save their credentials in plain text so that `pip` or whatever can pick it up.

First, you seem not to understand how LDAP authentication works. It's not reading plain text passwords to compare against what user provided. It's not even reading a hash and comparing user-provided password with that. It's sending password to LDAP server to ask if it is valid for specified user.

Then, don't underestimate the alternative: a selection of sticky notes with passwords for each service slapped on monitor, which is still a valid concern in business setting. And with LDAP you at least have one place to invalidate credentials and to enforce minimum password complexity (to avoid "password123" passwords).

A scenario for leaking passwords would be (from a comment of mine below):

>Someone naively sets up error reporting that takes the POST data and logs it somewhere. Employees can now see the passwords from POST data and impersonate each other, or in an even worse case, a vulnerability with the error reporting software can leak the passwords to the public.

I guess the second point is fair.

You don't have any way of defending against that stupid scenario, with or without centralized passwords.

Additionally, most of the users would probably use the same password for each of the services anyway, so you have pretty much the same situation in both cases, only you don't have a quick and reliable way to invalidate all the passwords.

> Basically my problem is with having one password for everything.

LDAP does not mandate single password. You are absolutely free to use something that will generate one-time passwords and send them via LDAP.

Ah, now that, I did not know about. Do you have any specific examples?

I haven't used it, but first result in google is this for OpenLDAP: http://www.phoronix.com/scan.php?page=news_item&px=openldap-... . What I really meant was that you have user who types password, an app that uses LDAP protocol to send password and LDAP server which verfies it. You can easily password generator (as many banks do) without changing LDAP protocol.