I'm building a web based, LDAP authenticated password manager for internal use.

We don't want to store the passwords in plain-text in the database, and we want multiple users to be able to access the data.

My question is, how can we protect the data, whilst allowing different users using different login credentials? The only thing that comes to mind is storing the encryption key as-is, and then using logic (i.e. is user a part of a specific group) to decide if the app should use it or not to decrypt the data. This of course isn't safe since anyone with access to the web server would be able to retrieve the key.

Does anyone know of a way to achieve security like this when using an external method of authentication?

1 Answer 1


For each data record (or set of records, if the same users can always access all records in a set), create a random encryption key. Then encrypt a copy of this key with the key of each user who is allowed to access the data.

(The user keys may be either derived directly from the user's password using a suitable key derivation function such as PBKDF2, or you can generate a random per-user key from each user and encrypt it with the password derived key. The latter option is a bit more complicated, but has the advantage that you only need to re-encrypt one key when a user changes their password.)

For more information, see e.g. this related question on crypto.SE.

Edit: I just noticed the mention of LDAP in your question. I'm not really very familiar with LDAP, but as far as I can tell, if your application is acting as an LDAP client, so that the user enters their password to your application, which then queries the LDAP server to validate it, then you can mostly do it as described above.

The one thing you're going to have problems with is password changes, unless you can somehow get the LDAP server to notify you about them and to include the old and new passwords in the notification. One option would be to have your app also check the entered password against its own database, e.g. by storing a hash of the user's encryption key (derived from the password with PBKDF2) in the database. If the password passes LDAP validation but fails this check, it means that the user has changed their password, in which case you need to ask them to also enter their old password so that you can re-encrypt the data.

However, the ideal solution would really be to store the encrypted data (or at least the per-user keys) on the LDAP server, if the server can be configured to do that securely. Based on some Googling, at least some of them can be.

You must log in to answer this question.