I've seen a few posts on the internet saying most people store user passwords in OpenLDAP using one of OpenLDAP's many, built-in hashing functions. But OpenLDAP itself recommends handing off password hashing and decryption to a separate service

Furthermore, RFC 4519 Section 2.41 states that passwords stored in an LDAP system should not be hashed, but rather stored in clear text.


The OpenLDAP docs suggest handing password hashing off to another service, specifically the Cyrus SASL library.

I'm seeing a lot of older hashing algorithms listed in both packages' docs as well. Stuff like SHA-1 and MD5.

In 2015, are there any common practices for hashing passwords managed through LDAP? Which hashing algorithms are commonly used these days? Is it very common practice to hand hashing off to a hashing service? If so, which packages are common on Red Hat Systems? Where do they store hashes?

  • 1
    see github.com/hamano/openldap-pbkdf2 . Also encrypted != hashed Aug 20, 2015 at 22:21
  • Where does it state "that passwords stored in an LDAP system should not be hashed"? ​ ​
    – user49075
    Aug 21, 2015 at 3:23
  • @RickyDemer Section 2.41 "Passwords are stored using an Octet String syntax and are not encrypted." This is also reflected in OpenLDAP's documentation: "RFC4519 specifies that passwords are not stored in encrypted (or hashed) form." Both are linked in the original question posted above. Aug 21, 2015 at 18:42
  • 1
    You might also consider OpenBSD's ldapd , which has bcrypt hashing May 8, 2017 at 18:20
  • RFC 4519 is from 2006 or so, making it understandable that it might not have yet been fully understood just how bad cleartext passwords in a database are. Conversely, it could just be implying that no additional encryption is applied. However, the idea of having multiple passwords, at least, was apt. Nov 30, 2018 at 20:41

3 Answers 3


It is about how you interpret what they are writing. They are not saying you should not hash and should store passwords in plain text. What it is saying is that the value you write into LDAP is not hashed or encrypted. This is like the situation you have with a normal database. You can define a column called password and you can either tell the database to encrypt that column or not. You can then stick data in that column, which may be encrypted/hashed or plain text. If you define the column as being encrypted, then data is encrypted as it is written to the column and will be decrypted when it is read from it. If you are storing hashes of a password, that hash will also be encrypted and will require decrypting before it can be used. In general, database encryption is about protecting data exported in data dumps etc. It is a bit like disk encryption in that once you have access to the database tables, the encryption/decryption is done behind the scenes and you don't see it. However, if someone manages to access a dump of the data or gets access to the table datafile on disk, they won't be able to read the information.

Note the definition of password attributes as being stored in an octet string syntax. This format is defined to support the full range of characters you will encounter in hashed passwords. What the best practice is saying is that LDAP stores the value you give it 'as is' without any further encryption or hashing. It is the duty of the software which manages this data to do whatever hashing you want

The 'L' is LDAP stands for lightweight. An LDAP server typically sees lots of reads with far fewer writes. It is designed to handle lots of queries and tries to ensure good performance by keeping it simple. Adding encryption creates additional unnecessary overhead. If the password attribute was encrypted, then all queries would need to decrypt that information, degrading performance.

LDAP also keeps things simple by not providing a management interface. It is essentially a defined tree of attributes and values whose primary role is to answer queries. To further re-inforce this, you will often find that in high-demand environments, you will have a master LDAP server where all the writes/updates are sent and slave/replicaiton servers where all the queries are sent. When you write to the master, if will forward on the changes to the slaves.

Management of the data is usually performed by some other program. For example, at our site, we have a perl program which receives data from our IAM system. It then takes this data, applies some business rules and writes the results to the LDAP master. The perl program performs the hashes of the passwords (we actualy need to support multiple hash types for each password because not every application understands the same hashing algorithm. This hashing also adds a salt.

When a client queries the LDAP server, it will just get whatever is stored in the attribute. With passwords, the data stored includes details of what type of hash has been used. Of course, for binds to work, the LDAP server must understand at least one of the hashes being used in order to perform the bind.

In our case, the main hash we use is SHA-512. References to MD5, SHA1, Crypt etc are outdated and should not be used. This is another example of the advantage of this approach. We used to use SHA-1 and even Crypt once upon a time. We could update to a newer hashiing algorithm easily without having to worry too much about LDAP and versions etc.


The LDAP server certainly does hash in some circumstances, such as verifying a bind. A stored password looks like this (my real password, crack away ;)


Notice that the hash algorithm is included in the hash. There is a fairly standard set of hashes in use with client software e.g. phpLDAPadmin has: blowfish, crypt, ext_des, md5, md5crypt and a few more. I would expect this is standardised somewhere. Newer algorithms are not available by default, so I would expect md5crypt is the best of these option - it's salted and has a work factor (1000x).

Apparently there are plugins for newer hashing algorithms; see this question. That's your best bet.


Please refer to Password storage cheat sheet for more details about acceptable hashing algorithms. As indicated by @Neil you should be able to use the recommended hashing algorithm in openldap.

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.