0

For some context, I want my api to be able to 'impersonate' (or connect as) a user on my ldap database as most of the api's access controls are on the ldap database and tied to the user you are connected as.

In order to do this I have an idea where I will generate a random password for each user. The random password will then be encrypted with a key only the api has access to. The encrypted string will then be stored under the user's entry. Now when the api wants to impersonate a user, it will get the encrypted string, decrypt it and then connect as that user.

How bad of an idea is this?

Improve this question
1
  • Backdoor users: bad. Normal encryption for password storage: very bad. Consider making api-exclusive accounts if you have to, or find another solution.
    – Pheric
    Jun 17, 2020 at 1:17

1 Answer 1

Reset to default
1

Is terrible, really terrible. Almost as terrible as storing the cleartext version of the passwords on a file named passwords.txt...

The first rule of storing passwords is that you never store passwords. You salt and hash them.

encrypted with a key only the API has access to

You cannot guarantee that. If the API can access, other entities can access it too. Anyone accessing the server as root can extract it. Anyone that have read access on the API application can extract it. Don't do that.

This is the shortest path to leaking every password on your database.

So, how do you impersonate any user?

You don't.

Create test users for each role, give them very strong passwords, and impersonate them instead.

You don't want to grant privileges to particular users, but you create groups, grant privileges to the groups, and connect the users to the groups.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .