WordPress plugin

[Duane Storey]

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?

[Cameron Kaiser]

Speaking from personal experience, Twitter will not allow you to have
your consumer secret in plain text in (visible form in) your code.

I am working with Raffi and Taylor on a solution for this with scripted
apps where such a secret must be handled securely.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- All I ask is a chance to prove money can't make me happy. ------------------

[Bernd Stramm]

On Wed, 2 Jun 2010 13:23:34 -0700 (PDT)
Cameron Kaiser <spe...@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....@gmail.com>

[Taylor Singletary]

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

[Duane Storey]

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:

> > <bernd.str...@gmail.com>

[Cameron Kaiser]

> > > 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.

Without jumping the gun too much on Raffi, for this particular class of apps
the application secret must be generated for each instance. The trick is
doing this without inconveniencing users or forcing them to "become
developers". Streamlining this process is what we're working out.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- PRIVACY. IT'S EVERYONE'S BUSINESS. -- Evil, Inc. ---------------------------