How do you turn on password hashing (SSHA) in openLDAP [closed]

Question

For the life of me, I cannot seem to find this anywhere and if anyone can even just give me a link I would be very appreciative.

We are trying to turn on SSHA hashing in openLDAP. By default it stores passwords in plaintext, which I think is criminal but hey I am an AD guy so what do I know. But you would think that they would make it easy to find the information needed to turn on hashing if you so choose. And wouldn't you choose?

Machinist

It is worth noting here for others: storing hashed passwords in your authentication database (LDAP, AD or anything else) isn't quite the security panacea it appears to be. SASL dramatically improves security over the wire (across the network), but requires that the original password be available to both ends of the link. So the tradeoff is better security in the datastore (hashing) against better security over the wire (SASL). – Knossos

From man slapo-ppolicy: Specify that cleartext passwords present in Add and Modify requests should be hashed before being stored in the database. This violates the X.500/LDAP information model, but may be needed to compensate for LDAP clients that don't use the Password Modify extended operation to manage passwords. – Macron

Answer 1

You can use 'password-hash ' to change the hashing algorithm, the default one is SSHA (not clear text).

Note that, slapd uses the above only if the password sent by clients are in plain text, if your client is sending a hashed password, it'll be stored as it is.

for eg: with pam_ldap, use pam_password exop (or clear)

how is password strength tests run at the server if the password is coming in hashed and I know that is a feature openLDAP touts?

If you sent hashed passwords, slapd cant perform strength tests, so the clients must sent passwords in clear text(ppolicy has option to accept/reject hashed password).

Note:

1. make sure your clients use ssl/tls (so the passwds are not sent in clear text)
2. userpassword attribute contains special characters ({}) so you have to do a base64 -d to identify the hashing algorithm used.

eg: normally the attributes are returned in the following format (:: indicate the result is base64 encoded)

userPassword:: e1NTSEF9QjU0VXNmQWhJN1dQZ3FvbDVSQ1l5RHUzTlVqa1luVVhYV2ljbmc9PQ=
 =

$ echo e1NTSEF9QjU0VXNmQWhJN1dQZ3FvbDVSQ1l5RHUzTlVqa1luVVhYV2ljbmc9PQ==|openssl base64 -d
{SSHA}B54UsfAhI7WPgqol5RCYyDu3NUjkYnUXXWicng==

Tough

Thanks Naj. Your suggestions became part of our solution. My comment about testing strength was actually questioning others who suggested that the hashing should take place prior to sending to LDAP for auth. The statement above was something that occurred to me that made me suspicious of the comment. Thanks again...win goes to you my friend. – Machinist

Answer 2

The LDAP spec requires plaintext passwords for interoperability. The link given above on security will give you the option for default hash types that the server can enforce, but do consider the implications.

Campanula

You are correct about the requirement to send plain text. I guess that is why openLDAP requires SL to be turned on before one can configure it to start hashing passwords. My question is, why does it allow one to send it plain text passwords with hashing turned off. Security wise , wouldn't it be better to have hashing turned on from the get go and require the user to turn it off. Sort of the BSD model, everything closed by default requiring the learned to turn the dangerous stuff on. – Machinist

Answer 3

When you tried to store userPassword attribute in add/modify LDAP operations, userPassword value is stored as plain text. But you can override this behavior using ppolicy_hash_cleartext option in ppolicy overlay module in OpenLDAP. Once you enable it, when client sends a plain text password, it is stored as SSHA by default. You can find more details on enabling hash password in OpenLADP from here

Finstad

Answer 4

This is an old question, but still relevant. It's no longer recommended to use SSHA (ie. SHA-1) due to its relatively easy brute-forcing.

A more secure hashing algorithm is SHA-512. A stronger hash can be generated on the client side with OpenSSL 1.1 like this:

_generate_password_hash() {
  local plaintext; plaintext="$1"

  command printf "{CRYPT}%s" "$(openssl passwd -6 -stdin <<< "${plaintext}")"
}

This will output a string such as:

{CRYPT}$6$SGIWzAbjh.3WoQQJ$vEFlcRBQpd2fJ8dxcbojr83pjQcXcJ.InRMzNRryTQ//fMYJoCRFWAPn22EvJyDikG.MNuUqRYqQtI97Clj2F0

Notice the {CRYPT} instead of {SSHA} in the beginning.

You may apply the password for example with ldapmodify:

ldapmodify -h "${LDAP_HOST}" -D cn=user,dc=example,dc=com -W <<EOF
dn: cn=user,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: $(_generate_password_hash NEW_PASSWORD_HERE)
EOF

Notice that LibreSSL has a different set of hashing algorithms available. Check your actual OpenSSL version with openssl version if openssl passwd --help doesn't show the -6 option.

Gertrudgertruda

Answer 5

OpenLDAP supports a variety of storage schemes for the administrator to choose from. The tool you use to create accounts has to be configured to do the hashing. The server will store passwords in the format the client requests. If hashing is done properly, ldapsearch will show the hashed passwords like this:

userPassword: {SSHA}d0Q0626PSH9VUld7yWpR0k6BlpQmtczb

See http://www.openldap.org/doc/admin24/security.html for details.

When it comes to administrative tools I would personally recommend http://phpldapadmin.sourceforge.net

Yolk

Really? So you are saying that the only way to have password hashing is to have the client or in other words an outside source do it. That seems less than optimum and a bit dangerous. In the AD world it is centrally done and centrally managed. This is hard for me to believe. – Machinist

Wait, how is password strength tests run at the server if the password is coming in hashed and I know that is a feature openLDAP touts? – Machinist

LDAP is just a directory. Enforcing password policies is up to the authentication layer not the storage layer. Really that's how the UNIX world works, there is a tool that does only one thing and does it well. To enforce password policies you need to configure the tool that your users will use to change their password, be it a web interface or a command line utility. I understand that this could be hard to believe that there is no "central" thing that does everything, but that's the idea of modularity. – Yolk

If you want a complete solution with everything configured out of the box and an admin interface on top of it, consider using FreeIPA . It has LDAP (RedHat's version not OpenLDAP though), Kerberos etc all pre-configured to work with each other and a neat web interface on top of everything. freeipa.org There is one caveat though: you need to run it on top of Fedora or RedHat EL – Yolk

Thanks everyone, we got it working. Our openLDAP is now handling the hashing (ssha) of incoming passwords and authentication against that hashed password. It seems the lesser used or configured once and left to "just work" features of LDAP is sparse in references and domain expertise. I was only able to find one single link after hours of Googling, luckily that was the only one I needed. Props to Najmuddin for giving me part of it. Prize goes to him. – Machinist

@Yolk You don't appear to be aware of the OpenLDAP Password Policy overlay which does many of the things you have told him should be done by the client. It requires the password to be supplied in plaintext so it can enforce quality, check for re-use, etc. – Vinic