You can't really encrypt it or anything, since as someone else pointed out, it eventually needs to be in plain text and therefore can be intercepted in the code. Plus, it's my understanding that many servers with PHP don't have OpenSSL extensions installed.
On Jun 2, 1:58 pm, Taylor Singletary <taylorsinglet...@twitter.com> wrote: > It really ends up just being a case of best-effort security. A desktop > application makes its best effort to keep the secrets concealed, obfuscated, > or stored. > > The last thing you want is for those with malicious intent to masquerade as > your application, giving it a bad name, and possibly getting it banned. You > want to make your best effort to make sure that doesn't happen -- especially > if you have access to privileged features with more risk like xAuth -- which > endangers not only your application but anyone who's made the mistake of > giving their login credentials to *any* third party. If I have a database of > 500 Twitter logins and passwords, and I come across a key/secret combo with > xAuth access, I can secure long-lived access tokens to act on their behalf > -- and your application will get all the infamy associated with that. > > If abuse is detected, you can always regenerate your API keys and secrets > and re-distribute your application. > > Security is a cat and mouse game. Sometimes the cat devises clever mouse > traps. But a clever mouse will always want to get its cheese. Storing > credentials in plain text in an open source project or otherwise lets even > the most lazy cats an opportunity to catch the mouse.. > > We recognize that there will never be absolute security in these things, and > the best we can do is offer you the best possible tools to deal with abuse > when it happens, and the best possible analytics to detect abuse. We aren't > all the way there yet, but we know what the score is. > > Not the quote you want to see here: "A strange game. The only winning move > is not to play. How about a nice game of chess?" > > Taylor > > > > On Wed, Jun 2, 2010 at 1:48 PM, Bernd Stramm <bernd.str...@gmail.com> wrote: > > On Wed, 2 Jun 2010 13:23:34 -0700 (PDT) > > Cameron Kaiser <spec...@floodgap.com> wrote: > > > > > We just updated our Twitter plugin for WordPress to use the new > > > > OAuth API. Someone just asked if it was safe to store the consumer > > > > key and consumer secret in plain text (which it basically has to be > > > > as I understand it, since ultimately it needs to be sent to the > > > > server in a plain text form). I can't really think of a way that > > > > would work for all end users to protect the two. Ultimately I > > > > guess this means that someone could pretend to be our application > > > > if they wanted? Anyone have any thoughts on this or any possible > > > > work arounds? > > > > Speaking from personal experience, Twitter will not allow you to have > > > your consumer secret in plain text in (visible form in) your code. > > > How do you propose people do that for desktop/mobile apps? You have to > > install the code on the user device, and that device at some point has > > to generate the consumer secret in clear text, so it can be signed. An > > intruder can examine the code and intercept the secret. > > > -- > > Bernd Stramm > > <bernd.str...@gmail.com>
