
Ask HN: How is LDAP not a huge security risk? - underyx
So, I&#x27;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 <i>everything</i>.<p>How come I didn&#x27;t find any literature about this issue? Is there some solution I don&#x27;t know about? If not, why do people even use LDAP if it&#x27;s so inherently insecure?
======
mountaineer22
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?

~~~
underyx
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.

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

~~~
underyx
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.

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

------
EJTH
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.

------
NeutronBoy
> 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.

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

No it wouldn't.

~~~
underyx
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.

~~~
dozzie
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).

~~~
underyx
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.

~~~
dozzie
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.

