I'm trying to featurize my LDAP settings so I don't repeat the same settings over and over and noticed that when I store the LDAP bind password and encrypt it using the Blowfish algorithm, the salt is different for each server. Should this be a setting that is exported (via Features module) along with the "LDAP Authentication" dependency or would this be a security concern?

Comments

johnbarclay’s picture

johnbarclay commented
Category: feature » bug

Because of the nature of exportables and automated drupal builds, everything needed to recreate a configuration should be in the exportables. I'ts unclear to me how exporting the salt will help. I'm marking this as a bug, since its an incompletely implemented bug.

Are you using 7.x-1.0-dev?

johnbarclay’s picture

johnbarclay commented
Version: 7.x-1.0-unstable6 » 7.x-1.x-dev
humansky’s picture

humansky commented

We are currently using Active Directory for authentication. AD doesn't allow anonymous binds, so I have a service account I use to bind to AD. I don't want to store a clear password in the database or in the feature, so I used blowfish to encrypt the password. However, storing the salt along with the hashed password is just as bad (I think) as storing the password in the clear. I guess I just wanted to see if there is a better way to automate deployment from dev to prod without manual intervention. I'm using 7.x-1.0-beta5, but I've tested with -dev version as well.

johnbarclay’s picture

johnbarclay commented

Since its 2 way encryption, you can't win. Both have to be available to the php bind process to reveal an unencrypted password to LDAP.

Some ways of tightening things up are using low privilege service account and restricting the service account's access to ldap by ip address. My feeling is everything else is just obfuscation because if someone can get into your php filespace you are out of luck; they can then access the db and php layer. If they only gain access to your database, its good if the salt and encrypted password aren't in it; exportables helps here by moving it into the code/filespace.

I'm willing to implement any suggestions in this area even if its just obfuscation; security is important as well as the illusion of it.

I stash constants and other server local data in the directory above root. And have settings.php just include the file. That way my builds are the same for prod and dev below root and I can make some drupal variables unalterable by site users.

aegir does something where it sticks the db password in the server environment variables so its not available in the filespace or php except as an environment variable. this helps in the case where someone gains read access to the filespace, but is not able to execute any php. this could be another approach with these 2 variables.

johnbarclay’s picture

johnbarclay commented
Category: bug » feature
johnbarclay’s picture

johnbarclay commented
Status: Active » Fixed

Salt is not part of this module, but the encypted service account password does support exportables.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

johnbarclay’s picture

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

This was not fixed before, because the install was generating the variable. It is fixed now in 7.x-2.x-dev. See http://drupalcode.org/project/ldap.git/commitdiff/4528533fece804190c5543...

johnbarclay’s picture

johnbarclay commented
Assigned: johnbarclay » Unassigned

This was not fixed before, because the install was generating the variable. It is fixed now in 7.x-2.x-dev. See http://drupalcode.org/project/ldap.git/commitdiff/4528533fece804190c5543...

mallezie’s picture

mallezie
Primary language Dutch
Location Loenhout
commented

Perhaps an idea is to remove the password from the export (perhaps only when encrypted with blowfish) and make it possible to define it in the settings.php file. This also solves the problem when you have your features in a 'pubic' git repository.
Just an idea.

humansky’s picture

humansky commented

Good idea, but I think this can be done already. Since the option is stored in the "variables" table, can you add this to your settings.php file:

# Whether to encrypt LDAP bind password
# 6 equals 'blowfish' encryption and '10' equals no encryption
$conf['ldap_servers_encryption'] = "6";

Would this work? Haven't tested yet.

mallezie’s picture

mallezie
Primary language Dutch
Location Loenhout
commented

I'll give it a try. Actually i'm thinking it would be better to remove it completely from the features export (since that's stored in git for example), and then add
$conf['ldap_servers_encryption'] = "6";
and something like
$conf['ldap_servers_bind_password'] = "YOURPASSWORD";
to your settings.php, since that file isn't in git, and seperate for each site (dev staging live)