I work for a hosting company and are about to design a rest api for a 3rd party so they can create Active Directory user accounts.

I also want this api to be async and robust enough to survice application pool recycling and reboot. In order to do that, I have to save state. For new user accounts, that would include the initial password, unless I can convince the 3rd party to accept callbacks or polling.

My design options are:

  1. Async fire-and-forget where I have to save the password for new accounts.
  2. Async with callback. New accounts can be created with a random password. 3rd party resets when the callback is received.
  3. Same as 2. but with polling.

I can't use the recommended password hash, because the objective is not to use it for later authentication, but to pass it on to Active Directory.

The api will be implemented CQRS style, hence the password cannot be part of any domain event. That would be the same as saving it.

Option 1: Store passwords temporary in a separate database and let it handle the encryption.

I will be using Sql Server, and I thought I could let that handle the encryption:

  • Save passords to encrypted database.
  • Save the id in the domain event.

When the user account is about to be created:

  • Read the password.
  • Create the account.
  • Delete the password from the database.

Option 2: Store passwords temporary in a separate database, but encrypt each entry with a different key.

The idea is that if the database is compromised, it would be harder to do anything useful with it because each password has a different key. Is this useful, or is it a variation of security by obscurity?

  • Create a random key
  • Encrypt the password
  • Save encrypted password to the database
  • Save key and id in the domain event.

Otherwise same as Option 1.


The password database should be almost empty during normal conditions. It's when something in the api's backend fails and new user account requests are piling up, things are getting risky. Initial passwords will stay in the database until problems are fixed.

New users must change password at first logon.


It's probably obvious I am not a security expert. Are these ideas just stupid? Are there any acceptable methods for storing passwords temporarily?

1 Answer 1


I agree with Francois. You say that you want it to be async. it's not clear that this is something the 3rd-party client is asking for. If it is something they want, the call-back approach with enforced reset on first login is preferable since they will at least know that the account if the account has been compromised when they attempt to login with the generated password. If they balk at that, you should make sure that they understand that they are asking you to disregard good security practice.

  • I was more concerned of how to store passwords securely, if it comes to that. I have two reasons to go async: 1. The client will experience faster response times. 2. It will protect them from temporary failures on our side. Commented Oct 6, 2015 at 17:41
  • If you have to do this, encrypt them and store the encrypted value on a separate system from where the key is stored. Do not store the user id at that location. On the other server store the salt and user name for each and a surrogate key (e.g. UUID) for the encrypted password. If you are really paranoid make it 3 places. That way, an attacker will need to compromise more than one system. Still not really a great practice from a security perspective. Convenience tends to be the enemy of security.
    – JimmyJames
    Commented Oct 6, 2015 at 20:23
  • Thank you! Agreed, not a good solution. Now I have well founded reasons not to do it, and a good enough fallback if I really have to. Commented Oct 6, 2015 at 21:19

You must log in to answer this question.

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