We're on the verge of a full boycott by users on apps that take passwords. Comments like this on ChrisBrogan.com keep me up at night. There's a groundswell happening, and it doesn't look pretty. I know Twitter is working on something, I just really hope it's soon.
---------- Forwarded message ---------- From: chrisbrogan.com <b...@chrisbrogan.com> Date: Sun, Jan 4, 2009 at 10:29 PM Subject: [chrisbrogan.com] New Comment On: Log Into Twitter And Change Your
On Mon, Jan 5, 2009 at 12:39 AM, Jesse Stay <jesses...@gmail.com> wrote: > We're on the verge of a full boycott by users on apps that take passwords. > Comments like this on ChrisBrogan.com keep me up at night. There's a > groundswell happening, and it doesn't look pretty. I know Twitter is working > on something, I just really hope it's soon.
> --Jesse
> ---------- Forwarded message ---------- > From: chrisbrogan.com <b...@chrisbrogan.com> > Date: Sun, Jan 4, 2009 at 10:29 PM > Subject: [chrisbrogan.com] New Comment On: Log Into Twitter And Change > Your Password > To: je...@staynalive.com
On Sun, Jan 4, 2009 at 11:39 PM, Jesse Stay <jesses...@gmail.com> wrote: > We're on the verge of a full boycott by users on apps that take passwords. > Comments like this on ChrisBrogan.com keep me up at night. There's a > groundswell happening, and it doesn't look pretty. I know Twitter is working > on something, I just really hope it's soon.
Honestly, most people (rightly or wrongly, i suspect rightly) don't really worry about it that much. I don't really think a boycott is likely to be effective.
Also, the chrisbrogan.com post confuses phishing with risk of giving an evil service your password. They aren't really the same thing.
For example, oauth type systems are generally considered to raise the risk of phishing happening (because they involve jumping the user all over the place to different sites) while at the same time (if implemented well) they can reduce the impact of a successful phish (by giving the user and the service more tools to control usage) They're also substantially more difficult to implement perfectly, raising the risk of code vulnerabilities.
Lots of tradeoffs well worth discussing (it's certainly a teaching moment) but the level of run-in-circles-scream-and-shout is getting to the point of being unhelpful.
I've been lurking on this list for a while. It's a nice resource for Twitter development. I'm currently working on my own desktop Twitter app. However I have apparently missed something on this list.
What exactly is wrong with an application (for Mac OS X in this case) asking for a user's Twitter user name and password. Storing the password in the OS X Keychain isn't hard at all and it is encrypted.
Have I really missed something important? Does this "fever" about apps asking for passwords apply to desktop and web apps, or just web apps? I'd really like to know whether or not my application would suddenly become "evil" because it asked for an account password. And yes, my app does inform the user that the password will be stored in the Keychain and it uses HTTPS when talking to the Twitter servers.
Reply on list or off list, which ever works best for you.
Dale
On Jan 4, 2009, at 11:59 PM, Christopher St John wrote:
> On Sun, Jan 4, 2009 at 11:39 PM, Jesse Stay <jesses...@gmail.com> > wrote: >> We're on the verge of a full boycott by users on apps that take >> passwords. >> Comments like this on ChrisBrogan.com keep me up at night. There's a >> groundswell happening, and it doesn't look pretty. I know Twitter >> is working >> on something, I just really hope it's soon.
> Honestly, most people (rightly or wrongly, i suspect rightly) > don't really worry about it that much. I don't really think a > boycott is likely to be effective.
> Also, the chrisbrogan.com post confuses phishing with risk of > giving an evil service your password. They aren't really the same > thing.
> For example, oauth type systems are generally considered to > raise the risk of phishing happening (because they involve > jumping the user all over the place to different sites) while at > the same time (if implemented well) they can reduce the impact > of a successful phish (by giving the user and the service more > tools to control usage) They're also substantially more difficult to > implement perfectly, raising the risk of code vulnerabilities.
> Lots of tradeoffs well worth discussing (it's certainly a teaching > moment) but the level of run-in-circles-scream-and-shout is getting > to the point of being unhelpful.
> I've been lurking on this list for a while. It's a nice resource for > Twitter development. I'm currently working on my own desktop Twitter > app. However I have apparently missed something on this list.
> What exactly is wrong with an application (for Mac OS X in this case) > asking for a user's Twitter user name and password. Storing the > password in the OS X Keychain isn't hard at all and it is encrypted.
Ed and I were sort of making that argument earlier.
> Have I really missed something important? Does this "fever" about > apps asking for passwords apply to desktop and web apps, or just web > apps? I'd really like to know whether or not my application would > suddenly become "evil" because it asked for an account password. And > yes, my app does inform the user that the password will be stored in > the Keychain and it uses HTTPS when talking to the Twitter servers.
In my opinion (I don't work for twitter or speak for them), I think 3rd party webapps have the most to gain from going OAuth, and desktop apps probably have the least. This is why I'm hoping Basic Auth will persist, even if in a limited or deprecated sense. It's not much good to make a desktop app walk the OAuth workflow because frankly an evil client application can do many more usefully evil things than simply being naughty with an OAuth token, and in some situations might make it impossible for that app to operate in a useful sense. (Think of all the little Twitter bots that are basically curl and a shell script, but still do useful monitoring work.)
However, it *is* much more useful to make a 3rd party standalone web app do it, and that's why Twitter is going to offer it.
-- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- We shoulda bought a squirrel. -- "Rat Race" --------------------------------
If you're storing the password securely and only using HTTPS, I'd say you're doing right by your users. In the absence of OAuth, that's basically best practice. It's also a pattern that's been deemed adequate by companies like Amazon, who collect and store financial information from their customers.
Christopher St John's comments above accurately reflect my own concerns. OAuth is not a security magic bullet, and it only encourages phishing attacks. I feel bad for users that have given their credentials to a phishing site, and we'll do everything we can to educate them, but token-based authentication systems are not going to fix this particular security problem.
Getting worked up into hysterics about boycotts is just, as security expert Bruce Schenier is fond of saying, "security theater". It's the equivalent of an apartment building's tenants telling their landlord they refuse to use keys because someone's place got broken into.
On Sun, Jan 4, 2009 at 22:07, Dale Merrick <theunstable...@gmail.com> wrote:
> I've been lurking on this list for a while. It's a nice resource for > Twitter development. I'm currently working on my own desktop Twitter app. > However I have apparently missed something on this list.
> What exactly is wrong with an application (for Mac OS X in this case) asking > for a user's Twitter user name and password. Storing the password in the OS > X Keychain isn't hard at all and it is encrypted.
> Have I really missed something important? Does this "fever" about apps > asking for passwords apply to desktop and web apps, or just web apps? I'd > really like to know whether or not my application would suddenly become > "evil" because it asked for an account password. And yes, my app does > inform the user that the password will be stored in the Keychain and it uses > HTTPS when talking to the Twitter servers.
> Reply on list or off list, which ever works best for you.
> Dale
> On Jan 4, 2009, at 11:59 PM, Christopher St John wrote:
>> On Sun, Jan 4, 2009 at 11:39 PM, Jesse Stay <jesses...@gmail.com> wrote:
>>> We're on the verge of a full boycott by users on apps that take >>> passwords. >>> Comments like this on ChrisBrogan.com keep me up at night. There's a >>> groundswell happening, and it doesn't look pretty. I know Twitter is >>> working >>> on something, I just really hope it's soon.
>> Honestly, most people (rightly or wrongly, i suspect rightly) >> don't really worry about it that much. I don't really think a >> boycott is likely to be effective.
>> Also, the chrisbrogan.com post confuses phishing with risk of >> giving an evil service your password. They aren't really the same >> thing.
>> For example, oauth type systems are generally considered to >> raise the risk of phishing happening (because they involve >> jumping the user all over the place to different sites) while at >> the same time (if implemented well) they can reduce the impact >> of a successful phish (by giving the user and the service more >> tools to control usage) They're also substantially more difficult to >> implement perfectly, raising the risk of code vulnerabilities.
>> Lots of tradeoffs well worth discussing (it's certainly a teaching >> moment) but the level of run-in-circles-scream-and-shout is getting >> to the point of being unhelpful.
On Mon, Jan 5, 2009 at 12:07 AM, Dale Merrick <theunstable...@gmail.com> wrote:
> What exactly is wrong with an application (for Mac OS X in this case) asking > for a user's Twitter user name and password.
Because your app could be evil[1], and, right now, a Twitter password is a non-expiring full-access read/write token. And somebody could tweet something evil while masquerading as you. Of course, you can always just change your password, but that's inconvenient. And there's a chance you use the same password for Twitter and your bank account.
> Have I really missed something important? Does this "fever" about apps > asking for passwords apply to desktop and web apps, or just web apps?
Logically, it's just as risky to give your password to an evil desktop app as it is to an evil web app (since the desktop app can always transmit the password to a remote server) However, most of the discussion has been about web apps.
> And yes, my app does > inform the user that the password will be stored in the Keychain and it uses > HTTPS when talking to the Twitter servers.
To be fair, an evil app could just as easily say (and even do) that.
Cameron, Alex: Thanks for responding. I just wanted to make sure I hadn't missed some major technical issue. I see that I haven't. I do agree with Alex in regards to the "security theater" comments he made. It doesn't appear that OAuth will make things any better, even if all Twitter apps are required to support it.
Christopher,
I agree with your points. As someone else on the list asked, what is the solution to this issue? It doesn't really seem to be a technical issue at all, but rather a trust issue.
Unless I have missed something you need the users password to post an update to their personal timeline. If the application doesn't ask for this information then how will their timeline get updated? Perhaps someone has already provided that answer. I'll dig through the archives tomorrow.
And with it being a trust issue you can extend that to a multitude of things in terms of computer applications (desktop and web based). Actually the real issue is the reputation of the entity that wrote the application. It all comes down to public relations.
For my own self, or rather for my application, I feel pretty comfortable asking users to enter their user name and password combo. Can I prove I won't be doing anything evil with it? Yes, if I release the source code (which is currently under consideration). If I don't though then obviously I can't prove I'm not doing bad things with it.
Don't you just love moral dilemmas brought up by technology? :D
Thanks to all three of you for providing answers that were free of scare mongering.
Dale
On Jan 5, 2009, at 12:28 AM, Christopher St John wrote:
> On Mon, Jan 5, 2009 at 12:07 AM, Dale Merrick <theunstable...@gmail.com > > wrote:
>> What exactly is wrong with an application (for Mac OS X in this >> case) asking >> for a user's Twitter user name and password.
> Because your app could be evil[1], and, right now, a Twitter password > is a non-expiring full-access read/write token. And somebody could > tweet something evil while masquerading as you. Of course, you > can always just change your password, but that's inconvenient. And > there's a chance you use the same password for Twitter and > your bank account.
>> Have I really missed something important? Does this "fever" about >> apps >> asking for passwords apply to desktop and web apps, or just web apps?
> Logically, it's just as risky to give your password to an evil desktop > app as it is to an evil web app (since the desktop app can always > transmit the password to a remote server) However, most of the > discussion has been about web apps.
>> And yes, my app does >> inform the user that the password will be stored in the Keychain >> and it uses >> HTTPS when talking to the Twitter servers.
> To be fair, an evil app could just as easily say (and even do) > that.
On Sun, Jan 4, 2009 at 11:20 PM, Alex Payne <a...@twitter.com> wrote:
> Getting worked up into hysterics about boycotts is just, as security > expert Bruce Schenier is fond of saying, "security theater". It's the > equivalent of an apartment building's tenants telling their landlord > they refuse to use keys because someone's place got broken into.
Alex, sorry, but this is more than just security - this is getting ready to put a whole lot of businesses out of business, thanks to the lack of such a mechanism. Regardless of whether it's the solution or not (I still argue it would have helped), if users boycott, our apps don't get used. If our apps stop getting used, Twitter stops getting used. There are entire groups of users out there right now asking what apps could be the culprit. I've heard some mention my app. I've heard others mention TweetDeck. I've heard some mention Twhirl. All these apps, whether they have any chance of being the culprit (I realize they don't, but your users don't have any way of knowing - all these apps collected their passwords), all have the chance of getting cut off of Twitter here real soon by the users if something isn't done. Didn't you guys say at one point the majority of your traffic comes from the API? This is more than just not using keys - this is about telling the landlord you won't pay them for the month because they refuse to install locks.
This issue is huge for us as developers, and I don't sense that urgency from Twitter.
I wholeheartedly agree with Jesse. IF users spread misinformation
about 3rd party apps that request passwords ALL being evil then we are
all in the same sinking boat.
Oauth is one part of the solution enabling serivce authentication. It
made me wonder will twitter also add in support for openid for better
user authentication? Better still will twitter offer a "Twitter
Connect" service like Facebook Connect an Google Friend Connect? As a
3rd party developer we could support Twitter Connect to authenticate
the user and then use Oauth for the service(s).
Personally I would like to offer my users the option to authenticate
with their preferred ID service - see http://www.janrain.com/products/rpx - and then use oauth to request access to their services. The one
thing that prevents me using RPX or creating my own version of the
service is the lack of twitter support for openid.
Scenario: User logins in via Google Friend Connect to our service. I
now have an authenticated user but how do I associate them to their
twitter account? Today I would still need them to give me their
username/password but when/if oauth via twitter existed I could
request authorisation to their twitter account and any other services
they use that supports oauth.
On Jan 5, 8:32 am, "Jesse Stay" <jesses...@gmail.com> wrote:
> On Sun, Jan 4, 2009 at 11:20 PM, Alex Payne <a...@twitter.com> wrote:
> > Getting worked up into hysterics about boycotts is just, as security
> > expert Bruce Schenier is fond of saying, "security theater". It's the
> > equivalent of an apartment building's tenants telling their landlord
> > they refuse to use keys because someone's place got broken into.
> Alex, sorry, but this is more than just security - this is getting ready to
> put a whole lot of businesses out of business, thanks to the lack of such a
> mechanism. Regardless of whether it's the solution or not (I still argue it
> would have helped), if users boycott, our apps don't get used. If our apps
> stop getting used, Twitter stops getting used. There are entire groups of
> users out there right now asking what apps could be the culprit. I've heard
> some mention my app. I've heard others mention TweetDeck. I've heard some
> mention Twhirl. All these apps, whether they have any chance of being the
> culprit (I realize they don't, but your users don't have any way of knowing
> - all these apps collected their passwords), all have the chance of getting
> cut off of Twitter here real soon by the users if something isn't done.
> Didn't you guys say at one point the majority of your traffic comes from the
> API? This is more than just not using keys - this is about telling the
> landlord you won't pay them for the month because they refuse to install
> locks.
> This issue is huge for us as developers, and I don't sense that urgency from
> Twitter.
Alex Payne wrote: > Getting worked up into hysterics about boycotts is just, as security > expert Bruce Schenier is fond of saying, "security theater". It's the > equivalent of an apartment building's tenants telling their landlord > they refuse to use keys because someone's place got broken into.
Ah, but what people _should_ refuse to do is give out copies of their keys to those who are essentially complete strangers just to water their houseplants or feed their cat while on vacation.
You should only give your key to someone trusted who then acts on behalf of the stranger to let them in, watch them water the plants or feed the cat, then ensure they exit your apartment without doing anything else.
Yes, tenants should tell their landlord that having to give out a copy of their key is not acceptable, especially when the break-ins occured using a copied key that was handed out.
Still, why do we care? It's just a Twitter account being compromised - what, do you exchange trade secrets in DMs that you wouldn't want someone else to read? Hint: Twitter isn't a confidential and secure messaging transport. Don't try to pretend it is.
-- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
Twitblogs wrote: > I wholeheartedly agree with Jesse. IF users spread misinformation > about 3rd party apps that request passwords ALL being evil then we are > all in the same sinking boat.
You say this like it's a bad thing. If we want to see a solution from Twitter, there has to be a real business reason for them to fund it.
What better business reason than "our API traffic dropped by 80% in one month and has remained at that low level for the past three months."
Let the panic continue. Either we'll see a workable solution to the problem, or folks will just stop using the API - either way, we'll finally have some clarity on the situation.
-- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
> I wholeheartedly agree with Jesse. IF users spread misinformation > about 3rd party apps that request passwords ALL being evil then we are > all in the same sinking boat.
> Oauth is one part of the solution enabling serivce authentication. It > made me wonder will twitter also add in support for openid for better > user authentication? Better still will twitter offer a "Twitter > Connect" service like Facebook Connect an Google Friend Connect? As a > 3rd party developer we could support Twitter Connect to authenticate > the user and then use Oauth for the service(s).
> Personally I would like to offer my users the option to authenticate > with their preferred ID service - see http://www.janrain.com/products/rpx > - and then use oauth to request access to their services. The one > thing that prevents me using RPX or creating my own version of the > service is the lack of twitter support for openid.
> Scenario: User logins in via Google Friend Connect to our service. I > now have an authenticated user but how do I associate them to their > twitter account? Today I would still need them to give me their > username/password but when/if oauth via twitter existed I could > request authorisation to their twitter account and any other services > they use that supports oauth.
> On Jan 5, 8:32 am, "Jesse Stay" <jesses...@gmail.com> wrote: >> On Sun, Jan 4, 2009 at 11:20 PM, Alex Payne <a...@twitter.com> wrote:
>>> Getting worked up into hysterics about boycotts is just, as security >>> expert Bruce Schenier is fond of saying, "security theater". It's >>> the >>> equivalent of an apartment building's tenants telling their landlord >>> they refuse to use keys because someone's place got broken into.
>> Alex, sorry, but this is more than just security - this is getting >> ready to >> put a whole lot of businesses out of business, thanks to the lack >> of such a >> mechanism. Regardless of whether it's the solution or not (I still >> argue it >> would have helped), if users boycott, our apps don't get used. If >> our apps >> stop getting used, Twitter stops getting used. There are entire >> groups of >> users out there right now asking what apps could be the culprit. >> I've heard >> some mention my app. I've heard others mention TweetDeck. I've >> heard some >> mention Twhirl. All these apps, whether they have any chance of >> being the >> culprit (I realize they don't, but your users don't have any way of >> knowing >> - all these apps collected their passwords), all have the chance of >> getting >> cut off of Twitter here real soon by the users if something isn't >> done. >> Didn't you guys say at one point the majority of your traffic comes >> from the >> API? This is more than just not using keys - this is about telling >> the >> landlord you won't pay them for the month because they refuse to >> install >> locks.
>> This issue is huge for us as developers, and I don't sense that >> urgency from >> Twitter.
Cameron's comment shows why a system like Oauth is important: Making it easy for third party developpers. Making it easier for users to build trust.
Btw business idea, as it did work with summize: Build an oauth service between third apps and twitter, gain the trust from the users, "force" devs to use it. As this can be switched on by twitter any moment: take a small amount of money from the users in the meantime until twitter implements it.
I'd probably pay 10 dollars a year for such an intermediary service (so make that 5 for six months)
Business idea 2 for you so you don't canibalise yourself: Let's use a pledge drive to put up money for you and implement these.
Alex:
> Christopher St John's comments above accurately reflect my own > concerns. OAuth is not a security magic bullet, and it only encourages > phishing attacks. I feel bad for users that have given their > credentials to a phishing site, and we'll do everything we can to > educate them, but token-based authentication systems are not going to > fix this particular security problem.
Of course it is not a magic bullet but let's not forget that having to provide my login data on third party apps because nothing else exists is really stupid. It may not be the magic bullet but in comparison that is miles between those too.
> Getting worked up into hysterics about boycotts is just, as security > expert Bruce Schenier is fond of saying, "security theater". It's the > equivalent of an apartment building's tenants telling their landlord > they refuse to use keys because someone's place got broken into.
The equivilant you are looking for is that in order to have operations done in my appartment all I can do is hand out my keys instead of being able to use the trusted third party service which will watch them just for a bit.
Are users stupid and dont know what they do? Of course. Basically it surprises me to see it took them phishers so long to go for it.
But you can see a clear correlation with some of the recent news with twitter news popping up on sites like digitalpoint and co.
The ecosystem is one of the reasons why Twitter is succeeding, interviews with users show that over and over again.
There is no reason why any Twitter user should simply trust an app because *you* created it. Though I inherently trust you and there's no reason to believe you would create a malicious app, no one can *verify* that. Trust yet verify.
That's all we are asking for. Until there is a verify mechanism, yes, no app at all ever on the planet, including my favorite TweetDeck, should be trusted. Ever.
I think that's what is being said here. And if that hurts business, well... blame Twitter. Or Bush. Or both. -- Aaron Brazell web:: www.technosailor.com phone:: 410-608-6620 skype:: technosailor twitter:: @technosailor
On Mon, Jan 5, 2009 at 11:35 AM, Nicole Simon <nee...@gmail.com> wrote:
> Cameron's comment shows why a system like Oauth is important: > Making it easy for third party developpers. > Making it easier for users to build trust.
> Btw business idea, as it did work with summize: > Build an oauth service between third apps and twitter, > gain the trust from the users, "force" devs to use it. As > this can be switched on by twitter any moment: > take a small amount of money from the users > in the meantime until twitter implements it.
> I'd probably pay 10 dollars a year for such an intermediary > service (so make that 5 for six months)
> Business idea 2 for you so you don't canibalise yourself: > Let's use a pledge drive to put up money for you and > implement these.
> Alex:
>> Christopher St John's comments above accurately reflect my own >> concerns. OAuth is not a security magic bullet, and it only encourages >> phishing attacks. I feel bad for users that have given their >> credentials to a phishing site, and we'll do everything we can to >> educate them, but token-based authentication systems are not going to >> fix this particular security problem.
> Of course it is not a magic bullet but let's not forget that having to > provide my > login data on third party apps because nothing else exists is really > stupid. > It may not be the magic bullet but in comparison that is miles between > those > too.
>> Getting worked up into hysterics about boycotts is just, as security >> expert Bruce Schenier is fond of saying, "security theater". It's the >> equivalent of an apartment building's tenants telling their landlord >> they refuse to use keys because someone's place got broken into.
> The equivilant you are looking for is that in order to have operations > done in my appartment all I can do is hand out my keys instead of > being able to use the trusted third party service which will watch > them just for a bit.
> Are users stupid and dont know what they do? Of course. Basically > it surprises me to see it took them phishers so long to go for it.
> But you can see a clear correlation with some of the recent news > with twitter news popping up on sites like digitalpoint and co.
> The ecosystem is one of the reasons why Twitter is succeeding, > interviews with users show that over and over again.
On Tue, Jan 6, 2009 at 3:47 AM, Aaron Brazell <emmenset...@gmail.com> wrote: > Twitblogs-
> There is no reason why any Twitter user should simply trust an app because > *you* created it. Though I inherently trust you and there's no reason to > believe you would create a malicious app, no one can *verify* that. Trust > yet verify.
Use an open source application, then. You can verify the source yourself.
On Mon, Jan 5, 2009 at 5:47 PM, Aaron Brazell <emmenset...@gmail.com> wrote: > That's all we are asking for. Until there is a verify mechanism, yes, no > app at all ever on the planet, including my favorite TweetDeck, should be > trusted. Ever.
But, but, but... People have been entrusting their email account usernames and passwords to desktop clients and even web clients for years; the same sorts of problems are theoretically possible there and, in the myriad cases of Outlook being attacked by viruses that spam everyone in your address book, quite feasible. Yet I've never heard anyone suggest "securing" your email program by forcing it in some way to not remember your password, making you type it in every time. Why this uproar over twitter authentication, when the open problem of mail authentication has been worked around for decades?
|
