Ask HN: How is LDAP not a huge security risk?
So, I'm thinking, if you have like 50 services connected to LDAP, with some being mission critical, and some being just quick hackathon projects that needed authentication, a bug (edit: a bug that leaks the password) in any of these services (no matter how unimportant) would compromise everything.
How come I didn't find any literature about this issue? Is there some solution I don't know about? If not, why do people even use LDAP if it's so inherently insecure?
17 comments
[ 1.8 ms ] story [ 182 ms ] threadMaybe 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?
- 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.
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.
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.
No it wouldn't.
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.
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).
>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.
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.
LDAP does not mandate single password. You are absolutely free to use something that will generate one-time passwords and send them via LDAP.
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.
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.