This is far less secure than OAuth and is actually not much better
than requiring a username and password.
One of the core benefits of OAuth is the ability to be very specific
regarding what each authorised application is allowed to do, on a per
application basis. It also allows you to selectively revoke the
permissions of any specific application without needing to ask or even
tell the application about it. To do this with the API key system you
effectively need to re-authorise every app you use when you want to
block just one of them. No real difference between this and having to
change your password.
I would much prefer that the guys (and gals) at Twitter concentrate on
getting OAuth properly implemented (which is harder than it sounds)
than their attention gets diverted by developers too impatient to wait
for the right solution to the problem.
-Stut
--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x
Truly OAuth is needed, and is a priority to the Twitter team (they've said
so). However, there is nothing in the link that Scoble has up saying directly
that the buyer is planning to use the information Twply has harvested (namely
usernames and passwords) for nefarious purposes other than to continue
running the site. They certainly could, but Scoble needs to chill out a
little.
More to the point, there is nothing about OAuth that prevents a similar
bad actor from behaving badly. This older post puts it in perspective very
succinctly:
http://groups.google.com/group/twitter-development-talk/msg/16bf699d39c7f804
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- 10% of computer users [use] Mac ... the top 10 percent. -- Douglas Adams ---
I agree that OAuth can't arrive too soon, but this episode sucks
mainly because there is no need for something like twply to need your
password. This annoyed me so much that I spent this afternoon coding
up a site to prove that point.
Feedback greatly appreciated: http://replies.twitapps.com/
-Stuart
That's pretty clever. Nice work.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Shady business do not make for sunny life. -- Charlie Chan -----------------
Thanks.
> Quick question: How are you ensuring that you see *all* posts in the
> public timeline? I didn't think that was quite possible yet with the
> Twitter API.
It's actually using the search API not the public timeline.
-Stuart
I'd find more reputable sources for that argument.
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
Whilst there's an element of truth in your statement (just about all
of the prominent tech bloggers remain prominent by stirring up drama),
lots of people have been saying similar things for a long time. Ad
hominem attacks don't change the fact that the message is right. You
could start here : http://adactio.com/journal/1357 .
I think we all understand, however, that the twitter engineering team
first needed to make twitter stable before they could add features
like this one. Now that they've largely done that, it appears they're
responding to demand for features like this one, which is great news.
Mark
So let's say Scoble is right. How, in fact, does OAuth prevent a bad
actor from using credentials to act badly?
OAuth solves many problems; it doesn't solve this one.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- BOND THEME NOW PLAYING: "The Man With the Golden Gun" ----------------------
> Whilst there's an element of truth in your statement (just about all
> of the prominent tech bloggers remain prominent by stirring up drama),
> lots of people have been saying similar things for a long time. Ad
> hominem attacks don't change the fact that the message is right. You
> could start here : http://adactio.com/journal/1357 .
Agreed, and that's a much better source.
>
> I think we all understand, however, that the twitter engineering team
> first needed to make twitter stable before they could add features
> like this one. Now that they've largely done that, it appears they're
> responding to demand for features like this one, which is great news.
Yep. So not really a lot of point in continuing the "oh boy, this is a
big problem! thing, I think, when they're on it and have given many
updates here recently." That's not a criticism of you in particular,
but of folks who apparently don't search the archives before posting
something along the lines of "Scoble said this is a big deal, so you'd
better do it!" It doesn't help in any way.
And this.
I think it's getting more urgent day by day:
http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/
Richie
http://twitter.com/RMetzler
Maybe for apps, but not for users. A user that thinks he's secure and is
not is far worse off than a user who's insecure and knows he isn't. If this
makes people think about who they give credentials to -- OAuth or no -- then
the experience will be a painful but useful lesson.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- BOND THEME NOW PLAYING: "The World is Not Enough" --------------------------
There are several problems to be solved, though.
The first is a malicious actor with access to a single system (in this
case, twitter) spamming. OAuth doesn't solve the problem of someone
using an account to spam using messages from that user (unless that
app doesn't need to message, and twitters OAuth implementation has
granular permissions).
The second is a malicious actor with access to a single system gaining
control of other systems that user has access to because they've used
the same username and/or password. Whilst this is bad practice on the
part of the user, we'd be silly to pretend that this isn't a large
problem. OAuth *does* solve that problem, which is one of the
problems in this scenario.
The third is a malicious actor with access to a single system locking
the user out of their own account (by changing their password) and
claiming the account for themselves (which has been known to happen
with gmail accounts, for example). Twitter, so far as I'm aware,
doesn't allow changes of passwords via the API, and I would assume
that an OAuth implementation would only allow access to the API, and
not the web interface. Even were these things not the case, it
wouldn't make sense to allow an OAuth client to change the user
password. So OAuth does solve this problem, also.
Mark
Clearly. But the point I'm making is that *this* particular situation isn't
solved by OAuth. You're absolutely right about the rest of the similar
issues it *does* improve -- no one is contesting OAuth's utility -- but it
wouldn't help this particular hypothetical situation.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Friends don't let friends use Windows. -------------------------------------
Actually, it does.
On Jan 2, 11:06 am, "Jesse Stay" <jesses...@gmail.com> wrote:
>
> It's true, OAuth doesn't really solve this problem, but the general public
> thinks it does.
With OAuth you can turn off a particular token, blocking a *specific*
application (i.e. Twply).
It doesn't prevent bad actors from behaving badly, but it does given
provide a pathway to give users more control over third-party access
to their account.
If you don't like what your application does, or find it hard to do
what you want, I might also suggest that you developed your
application at the wrong time. Making financial commitments that rely
on a service which you have no agreement to level or service seems
like a bad idea.
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
Whether its writing books or developing applications, it's typically
bad form to assume your own experience mirrors others' experience when
doing a similar type of activity. Generally leads to incorrect
assumptions.
If you don't like what your application does, or find it hard to do
what you want, I might also suggest that you developed your
application at the wrong time. Making financial commitments that rely
on a service which you have no agreement to level or service seems
like a bad idea.
Of course, once we offer OAuth, it would be nice to see the same
community pressure that's been applied to us put towards companies
like Amazon. The Amazon.com iPhone app collects my username and
password, and that account is actually tied to my credit card
information. Where are the blog posts about their anti-patterns?
--
This is where I get antsy, and maybe Chris can point out some ways to deal
with this, but from my perspective as a desktop client author OAuth is a
lot of hurt without a lot of benefit to me the developer (other than "it's
the only way in so love it or lump it"), and I think even the user's benefits
are nebulous. If you don't trust an application, you shouldn't be running it.
Isn't that where Trojan horses come in?
But let's say that there is (a) good reason for a desktop application to use
OAuth as its primary method; now I have a technical question. The way I'm
reading
is that I go and get a request token (A.2), but I need to redirect a user to
a service provider's login page (ouch) for her to authorize that token (A.3),
then provide a callback URL (double ouch) (A.3). At best this is turning my
application into not only a Twitter client, but also a web server (to accept
the callback). At worst this isn't possible because the Service provider
*can't* call me back due to network restrictions on the desktop machine.
Also, since TTYtter is text based, I *really* don't want to be opening up a
browser to get logins (or if I do, I want it to be Lynx, and fat chance I bet).
Clearly OAuth is the way to go for standalone web sites talking to Twitter,
but I get nervous about hearing OAuth will be the only method of access while
trying to work through the issues unique to a desktop client. I would
appreciate hearing from someone knowledgeable about the best way to overcome
these issues, or if there is a special way that I missed where an application
can authenticate itself by just asking the user for their OAuth credentials
and proxy everything to the service provider, which would also suck, but less,
from a developer standpoint. (But that would also probably defeat the purpose
of OAuth.)
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Blanket statements are always wrong. ---------------------------------------
--
That's what I mean. This would definitely be UX hurt for a standalone
application, and it still doesn't solve the callback problem. Chris?
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- This message will self-destruct in five seconds. Good luck, Jim. -- M:I ----
And one more followup is how Google tried to deal with this, which I just
found. Some of these issues would be very difficult to overcome in practice.
http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- When the going gets weird, the weird turn pro. -- Hunter S. Thompson -------
Were I king of Twitter, I would have banned any 3rd-party web sites
that request usernames and passwords. Lucky for you, I'm not in charge
8D.
The security expectations are different for desktop apps, I think.
Users understand the potential for malicious applications on the
desktop better, and that's why I never had a problem asking for a
username and password in Spaz, as long as I always communicated over
SSL, and stored the password locally in an encrypted format. Desktop
apps are typically not open to as many easy-to-execute attacks that
would allow for stealing of credentials as web apps. So, I feel
comfortable with desktop apps requesting usernames and passwords. I
also think that throwing the OAuth authorization squaredance would
indeed be a hassle that will confuse most users – maybe not as much as
OpenID does, but something that definitely will require a lot more
hand-holding and explanation on the part of app devs.
However, I don't know if it's reasonable or even possible to make a
distinction between web apps and desktop apps for the purposes of
authentication type. I suspect it is not.
OAuth does offer some wins over username/password exchange. As I
understand it (mostly from my experience with Flickr), these include:
- more granularity over authorization: an application can just request
read access, for example
- no password sharing required: many (most?) users will duplicate
usernames and passwords across various accounts. OAuth limits the
potential damage (although you could see some interesting information
assurance problems with Twitter accounts that feed other systems).
- A malicious app can be blocked system-wide (after being identified as such)
- A malicious app can be blocked from an account without changing that
account's username and pass (after being identified as such)
All that being said, *I will bet you dollars for donuts that you'll
see successful phishing attacks via OAuth*. In fact, you might even
see *more* successful attacks, because for as many folks who have
ill-advisedly entered their Twitter credentials into a 3rd-party site
to get an ego-stroke, I suspect that *more* will click a button that
says "give this application permission," no matter what permissions
are being requested.
Those who expect OAuth to be a panacea for identity theft on Twitter
simply don't understand the issues involved. Operating a modern
computer involves a lot of trust - trusting applications you run on
your machine, trusting web sites you set up accounts on, and the like.
And when you trust, there's always the potential for getting burned.
OAuth doesn't change that fundamentally.
In addition, OAuth or no, what makes us think classic phishing attacks
that collect Twitter usernames and passwords will stop? Remember,
*most Twitter users use the web site or SMS* and therefore may have
*no* interaction with the OAuth system -- all they ever do is enter a
username and password. And even for folks who *do* have experience
with the OAuth system, I'd expect that without extensive training,
they'd still be likely to fall for classic phishing attacks.
As a side note, I wonder if Twitter API dev would have taken off as it
did if OAuth was required from the start. I believe that using HTTP
Basic Auth was a key to making API dev as accessible as possible.
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
Those who expect OAuth to be a panacea for identity theft on Twitter
simply don't understand the issues involved. Operating a modern
computer involves a lot of trust - trusting applications you run on
your machine, trusting web sites you set up accounts on, and the like.
And when you trust, there's always the potential for getting burned.
OAuth doesn't change that fundamentally.
Help us out here with what "worm" you mean -- there are lots of them 8)
> (if it's not, then Twitter really needs a Captcha on the
> Twitter login page) At the moment all Twitter can do is chase down IPs to
> kill the App.
Sure.
> With OAuth it would be as simple as killing the API key
> itself and the worm would be dead.
If the malicious application uses OAuth via Twitter, yes.
> Could they go in and create another one?
> Probably, but it makes it a whole lot harder for someone to create such a
> worm. This is the reason most of the Facebook worms right now are spreading
> through simple screen scraping and not the App platform. It's too much work
> to do it on the App platform there because Facebook would just shut you down
> each time their alarms went off.
I'd note that it used to be too much work to spam Google Groups
because of CAPTCHAs too, but almost all CAPTCHAs can be defeated now
programatically and via mechanical turk-style attacks. I and a few
others have to review posts from all new users for this reason.
Also, why do you assume that phishing attacks would have to come via
Twitter messages, though? Most come via email or web content on other
sites. Twitter currently uses email notifications for several events
-- faking those would be quite easy to do, for example.
OAuth may have mitigated (not blocked) *one* particular worm that was
sending messages directing people to a phishing site. And yes,
removing everyone's shoes does stop the shoe bombing attack. Whether
or not this actually makes you *safer* is something we should very
carefully consider. Personally, I'd say it helps, but only a little --
far less than most of our Thought Leaders claim.
OAuth may have mitigated (not blocked) *one* particular worm that wassending messages directing people to a phishing site. And yes,
removing everyone's shoes does stop the shoe bombing attack. Whether
or not this actually makes you *safer* is something we should very
carefully consider. Personally, I'd say it helps, but only a little --
far less than most of our Thought Leaders claim.
> So what do *you* recommend Ed (that goes for everyone that is criticizing
> OAuth, including Alex)? I see a lot of criticism against OAuth, but I see no
> suggestions for a solution.
Perhaps you're mistaking criticism with an attempt to make for
realistic expectations, and temper an artificial urgency.
Generally I think OAuth is a Good Idea, and I think it's probably a
good step for Twitter to take. I think I can say Alex agrees, or he
and the rest of the API team wouldn't be implementing it.
It's not really my job to tell Twitter what to do – first off, I think
they have people with very good security backgrounds in place, and
secondly I'm not on their payroll. But if you actually want to hear a
few things, I'll toss them out. I don't have time or motiviation atm
for a lot of detail (we just lost a family friend tonight to cancer),
but I'm happy to talk about them another day in detail if you want.
- immediately cease the development of any web-based applications that
require user credentials. I generally don't think that you're keeping
your user's best interests in mind when you do this.
- educate users about risk acceptance: what it means to trust a web
application with your credentials (or OAuth permissions), and what the
consequences could be if trust is broken.
- educate users about how to identify phishing attacks
- possibly implement some personal site ID techniques on the Twitter
homepage, like user-chosen identifier images
Even if you do a great job on all of these, though, you will always
have some people who fall for it.
> Right now, I think it's a step in the right
> direction - I see a lot of theories here, but not a lot of urgency to fix
> the problem. As I said, I don't care what the solution is - I just need
> something, other than requiring my users to enter their plain text usernames
> and passwords. There's huge urgency here - what's the solution to the
> problem?
There is no solution.
Really. There isn't. People who work in security will tell you this.
The security industry spends millions and millions of dollars on
application trust issues, and there is no solution. There are things
you can do, but you can't "solve" the problem. You can only *mitigate*
risk.
People clamoring for OAuth -- this is the urgency you refer to -- are
participating in security theater. They want it implemented not
because it will make things a little better, but because they have
been whipped up into a frenzy by ye olde Thought Leaders and want
*something* to be done. I was completely serious about my shoe bomb
analogy, because it's a classic security theater – "oh shit, you could
put a bomb in your shoe! better check everyone's shoes!" It's a
temporary PR fix, but it doesn't solve the problem other than making
people feel better -- until the next security flavor of the week comes
around.
If you seriously want to study this kind of thing further, I think
starting off with Schneier's "Beyond Fear: Thinking Sensibly About
Security in an Uncertain World" would be a good idea. As a developer,
you should also dig into all the security info you can, and make
security a first-level concern. If you're a PHP dev (I know a lot of
folks here are), I'd probably start out with Chris Shiflett's
"Essential PHP Security." Rails devs should keep an eye on
http://www.rorsecurity.info/.