How to support secure creation of a user account over an external API via a queued job?

Question

So this question is delving into security and encryption and the problem potentially hasn't been encountered by many. Answers may be theoretical. Let me outline the scenario...

1. A website frontend is driven via a backend API. The backend has an endpoint handling a generic registration form with username and password. It's using SSL.
2. The backend API handles registration via an async job queue. The queue does not return responses to the API server. It's a set and forget operation to queue up the registration.
3. Queued jobs are picked up by workers. The workers take care of creating the user account. These workers need access to the plaintext user password so that they can trigger a third-party API registration call with the password.

So the real crux of the problem is the syncing of the password to the third party API while not revealing it to prying eyes. The queue poses the problem of not having direct access to the plaintext password from global POST data anymore, meaning it needs to be stored in some fashion in the queue.

The queue can easily store the hashed password and copy it directly to the users table. This solution does not allow for syncing of the password with the third party API, however, as it's already encrypted. I toyed with two-way encryption, but am whole-heartedly concerned with leaving the password prone to decryption by an attacker.

Can anybody think of a secure way to handle this scenario of password syncing?

The queue is a requirement and it's assumed that this is readable by anyone with access to the server. The passwords don't necessarily have to be synced; the password for the third-party API could be a derivation of the original so long as there's a secure means to decrypt via the logged in user without supplying their password. This is essentially to simulate Single Sign-On with a third party API that does not support SSO.

Answer 1

This appears to break down to simply;

• I have a job queue containing plaintext passwords.
• I would like to prevent other server users from accessing those passwords.

This seems like it should be quite easy, assuming 'other server users' does not mean a superuser account.

What you need to do is engineer it so that your frontend <-> jobqueue link acts as a diode, jobs are able to go in, but no data can egress from the jobqueue in the direction of the front end.

Some simple examples;

• The job queue exists in a database to which the front-end does not have access. The data is encrypted under a key generated at run-time.
• The job queue exists only in RAM in a process marked as untracable (in Linux you will need AppArmor and I believe this is possible by removing the capability CAP_SYS_PTRACE)
• The job queue does not exist - make the back-end calls synchronous.

That said, doing anything other than immediately hashing plaintext passwords is antipattern imho.

Answer 2

You should use bcrypt to hash the password and discard the plaintext as soon as it hits your frontend's API server.

For the third-party API password, use a cryptographically secure pseudo-random number generator to make a long random password that you store in the user record. Depending on the sensitivity of this API, you may want to symmetrically encrypt the API password before storing it in the database. I'd suggest using Keyczar to manage the encryption if you want to encrypt the API passwords.

Answer 3

What I don't get is why you're propagating the same password to the third party API. That's not Single Sign On. That's Single Password Stupidity.

Instead hash their password and store it. Then generate a random password for the user, one per third party sign on. And sign on using that. That way, only the individual site passwords go into the queue.

---

Looking at your actual question: This is impossible. I assume the job queue and the backend API are on the same server. If you don't trust the queue's security, you can't really trust the backend security either. And you have to store the password somehow, somewhere in plaintext, or in a format from which your server can extract the plaintext password.

Answer 4

This answer is different from the earlier questions that suggest you should hash the password, store it in a database, etc. Those solutions are needlessly complex in my mind.

If you're front-ending the 3rd party API everywhere, then you can/should seed and hash the password yourself and simply send that hashed blob to the backend. One approach could look like this:

1. Hash the password with BCrypt / Scrypt with a salt

2. Send that hash to the back end as the user's password, and update it when the user changes their password.

3. Use the same hash solution for your authenticating webservers

In other words, don't send the 3rd party API a clear text password, send them a hash you create. Just be sure to re-create this hash format on each and every validating webserver or webservice.

Then when you proxy the authentication requests to the 3rd party API, take the HTTPS POSTed cleartext PW, hash/seed it, then send it off to the API for further validation.

This approach will prevent the casual observer of the queue from impersonating a user, and the salt will prevent a rainbow table from being created.

Answer 5

Wait, unless you have you kernel configured to allow root to view any memory in the system, why not just use pipe()? It's stored only in volitile memory, it is secure within the system, and supports both synchronous and asynchronous data transfer.

If the queue is just for connecting workers directly to the API, it seems like there would be no practical way to exploit the system.