Re: [twitter-dev] WordPress plugin

2010-06-02 Thread 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 * ckai...@floodgap.com
-- PRIVACY. IT'S EVERYONE'S BUSINESS. -- Evil, Inc. ---


Re: [twitter-dev] WordPress plugin

2010-06-02 Thread 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

On Wed, Jun 2, 2010 at 1:48 PM, Bernd Stramm  wrote:

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


Re: [twitter-dev] WordPress plugin

2010-06-02 Thread Bernd Stramm
On Wed, 2 Jun 2010 13:23:34 -0700 (PDT)
Cameron Kaiser  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




Re: [twitter-dev] WordPress plugin

2010-06-02 Thread 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.

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 * ckai...@floodgap.com
-- All I ask is a chance to prove money can't make me happy. --