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:
- Async fire-and-forget where I have to save the password for new accounts.
- Async with callback. New accounts can be created with a random password. 3rd party resets when the callback is received.
- 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?