Reversible password storage obfuscation method for third-party login credentials

Question

I have an internal business application, that as part of its functionality connects to a third-party app using login credentials specific to the user of my own app. These passwords are stored in a central database. Currently they are plain text (this was justified based on a high level of front-line security into our corporate LAN), but a recent attack against the network of our new parent company (luckily they didn't actually get in) has led me to take another hard look at that.

Passwords for the main internal app, we can bcrypt them with a salt, no problems there. The problem is ciphering the third-party application credentials. As we all know, users like to keep the same password for multiple apps, so no matter what I do to the internal app password for safekeeping, it won't make a lick of difference if the third-party credentials are sitting there in plaintext right next to it.

Here's the kicker; whatever method is used, it must be reversible within the application, because the #$%^&* third-party app requires transmission of plaintext credentials from the internal app's process to a SOAP service (luckily it does so over HTTPS), and the internal application allows users to maintain these stored third-party credentials (saving the Dev department the trouble of maintaining DB content). So, the best I can do is encryption, not hashing.

So, I realize that any method I employ here will be less than ideal; if the attacker gets both the application and the credentials, he'll get the plaintext passwords and there isn't much I can think of to prevent it. I'm just trying to make an attacker work just that little bit harder to get the credentials, hopefully giving me enough time to at least alert the third party so they can disable our logins, if not force every user in the system to change their third-party credentials before the attacker can crack one.

So, what do you suggest? AES (I can't imagine RSA being of much use as the application has to both encrypt and decrypt)? Any clever tricks for keeping the key out of the hands of someone who manages to get both the DB and the application binaries?

Answer 1

Let's suppose that in your app (let's call it App1), the user already has to enter some credentials C₁ (name and password) which App1 uses when it connects to your central database. Right now, your central database contains C₂ as cleartext, to be used when App1 connects to App2.

Let H() be a hash function with a large output, say SHA-512. When the user enters his password (C₁) in the interface of App1, App1 computes H(C₁) and obtains a 512-bit value, which it then splits into two 256-bit halves, P_l and P_r.

The credentials C₂ are symmetrically encrypted with a key derived from P_l. This derivation should be slow (like bcrypt or PBKDF2 or something equivalent); I suggest relying on an existing, well-audited format for the encryption details and the key derivation, e.g. OpenPGP. Let's call E(C₂) the encryption result.

Now let your central database store E(C₂) and bcrypt(P_r).

When the user enters C₁ in App1, App1 applies H() to obtain P_l and P_r. App1 then contacts the central database and sends P_r (within a SSL tunnel, of course). The central database applies bcrypt() on P_r to see if that matches the stored value; if yes, it sends E(C₂) back to the client. Then, App1 uses P_l to decrypt the blob and obtain C₂.

This way, the central database never obtains the decrypted C₂ at all; and C₂ are known to App1 only in a transient way (in RAM, not "hidden" in the code). What the central database knows is sufficient to test a password for validity, but slow hashing and salting is employed to counteract that issue (as part of E() for P_l, using bcrypt() for P_r).