Thanks for the quick change. Nothing like real-time updates!
But I'll take you up on your querry:
We could use suggestions from desktop developers about the security
issues they've run into. Developers working in sufficiently high-
level languages shouldn't be dealing with buffer overflows and the
usual security issues. What have you defended against?
Off the top of my head, it seems like the two things I put the most
thought into were:
1. Storage of access keys (for OAUTH) or passwords (for basic auth).
Since an access key provides nearly as many rights as a username/
password pair, it has just as much power if it is acquired by an
untrusted 3rd party. In Mac OS X the "Keychain" is the home of data
that must be stored in an encrypted form and accessed through a secure
API. I'm not sure what AIR, Silverlight, or Windows devs are
conquering this subject. I imagine each platform has a set of best
practices. But it would probably be a good idea to at least mention
the gravity of secure storage of these things. Since OAuth keys are
new to a lot of us, I can see someone accidentally misunderstanding
this and storing them in a preference file unprotected.
2. Obfuscation of the application's registered "key" and "secret."
Are there any best practices? What about an open source project?
Isaiah
YourHead Software
supp...@yourhead.com
http://www.yourhead.com
On Jun 29, 2009, at 4:40 PM, Alex Payne wrote:
Apologies, these two sections were under the wrong heading.
On Mon, Jun 29, 2009 at 16:32, Support <supp...@yourhead.com> wrote:
Hi Alex,
I just thought I'd give you some feedback on the "Desktop
Application Security" section here:
http://apiwiki.twitter.com/Security-Best-Practices#DesktopApplicationSecurity
Both of the sections below seem to be subheadings under this topic:
1. Under this heading the sub-section of the document titled "Lack
of Rate Limiting" states that we should use a "CAPTCHA" to slow down
hackers. This didn't make much sense to me as when I think of
Desktop Application I think of the few that I've used:
Twitteriffic, Tweetie, and Destroy Twitter. All of those have
direct control of their UI. Although a CAPTCHA could be used to
limit scripted behaviors, it would probably be more effective just
to directly limit the resource.
It's not that a CAPTCHA *couldn't* be used, it's just not something
I see very often in a desktop application.
It seems to me that CAPTCHA would be more appropriate for a multi-
user service than a single user desktop app -- so I was wondering if
this section of the document was in the wrong area.
2. Under the sub-section Lack of Information about Threats, it
begins, "If you think there's an issue with your web application,
how do you find out for sure?" This is clearly at least a typo in
the *desktop* app section, but it goes on to describe creating a
"dashboard" of critical stats. Again, this would make more sense in
the context of service administrator, but I'm having trouble
understanding what this would mean to a desktop application developer.
Am I misunderstanding what is meant by "Desktop Application?" Does
that mean something other than the examples I mentioned?
Thanks,
Isaiah
YourHead Software
supp...@yourhead.com
http://www.yourhead.com
On Jun 29, 2009, at 3:34 PM, Alex Payne wrote:
I wanted to point out a blog post (http://apiblog.twitter.com/security-best-practices-for-twitter-apps
) that addresses the coming "Month of Twitter Bugs". Long story
short: Twitter is in the loop, we've got security at the forefront
of our daily work right now, and we're available to help if your
application is identified as vulnerable or compromised.
Please check out the new wiki page (http://apiwiki.twitter.com/Security-Best-Practices
) and let us know what's missing. Thanks!
--
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x
--
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x
