Using cookies to securely store encrypted third-party passwords in DB

Question

Obviously, storing third-party credentials of any kind is a major risk, and I'd like to avoid it as much as possible. However, I have an idea as to how it could be relatively safe and I'd like some opinions on this strategy:

1. MySite allows users to register with a username and password (or Facebook, whatever)!

2. If that user is also registered at site AllTheData.com (herein called ATD) with a username and password, they can give me those over HTTPS.

3. MySite receives the third-party credentials to ATD and does two things: creates a new crypto-key which it stores in the user's cookies, AND encrypts the username and password with that key and stores those encrypted values in the database.

AllTheData.com's Database might look like this:

| User               | Password              
| JohnDoe@gmail.com  | p4ssw0rd_hashed

MySite's database now looks like this:

| User               | Password               | ATD_username         |ATD_pass
| JohnDoe@gmail.com  | another_p4ssw0rd_hashed| ct5lHMGymedITfElVA...|BHJCS38DkG7Zg0...

And the user's browser has a cookie with the key:

MySite_key: E3iKZxk2ZDD4EUb*fH$X6Mz5BO^iQeOM&V$lB0WAk4&WAB#A4QB8Yn7

Now when I need to access the service I pull out the encrypted values from my database, and I pull out the cookie from their request, and I can access the server! And of course, if their cookie has expired or they've cleared them out or switched computers or anything else then I have to ask again : ( But it's worth it if it means I don't have to store credentials in plain!

Have I done anything terribly wrong here? Are there any obvious problems with this plan?

Thanks!

Answer 1

I agree with CBroe's comment. There are much better ways of interacting with a 3rd party than forcing your users to give up their precious credentials. I would suggest looking into something like OAuth . It allows your users a lot of great features:

• They only present their ATD credentials to ATD
• ATD can give them control over what data or actions your system can do for them. The user has the power to revoke your system's access at any time.
• Most of the big third parties that you would want to integrate with are already OAuth providers

---

Since you've stated that OAuth is not an option, I would try one more plan of attack before using your proposed solution. You have already admitted that your solution is pretty transient; once a user clears their cookies, you require them to log in again. If the service that you are calling creates a session on login, you could simply forward the users credentials to the third party and temporarily cache whatever token or session ID the service would normally return to users (I see no reason to store this in a database). You could then delete that token once your user logs out of your system. This keeps you from storing their credentials directly. It's not a great step up, but that's what I would pursue first.

If you combine this with your cookie encryption idea, I think you get a pretty good separation. You have the encrypted authentication token cached on the server, but it is only accessible to users that have the encryption key stored as a cookie. Like you say, that prevents your server from giving access to the third party if you are compromised. You don't really get any protection if your client is compromised, but I think that's unavoidable.

If the system requires credentials for every request, then I don't really see a better approach. You've done your homework and I don't see any better solution.

Answer 2

This is not too bad, although not the best way of allowing access to a 3rd party system.

Make sure that the MySite_key is generated by a cryptographically secure algorithm so that it cannot be predicted by an attacker, and protect this cookie the best you can. If there is any breach on your site, the cookie becomes very valuable to an attacker. Of course, how valuable depends on what data the user has access to in ATD.

That means implementing SSL/TLS on your site, enforcing the Secure Flag and HTTP Only Flag on the cookie and setting a HSTS policy . Also ensure that your site does not have any session fixation vulnerabilities - if one existed an attacker may be able to set their own encryption key for another user's account.

Make sure the encryption algorithm is also secure enough for your needs, such as AES-128 .

Also ensure that your communications with ATD are over SSL/TLS only. Again, using versions of the protocol and cipher suites that are considered secure and not vulnerable to any downgrade attacks (eg FREAK ).