2

I'm attempting to throw together a pretty quick mash-up that I think would be useful for folks, and I'd like to make use of Twitter communication. This is my first experience with OAuth, and I've chosen the Twitterizer library to get the job done.

My question comes from the fact that I don't plan on storing user information or having users create accounts (it's meant to be more of a quick utility). Given this, once I get the user's OAuth access token and secret, I have to figure out a secure way of storing them (likely locally) without compromising the security principles of OAuth.

Here's what I'm thinking so far:

  • User goes through the process, up until I have their access key and secret
  • I encrypt the values and store in a cookie to retrieve later

However, a few questions / concerns:

  • What (if anything) prevents someone from impersonating a user via the cookie?
  • What is the correct way to deal with potentially multiple users on the same browser? My initial thought is a "logout" button on my app that would kill the cookie, but I'm not sure.

Thanks in advance for any help you can give!

SeanKilleen
  • 8,809
  • 17
  • 80
  • 133
  • How to you plan to retrieve the access key and secret values that you hash? Do you mean encrypt them and store them encrypted in a cookie? – userx Aug 14 '11 at 19:53
  • Yes, correct -- thank you! I'll clarify. – SeanKilleen Aug 14 '11 at 19:57
  • While it's good that you've given plenty of context, people should understand that you're asking very broad questions: How best can I store sensitive information in a cookie? Is it a good idea? – Ricky Smith Aug 16 '11 at 01:01

2 Answers2

0

I do not know much about OAuth since I don't use it, but one way you could handle multiple users on one browser is to use some kind of timer function. Each time the user connect's to your page the cookie get's a "Valid until" timestamp wich is now+30 minutes for example. If the valid until time is passed the application will ask the user to re-authenticate themselves.

You could even do this by setting a very-short timestamp on page unload and then set a longer on pageload. This will mean that if the user goes from one page to another within your app they will have a long time-out, but if they leaves your app the next user could use the same browser within a minute or so without the previous user logged in.

A more secure way could be to to use sessions. You could set a cookie that holds a session ID for example and then set the "valid until" values in the session.

Be aware however that these methods are definitely not foolprof since the cookies can be manipulated, the timestamp changed and sessions highjacked.

Lobo
  • 566
  • 1
  • 7
  • 20
  • Hi Lobo -- thanks for the response! I think, however, that the goal is to avoid having users have to re-authorize my app to tweet on their behalf every time they use it, as this has become a non-standard behavior (since most sites authorize once and store in a user database). I think timers might be overkill for what I'm doing, but I'll examine the session option in more detail, as this would be better for use in a public setting. Maybe re-authorizing once a session wouldn't be so bad.. – SeanKilleen Aug 14 '11 at 23:20
0

I think on the whole, cookies shouldn't be relied on for sensitive information, but, security is always a balancing act. Ultimately, you're trying to obscure the information you are storing insecurely.

In addition to encrypting the token, you could also include a checksum. I'd keep it in a separate cookie. It needs only to be some value that your site can use to verify the integrity of the sensitive data, to ensure it wasn't tampered with. It could be a one-way encrypted hash or something like that.

You can also specify an expiration date on the cookie. Perhaps keep it to a few days, or weeks.

I'll say this again, generally storing sensitive information in a cookie is a bad idea.

Ricky Smith
  • 2,379
  • 1
  • 13
  • 29