The anonymous bind password is currently stored in the ldapauth database table in unencrypted form, representing a security risk to site admins' LDAP directories. @miglius had asked what type of auth and where the password should be stored. I don't know enough about Drupal password security to answer the first question, though I would expect bind password security to be at least as good as user password security. If necessary, I would accept ldapauth writing an encryption key to a private data directory. I just don't want the password stored in plain text. As for the second question, I think it would be fine to store the encrypted password in the database.

Many thanks for your work on this project.

Comments

miglius’s picture

miglius commented

The problem is that to authenticate against the LDAP server a plain text password is needed. One cannot authenticate against LDAP server with a MD5 or similar password hash. If the password would be stored encrypted in the database, how can it then be decrypted before authentication with LDAP? Using encryption keys? But the keys would also be stored in the database which would not strengthen the security.

Any ideas are welcome.

kassissieh’s picture

kassissieh commented

The ubercart project writes an encryption key to a user-specified directory outside the public html directory. See http://drupal.org/node/268041. If encrypting the anonymous bind password were made optional, then those with access to private directories on the server could take advantage of this option.

Another option is to store an encryption key in the database. While not as secure as a private file-based key, it would provide one hurdle to overcome to access this password, whereas currently we have none.

miglius’s picture

miglius commented

I don't think that additional hurdle like storing the key in the database can stronger the overall security. Since the code is open and publicly available, it is just a matter of several minutes until one looks at the code and finds where the key is stored. This would not make it any more secure.

Storing the key in the file might add a little security since then if the db is compromised, the file is not. But the misconfiguration of this setup (leaving the file accessible from the web) would be even worse.

kassissieh’s picture

kassissieh commented

If the module creates a random key and then stores it in the database, then the fact that the source code is public would not help someone gain access.

Sure, misconfiguration could lead to a problem, but at least the burden of security will rest on the site admin, not the module developers.

Regardless, it's better than storing a password in clear text. At least the admin page should make this fact clear.

Am I the only one who has requested this feature?

cgmonroe’s picture

cgmonroe commented
Status: Active » Closed (duplicate)

Marking as duplicate of #923338: Password stored in clear text