I think if you use a strong key with AES/Rijndael, you can use a machine datastore, or even just a secure file in your app directory. Or encrypted DB fields if you're using a DB. You can put the key in the machine cert store, or you can bury the key in your deployed binary.
That will protect you against 95%+ of curious/mildly malicious users. That other 5%, and otherwise more malicious users, are going to require a hugely disproportionate amount of effort and/or money to be invested if you intend to beat them. That group is going to include the hardcore sorts capable of starving CPUs in order to flip bits in private keys of RSA -- feel free to try to program around that sort of person, but you're wasting effort in a case like this, IM(H)O™. --ab On Thu, Apr 15, 2010 at 11:16 PM, Rich <richard.frain...@gmail.com> wrote: > I agree with the "obscure" comment. > > For better or worse, I am trying to design a solution for a semi- > public machine, so multiple users may be using the same application > installation, and each user has their own registry settings. (The > other registry settings are innocuous, but I am trying to trade off > user convenience with user security.) > > If I understand it correctly, the token secret is tied to a user- > external-application tuple. If so, then just having the token secret > would only allow a malicious 3rd-party to post a Twitter status using > the authorized application. Since we require the use authenticate to > Twitter at the start of each application session, I was hoping that > this would mitigate the risk of storing the token secret I the > registry. (Of course, I am also expecting the user of a semi-public > machine to close the application when they are finished…) > > Further thoughts? > > > On Apr 15, 7:53 am, Andrew Badera <and...@badera.us> wrote: >> The Windows Registry is NOT "secure" -- it is at best "obscure." >> >> Is it a good place to store information? Maybe. Matter of opinion. >> Consider a secured machine datastore as well. However anyone with >> physical access to the machine has everything they need to access >> anything they want, given a little patience and tech skill. >> >> Why do you need a "secure" location for a user token? It's just the >> user who has access, right? Or are you referring to your application's >> key, and not the user key? If so, there's really no good way to secure >> that with current iterations of OAuth. The mechanism is fallible for >> desktop apps. 2.0 may address some of that. >> >> ∞ Andy Badera >> ∞ +1 518-641-1280 Google Voice >> ∞ This email is: [ ] bloggable [x] ask first [ ] private >> ∞ Google me:http://www.google.com/search?q=andrew%20badera >> >> >> >> On Thu, Apr 15, 2010 at 10:43 AM, Rich <richard.frain...@gmail.com> wrote: >> > My question is similar to this post <http://groups.google.com/group/ >> > twitter-development-talk/browse_thread/thread/ >> > 5d37e76f8efed028/2052210d4cd2bcea?lnk=gst&q=token#2052210d4cd2bcea>. >> >> > I am using TweetSharp 1.0 with a WPF 3.0 C# application. >> >> > I request that the user allow the desktop application to update their >> > status at certain times in our application workflow. If the user >> > grants permission, I store the access token and access token secret in >> > the registry for use in future sessions. >> >> > I could encrypt the token secret before persisting in the registry, >> > and decrypt before using in my call to Twitter, but the encryption key >> > would still be in the desktop application. This seems a bit better >> > than not encrypting the token secret, but is the gain in security >> > significant? >> >> > -- >> > To unsubscribe, reply using "remove me" as the subject.- Hide quoted text - >> >> - Show quoted text - >
