Allow the site admin to set the type of encryption used for binding password. And any salt that is used. Provide encryption mechanisms in the module itself as well as support other encryption modules such as encrypt and aes.

Comments

retsamedoc’s picture

retsamedoc commented

I don't have a problem with having the encryption stuff in the API, but I do believe we should leave the preferred encryption/salt choice in the Authentication module and not in the API. In fact, I can't think of any configuration options for the API (and there probably shouldn't be per other APIs).

johnbarclay’s picture

johnbarclay commented

The server binding credentials is what I'm concerned about, so they fit in the api. I'm happy just picking a preferred encryption and using that and having no UI for the encryption at all. In the documentation, we can say if you have AES or encrypt enabled, we will use that default encryption model over the default built into ldap_api.

If demand emerges for selecting an encryption, we can add a hook or an option later.

The only time I want preferences in the API is when the site admin's preference on a substantive implementation choice is likely to influence other ldap modules. I think the choice of two-way encryption is more fluff than a such a choice.

Does this sound good? Pick a default two-way encryption and go with it. And wait until the demand for choice of encryption demonstrates itself.

retsamedoc’s picture

retsamedoc commented

Er, server binding credentials do not matter. Password decryption is handled by the LDAP server. Unless this is an Active Directory goofiness. Am I missing something?

johnbarclay’s picture

johnbarclay commented

Going to the server, the binding credentials are encrypted. But they are stored in clear text in the database. This is the issue. Someone who has access to the code and db would be able to decrypt it, but it avoids the accidental exposure. The university I work at simply prohibits clear text storage of passwords as an IT policy.

retsamedoc’s picture

retsamedoc commented

Okay, that makes sense. Not really sure what I was thinking before but I agree that we do need some encryption/decryption for bindpw. Sorry.

netw3rker’s picture

netw3rker commented

Just to clarify, this is for local encryption of the connection parameters (which include the password) and not the encryption choice for connecting to the server eg tls, ssl, sasl, etc right?

this feels more like security through obscurity, but i guess there really isn't much of an option beyond that is there?

Incidentally, someone mentioned ldap/sasl encryption to me the other day. I dont know much about it, but should there be some kind of api setup for providing things like public/private keys, or config settings for sasl (if there are any) etc.?

-Chris

johnbarclay’s picture

johnbarclay commented

1. Yes, this is for the connection parameters and it is 2 way encryption. On way before storing in the db and the other way for pulling it out. So it is security through obscurity. But its better than clear text passwords in the db for some. I really don't know a good way to keep that password safe.

2. I think any kind of public/private key or other security layer between the ldap server and drupal should be in the api, ideally leveraging any php and drupal functionality. I think it would be good to get some more of the encryption functionality and preferences in core for drupal 8.

At the same time, the ldap server class in ldap api should be able to be extended by other modules if they want to do something off the wall. I don't think hooks work well for functionality such as changing the binding model.

johnbarclay’s picture

johnbarclay commented
Version: 7.x-1.x-dev » 7.x-2.x-dev

in 7.x-1.x picking encryption methods is in the "ldap_server" module. We'll have to sort this out in 2.x

c-logemann’s picture

c-logemann
he/him
Primary language German
Location Frankfurt/M, Germany
commented

@johnbarclay: Are you sure that the IT policy is not only for the userpasswords? I think the problem with cleartext passwords is all around connecting services between servers like database replication and so on.

As I understand is the idea of hashing/salting/encrypting passwords there should be no (easy) way for uncrypting this. And because the old md5 hashing of userpasswords was not strong enough drupal 7 is using blowfish now.
So every user have to send cleartext password through an interface and this transmitted password is hashed or something to be compared with the stored hashed password.
In this way the ldap module have to send a cleartext password to the ldap server. Because of this we save this password in cleartext in the drupal db.

If you try to encrypt the password for the ldap user for storage in a way which can be unencrypted by the module you have to "tell" the module how it can "find out" the cleartext password.
@johnbarclay: Is this you are thinking about?

Even if we would have a kind of a secret keychain in drupal where we can manage passwords we have to store the masterpassword of the keychain somewhere in drupal because nobody is there to open it manually.
So if anybody have access to the server(s) where the drupal webapplication(s) (more in a cloud) and/or databases are running we have a bigger problem as finding out the cleartext password for accessing ldap. Because of this it is very important to avoid access to the server and keep all code secure.

I have the same problem with sync replication in openldap. The consumer have to save a password for the replication user in ldap in a config file in cleartext.

First of all I use and recommend SSL encrypted communications between browser and drupal for the users and between drupal and the LDAP server. I don't use starttls and allow my ldapserver unencrypted communication only on localhost. Define in ldap.conf to proof the ssl certificate and so on.

The next thing is that I try to improve this situation with more ldap users for different things:
1. the authentication user (or user of auth group) in LDAP should have only the right to read the drupal user tree in LDAP. If all users in this tree are already synchronized with drupal mostly all data are in both system. So if anybody have access to the drupal database he don't need this password anymore I think.
2. the replication user can and have to read all he has to replicate. Because on the system where the cleartext password is saved in the config files for replication there are all data replicated he can read. So if somebody have access to the server where the replication is made he don't need the password anymore I think.
3. the ldapcontroller user (I use for provisioning) has only writing right in the drupal user tree of the LDAP database. With writing rights somebody can do destruction in the ldap database. So I think, this password is as important as the mysql password or the user/1 password.

Maybe there is a possibility I don't know, but I believe we could change the need to store something unencrypted. When I'm looking to the key of my office in my private room I think: If somebody breaks in this room, safe, bank ore something else he have access to my office, too.

Update:
Maybe we can increase the security by using a module like that: http://drupal.org/project/aes or try to copy its method because it's can make userpasswords less secure against the hashing concept. But I like the possibility
to store the AES key in the file system. So we don't save the cleartext LDAP password in database and spread it in its replication. I will test this way the next days because I am alwasy interested in more security.

johnbarclay’s picture

johnbarclay commented
Status: Active » Closed (won't fix)
kenorb’s picture

kenorb commented
Issue summary: View changes
Related issues: +#1968208: LDAP User: Allow for encrypting of the userPassword field with md5, sha, smd5 or ssha on a per-server basis