2

I'm writing a Facebook canvas webapp that performs a login (using urllib) to a third party website and performs actions on behalf of the user. This means I have 2 accounts; the account the user has with my webapp (via facebook) and the account the app uses to perform a login on their behalf (with user/password details provided by the user).

I obviously don't want plaintext passwords in the DB. But I also don't want the user to have to enter their password every time they perform an action. I want them to enter the password once when they sign up, and I want to encrypt the passwords, but what do I encrypt against? Any key on the server would be available to anyone who had gained access (i.e. useless), so I was thinking of encrypting it against a value available via the Facebook API.

When the user logs in (and gives the app their access token), the app can request the value via the API and encrypt/decrypt their 3rd party password with this. Anyone with access to the server wouldn't be able to make this request without the user being logged in to the app. (This still means someone snooping on the server could get logged-in users 3rd party password, but anyone who got one-off access to the DB couldn't see passwords.) Is this wishful thinking?

Timmy O'Mahony
  • 53,000
  • 18
  • 155
  • 177
  • Does the third party site not provide OAuth access? Because that solves most of your problems... – Malcolm Box Apr 26 '11 at 14:21
  • Nope, there's no API at all, so that's why I have to use urllib to essentially screen scrape and perform login POSTS etc. – Timmy O'Mahony Apr 26 '11 at 14:25
  • Does this site put a cookie when you login ? You could use this mechanism, so they would only have to login again next time the cookie expires ? – dwarfy Apr 26 '11 at 15:39
  • it does but that would still require them to reenter their password on every visit which is something I would like to avoid – Timmy O'Mahony Apr 26 '11 at 15:44
  • Not really sure what your question is honestly. For dealing with a 3rd-party site with no API or OAuth support, it sounds like your plan is as sound as it can be. At least by encrypting with a token from Facebook, you're effectively making an insecure login component dependent on a relatively secure login component. – Chris Pratt May 03 '11 at 20:04

3 Answers3

4

You might as well encrypt it using a key on the server. If anyone gains access to your server they will have everything they need to retrieve the key even if you're getting it from Facebook.

I think the best you can do is to store the key in a location that isn't available to your webserver, but that is available to your script. At least make sure you don't store the key in the database.

Whatever you do beyond that would just be security through obscurity. The key here is to keep your server secure so that no one gains access to it.

Erik B
  • 40,889
  • 25
  • 119
  • 135
0

I guess you could store the logins ONLY on the client, in some sort of local storage and do all the actions related to the third party, from the client in JS.

This of course would need some change in the architecture of your app if you tought to do all this from your server, but that would possible for sure, you can event make client JS send data to your server after it worked so you can log data from the interactions with the 3rd party.

Furthermore it has the advantage of distributing the load on the clients

I know you didn't tag the question with javascript and you seem to want a server pure solution, but It seems the best solution to me. the user keeps its data ..

dwarfy
  • 3,076
  • 18
  • 22
0

Security through obscurity might be your best bet. Perhaps implement an algorithm to generate the key using something standard (like the current datetime). You can store the date in your db, and use that to generate the key using your own algorithm.

Gevious
  • 3,214
  • 3
  • 21
  • 42