存储密码以登录第三方API

Question

I am writing a trading application using Node & Express for the backend. Each user will have their own login for the application itself, but in order for it to be useful the application also needs to login to the user's brokerage account.

The brokerage account in question has a REST API in which you POST the login and password for that system. That API does not offer SSO or OAuth as an option for authentication. The only means to authenticate is POSTing the uid and password.

So there are two logins involved here: one to my application, and another completely separate login to the brokerage account. Each of those logins uses a different user ID and password.

The problem I'm having is figuring out how to store the password for the brokerage account. I understand that storing a password at all is a bad idea. But if all I store is a salted hash of the brokerage password, I wont be able to reverse that and get the actual password back. Hence, my application won't be able to login to the brokerage account unless the user enters that password again.

(As an aside, there is another program that does this. https://dough.com requires the user to login to dough, and then you also have to login to TD Ameritrade. That logging in twice is what I'm hoping to avoid.)

Is there a reasonable and secure way to store a password for this 3rd party API so that my app can login on the user's behalf without forcing the user to submit the password every time they use my app? I understand there are big security risks here. If the answer is no, then I won't.

Answer 1

Edit & Obligatory - Really the solution is to not do this. While technically possible, it will almost certainly not be implemented correctly & will expose your users' passwords.

Yes there is, but it's not incredibly easy & implementation is key. The JavaScript OpenPGPJS library is what you want.

In order for a somewhat secure system, your backend cannot be allowed to decrypt the password. This is where the JS library comes in, which provides PGP crypto via the browser.

You can base the PGP password off of the user password, or make them provide a new one for decryption. Alternatively, you can generate random keys for the password encryption then create a master key with access to the random ones - encrypting the master with the user input.

Whichever method you go with you will either need to have them enter the password in order to decrypt the record when needed, or add their password into their local session. The former is secure and the latter has obvious security implications.

Simple string encrypt using a password as provided by the examples:

var options, encrypted;

options = {
    data: 'Hello, World!',      // input as String
    passwords: ['secret stuff'] // multiple passwords possible
};

openpgp.encrypt(options).then(function(ciphertext) {
    encrypted = ciphertext.data; // '-----BEGIN PGP MESSAGE ... END PGP MESSAGE-----'
});

Decrypt:

options = {
    message: openpgp.message.readArmored(encrypted), // parse armored message
    password: 'secret stuff'                         // decrypt with password
};

openpgp.decrypt(options).then(function(plaintext) {
    return plaintext.data; // 'Hello, World!'
});

Answer 2

I think you have a few options, and the decision you choose should depend on the risk you want to take. If it is financial data as you hinted, I think the decision should clearly be not doing any of this.

One option is to store the 3rd party API password encrypted on your server with a key derived from the user's local password. As you don't store your user's local password, you can only decrypt the 3rd party API password upon user logon when you have his local one, and from there if you want to make future calls to the API impersonating the user, you will have to keep the plaintext version of the 3rd party password in server memory (the user's session). I think that while in some applications this could probably be a viable option, for financial data this is unacceptable.

Another thing you could do is encrypt the 3rd party API password in Javascript as Dave Lasley described in his answer. While that could work, it adds a lot of complexity, and as he also pointed out, implementation would be key. It would be hard to get this right and maintain over time without introducing vulnerabilities. Also Javascript crypto has its problems, the best practice is to not do cryptography in Javascript. You would have to keep the 3rd party API password in Javascript memory, which is a very weak control, any single XSS would be able to steal it from there (any other browser store is even worse than a Javascript object in memory). Also the 3rd party API would need to support CORS from your domain (or * obviously).

My take is that pretty much the only good way to do this would be a careful implementation with OAuth2. If the API doesn't support that, then you should not do this at all unfortunately.