2

Say you work for LargeCorp, you have a LDAP login to access your desktop, access various internal applications etc.

It's convienient because you don't have to independantly manage authentication for each application you use; this is convenient for both yourself - you don't need to remember ten different passwords, and for the developers, who don't need to implement their own authentication.

The problem is - say someone points me to an application which asks for my LDAP username and password - how can I be sure that this isn't a phishing attempt from someone within the organisation? This is a large corperation after all, I can't trust that developers are not incompetent/malicious.

The plausible example I can think of, is a disgruntled employee sends his manager a link to an internal application - 'Hey boss, check out this new tool we've made'. Boss logs in with his LDAP credentials and disgruntled employee now uses the boss's credentials to read his boss's emails.

Out in the wild - we'd suggest that you should use a different password for each website you use - so (assuming I have a perfectly random password) there would be no risk to my other logins by accessing this site. But with LDAP I have to use the same password.

What security principle is there that justifies LDAP centralisation?

2

LDAP should only be used on an internal network. Therefore, all services using it should be on the internal network, and should be secured from outside access. In fact, you should make sure you have specific firewall rules in place to prevent LDAP access from the Internet, nor should you try to use LDAP on a website on the Internet. It's simply not secure for those purposes. Finally, users should definitely use a different LDAP password than sites they frequent, and the network should be configured to require a new password no more than once every 90 days (72 is the recommended maximum). As long as LDAP is safe behind a firewall, it makes sense that all internal apps use the same protocol, to minimize the number of passwords you need to set.

That said, I can't, in good conscience, recommend LDAP for pretty much anything. It's an old protocol, and has since had a number of useful successors, like JWT, SAML, and OAuth, which not only allow to you use just one password, but also ensure that your password is never visible to the service requesting the authentication. The only thing the service gets is a unique token that verifies that you are who you say you are, plus a unique identifier that may not even be related to your real username. Users can also generally revoke these tokens at any time, and verify that an app is authorized to use those tokens by way of "grants."

  • The concern is more being phished by someone inside the organisation. – dwjohnston Jun 15 '16 at 10:28
  • @dwjohnston If there's some concern about internal phishing attempts, the people attempting to do so should be fired/arrested/prosecuted/etc. LDAP is widely used on internal networks because it gives users a single password to remember for the entire network, but isn't particularly secure. You should definitely protect sensitive systems with something more than LDAP, such as RSA, 2FA, or some other hard-to-defeat system. – phyrfox Jun 15 '16 at 15:38
  • I've added an example that I think is plausible - a disgruntled employee phishing his boss, so he can read his boss's emails. – dwjohnston Aug 8 '16 at 5:09
0

Normally you protect your LDAP from anonymous access, so all request are being done from a account, not just a request fired at a server.

Also while LDAP is a standard (that has withstood the test of time as HTTP and SSH have) its structure however is not 'standard' there are many ways to implement where and how a user authenticates, both in field names and in methodology.
As for the trust issue. Yes LDAP is only supposed to be used on a LAN and only on places you know its supposed to ask for your LDAP credentials. This is however no different from any other Credential scheme.
I do not agree with @phyrfox though as to not recommend LDAP. as a protocol it is solid and has withstood for many more years than any of the alternatives the he list. I would like to add that you should only use a TLS secured LDAP with client login and separated area's of access (so when an application only needs your name to display the can in fact not see any other details bout you).

LDAP is a protocol to easly dismiss as beeing old. but most of the time the people that do that have not really delved deep enough into the workings of the protocol and what it can offer. The other technologies like JWT oAuth (2) and SAML actually augment LDAP not replace it. not even OpenId Connect does. which comes closest of them all.

It is important to realize that LDAP is a Directory protocol and not a Authentication or Authorization Protocol. while you can use it for such things care has to be used as to not introduce weaknesses in the system.

For anyone who is unclear on what a Directory is, its a List of Properties. Like a File directory is a List of files with some Meta-information about them (when was it made, what name does it have, etc.) A good example of a Directory is the Yellow pages or other Phone book.

  • 1
    The complaint about LDAP being old stems from fundamental flaw in it, which is that you are authenticating with the Application service rather than with the Identity service. Modern enterprise authentication practices use Single Sign On with dedicated Authentication server. You only ever enter your credentials to the Authentication, not the Application. This requires much less trust in the Application. – Lie Ryan Jun 14 '16 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.