Some of my colleagues want to get rid of our current inhouse application authentication, and use LDAPS to handle all of the authentication (storing passwords etc.) instead. I disagree and say that we should be building a strong authentication model using hashing and salting like so, and authenticate within the app itself.

They want the application to pass everything onto LDAPS because it means less maintenance; so Microsoft (or whatever LDAP service) is responsible for keeping all of the hashing etc. up to date on their end.

Aside from the problem of needing a secure LDAPS server (which I say is a problem in and of itself), are there any security risks going down a route where the application forces LDAP to handle authentication?

  • OpenBSD's ldapd supports BCrypt password hashing, and I believe OpenLDAP's server has an extension for it Aug 24, 2017 at 19:40

1 Answer 1


There are always risks. The real question is which approach gives risks that are more acceptable to your situation.

The use of LDAP for this is a tried and trusted solution that is well used and well supported. So that is a definite positive. Your bespoke auth is potentially poorly tested and, well, bespoke! How do you prove the risks associated with it? That might be unknowable without spending money on getting it professionally tested.

I would say though that there is LDAP and then there is LDAP! If they really mean that you would be using Active Directory along with the Microsoft standard tools for authentication and authorisation, that makes a whole load more sense than if they are simply saying "let's just use LDAPS".

Vanilla LDAPS may be no better than your current solution. But it might still have advantages if the current solution has minimal support and maintenance.

Bottom line is that off-the-shelf solutions, especially when using well tried industry standards are almost always better than bespoke ones for standard tasks. And are likely to be better supported and tested. But adding a specialist toolset is likely to be even better. Use open standards wherever possible as it makes integration and maintenance a lot easier. So using OAuth for example.

Incidentally, LDAPs isn't difficult to set up. Active Directory can be difficult if you don't already have a Windows infrastructure. If you are already using AD in the same environment as your application and users, it is a bit of a no-brainer.

Assess the risks, impacts and benefits of each without the emotion of protected territories. This should be a documented risk assessment, probably with a benefits matrix.

You must log in to answer this question.