Does this security scheme make sense?


#1

I’m building a site (in PHP) that talks to Twitter on behalf of my users, and, in dealing with the OAuth stuff, I’m trying to do a reasonable job of security around the tokens. I’m an admitted newbie at this, so I’d appreciate any comments on the adequacy of the approach I’m taking:

  • The users’ oauth_tokens and oauth_token_secrets are encrypted via mcrypt and RIJNDAEL-256, and stored in a database (mysql).

  • The encryption key for dealing with the tokens is kept in a file outside of webroot, and gets loaded when it’s needed for en/decryption.

  • I have also put into a file outside of webroot my app’s Twitter consumer key and consumer secret, and the oauth_token and oauth_token_secret for the user account associated with my Twitter application. I have not encrypted any of these, under the rationale that the encryption key is in the same place as these tokens, and there’s no point in locking a door if you’re leaving (have to leave?) the key right next to it. If a bad guy has gotten that far into my system, the game’s kinda over. (Or so I think.)

  • The database credentials are unencrypted and kept in yet another file outside of webroot.

Like I said, does this seem reasonable? I’m maybe especially concerned about leaving some things unencrypted; insight and wisdom about this or anything else are more than welcome (that’s the whole point of this post); thanks very much!


#2

If you’re required to be in compliance to some sort of data storage regulations, you’ll need to consult those regulations to figure out what their requirements are. If you’re just trying to do best by your users, that sounds reasonable, although the obvious target would appear to be the location that you’ve stored the encryption and consumer keys. I’m not sure that being outside of webroot helps in case you have a vulnerability in your app which allows reading from arbitrary disk locations, for example, so locking down permissions and the accounts which your web services run under would be another place to pay close attention.

I would say that if your OAuth token database were compromised, it would certainly not be as bad as losing a password database. You’re always able to regenerate your consumer credentials on dev.twitter.com, which will invalidate the access keys created with the compromised key, which is a huge benefit of using OAuth.


#3

Good comments; thanks very much.