[twitter-dev] WordPress plugin
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?
Re: [twitter-dev] WordPress plugin
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. --
Re: [twitter-dev] WordPress plugin
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
Re: [twitter-dev] WordPress plugin
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
Re: [twitter-dev] WordPress plugin
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. ---
