OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
chinaski007
Let's be honest...
The end-result for third-party developers using OAuth appears to be
fewer sign-ups, less reliability, more complexity, and potentially
less security.
Google Optimizer reveals that users are more likely to sign-up for
Basic Auth than OAuth. That's just fact. Test it for yourself to
confirm.
I suppose this is not so weird. Users are accustomed to giving user/
pass information even to "foreign" apps. It is far more disruptive
and invasive for them to go to some bizarre Twitter screen asking them
to "approve an app". To the average user, what does that mean? (And,
heck, it may even require more steps if they have to login again to
Twitter.)
In terms of reliability, Twitter OAuth was down for days several weeks
ago. Tonight yet another unannounced change occurred that broke major
code libraries. Meanwhile, Basic Auth has been plugging along just
fine and dandy...
So what IS the benefit of OAuth?
It doesn't benefit developers as you will likely get more sign-ups
with Basic Auth and Basic Auth is far, far easier to setup. Sure,
OAuth might satisfy some power users hungry for security...
But is OAuth even more secure than Basic Auth?
Perhaps not. After all, tonight's fix was for an OAuth security flaw
known for at least 10+ days (judging by tweets to @twitterapi) that
allowed for potential impersonations of credentialed users.
On the heels of Twitter's (unofficial) assurance of better
communication with developers, this sort of unannounced change is
distressing. What's next? (Have Labor Day Weekend plans? You might
want to cancel those... just the right time for Twitter to make an
unannounced API change!)
As for us, we are in the strange position of deprecating OAuth in
favor of Basic Auth.
Weird, eh??
Okay, we are not totally deprecating OAuth, but we are advising users
that Basic Auth is far more robust and reliable.
And so our message to new developers: avoid OAuth like the plague. If
you must, offer it. But let Basic Auth be your backbone: more
reliable, more sign-ups, simpler, and probably just as secure. (Just
look at Google Code bug reports about OAuth to get a sense of
reliablity.)
(Okay, okay, this post was written at 4am after a workday that started
at 8am, and after Twitter introduced this new change at 5pm... (hey
Twitter, can you introduce major new changes EARLIER in the day so we
can react!?!?)... it still doesn't excuse Twitter's continued
disregard for the small-to-medium size developer.)
Duane Roelands
never have to provide their Twitter credentials to your application.
Basic Auth also provides no way to know that the application is
actually who it says it is. OAuth is far from perfect on this front,
but it's light-years ahead of Basic.
I'm just as agitated about this as anyone, because I think that
Twittter's behavior in this specific instance has been sub-par.
However, OAuth is still far more secure than Basic Auth
Grant Emsley
If I sign up for a website or program with my twitter password, and it
does bad things, I have to change my password in EVERY twitter program
I use. With OAuth, I can just block your app.
Paul Kinlan
TjL
> [the same post three different times]
WE GET IT. YOU DON'T LIKE OAUTH.
Your (probably statistically insignificant) tests with Google
Optimizer reveal that your users are more likely to sign-up for Basic
Auth than OAuth.
WE GET IT.
Did you need to start three different threads to say exactly the same
thing on the same day?
goodtest
clear examples and takes time to get it right, I still vote for OAuth.
You see people simply don't trust 3rd party apps with their login info
as much as they trust the main-application(twitter.com). So at the end
of the day, its better for us :)
chinaski007
Sorry about that... I deleted those threads before posting this one.
I gather you are choosing to receive emails individually.
The tests were statistically significant at 95% confidence levels.
On Jul 28, 8:09 am, TjL <luo...@gmail.com> wrote:
Andrew Badera
I gather you are choosing to receive emails individually.
As are a large number of us on this list.
JDG
I think that is the statistical significance to which TjL was referring. At least, I hope so.
Internets. Serious business.
Andrew Badera
I think that is the statistical significance to which TjL was referring. At least, I hope so.
I think TjL was referring more to raw population factor than biases. Any one single non-large userbase app is not likely to be statistically predictive of the results you will find across the spectrum of possible apps.
JDG
Internets. Serious business.
chinaski007
I haven't done any comprehensive profiling of them. (As well, my
particular presentation of the OAuth or Basic login options also may
confound the data.)
That said, the fact that any sub-population of Twitter users shows a
preference for Basic Auth is surprising. I suggest that linking
another app to one's Twitter account is foreign and difficult for the
average person to understand.
The OAuth scare page presented by Twitter doesn't help. It clearly
hasn't been split-tested and is poorly executed. It is likely
responsible for a significant number of desertions. Compare it, for
example, to the Facebook app auth page. Twitter's DENY button is just
as big as the ALLOW button; Facebook offers "approve" and then a much
smaller "cancel" link.
Add in the current complexity and unreliability of Twitter OAuth, and,
at the very least, offering Basic Auth as an adjunct option seems to
make sense.
Otávio Ribeiro
Andrew Badera
I haven't done any comprehensive profiling of them. (As well, my
particular presentation of the OAuth or Basic login options also may
confound the data.)
That said, the fact that any sub-population of Twitter users shows a
preference for Basic Auth is surprising. I suggest that linking
another app to one's Twitter account is foreign and difficult for the
average person to understand.
The OAuth scare page presented by Twitter doesn't help. It clearly
hasn't been split-tested and is poorly executed. It is likely
responsible for a significant number of desertions. Compare it, for
example, to the Facebook app auth page. Twitter's DENY button is just
as big as the ALLOW button; Facebook offers "approve" and then a much
smaller "cancel" link.
Add in the current complexity and unreliability of Twitter OAuth, and,
at the very least, offering Basic Auth as an adjunct option seems to
make sense.
OAuth IS unfamiliar, YES. OAuth DOES ask more of the user, YES. Like anything else new in technology, the better you educate your user, both implicitly and explicitly, about the process, the better the adoption rate is bound to be for a useful or required innovation.
In other words, handholding and spoonfeeding your users through the OAuth process is going to give you better conversion rates than simply bouncing them to Twitter with little or no notification or education.
--ab
chinaski007
> OAuth IS unfamiliar, YES. OAuth DOES ask more of the user, YES.
In terms of security, we've already seen how OAuth-like applications
in, e.g., Facebook have led to massive hacker/phishing/etc problems.
While OAuth solves one leg of the security problem (not actually
having their password), OAuth'd apps still have complete API access to
the account and can run rampant before the user realizes or figures
out how to revoke credentials.
jahbini
with no hiccups: Lot's of very solid implementations out there.
As far as the user sign-up problem, Yeah, I agree, It's a bit of a
scare for the user to have to connect to an off-site twitter authority
page -- But that's what Facebook, paypal and all the big boys are
pushing toward.
As Robert Palmer once said: "Your gonna have to face it, your addicted
to passwords".
Jim
JDG
Internets. Serious business.
Amitab
www.twaller.com) which supports OAuth, I think I should share my
perspective on this.
I really loved OAuth because:
(1) Ease of coding. I could get OAuth working within a couple of days.
Saves me any password maintenance, encryption etc.
(2) Integration with Twitter Branding. With the OAuth scheme, I
believe my website is more integrated with Twitter. It would also be
nicer if Twitter would maintain their own list of websites they trust
with Oauth, just to give users the added confidence that Twitter
trusts me.
(3) Saves me worrying about SSL. A lot of people are finicky about
HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth
that way in future, we will simple provide it.
The part I hate about OAuth is that the OAUth page is extremely slow
to load and sometimes does not load at all. I see this issue with the
Twitter website in general as well, sometime postst from the web just
don't go through. I would much appreciate if people at Twitter can
address scalability problems to OAUTH, because that I believe is the
biggest user turnoff.
jmathai
OAuth.
I'm trying to get a feel for if we're fortunate, have a good flow or
everyone has the same rates.
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/da46cd261fa13bca?hl=en
On Jul 28, 2:13 pm, Amitab <hiamita...@gmail.com> wrote:
> As a developer who has recent launched Twaller (http://www.twaller.com) which supports OAuth, I think I should share my
Isaiah
I really loved OAuth because:
(1) Ease of coding. I could get OAuth working within a couple of days.
Saves me any password maintenance, encryption etc.
(2) Integration with Twitter Branding. With the OAuth scheme, I
believe my website is more integrated with Twitter. It would also be
nicer if Twitter would maintain their own list of websites they trust
with Oauth, just to give users the added confidence that Twitter
trusts me.
(3) Saves me worrying about SSL. A lot of people are finicky about
HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth
that way in future, we will simple provide it.
The part I hate about OAuth is that the OAUth page is extremely slow
to load and sometimes does not load at all. I see this issue with the
Twitter website in general as well, sometime postst from the web just
don't go through. I would much appreciate if people at Twitter can
address scalability problems to OAUTH, because that I believe is the
biggest user turnoff.
chinaski007
We had much lower rates. But it is difficult to disentangle if that
is due to the extra steps required for OAuth, the OAuth scare screen
on Twitter.com, or because of the copy we initially used to invite
users to use OAuth. (For example, we had text that read "add your
Twitter account via OAuth" which admittedly isn't going to be very
well understand by the average user... "login with Twitter" would be
better.)
But for the last 3282 users who added accounts in our system, and for
whom we offered BOTH OAuth and Basic Auth options (and where the OAuth
step was clearer, indicating that they wouldn't have to give us user/
pass), 1209 or 36% chose OAuth. While this might again be confounded
by other factors, this does suggest that for our app, at least, given
the choice between Basic and OAuth, users show a preference for Basic
Auth.
On reflection (and after some sleep), I admit that my initial post was
a bit hyperbolic, and partly due to my frustration dealing with
another unannounced API change. That said, at least for us, evidence
bears out that Basic Auth is just as accepted, if not more accepted,
than OAuth by our users.
On Jul 28, 3:58 pm, jmathai <jmat...@gmail.com> wrote:
> Funny, I posted about our high success rate (95% of all users) with
> OAuth.
>
> I'm trying to get a feel for if we're fortunate, have a good flow or
Dewald Pretorius
signups.
Potential technical advantages of OAuth aside, every additional click
that you add in the conversion process adds an addition leakage point
where some users can and will abandon the signup process.
Duane Roelands
Twitter's implementation of it, or the way that they've behaved with
regard to it. Now, with all that being said.
If your website expects me to hand over my Twitter password, I'm not
using your web site. Just yesterday, another scam site (TwitViewer)
managed to steal thousands of accounts, and convince other people to
hand over their information because it was posting tweets from the
stolen accounts.
OAuth is not perfect, but it provides individual users and Twitter
with a way to identify bad actors and lock them out of the ecosystem.
OAuth works. There are examples out there. There are developers who
are willing to help you.
Implementing OAuth tells your customers that the security of their
account is important to you, and shutting down Basic Auth trains your
users to stop giving away their password. If your product has value,
and you clearly communicate what that value is, the users will use
OAuth.
Doug Williams
Amitab
On Jul 28, 4:16 pm, Isaiah <supp...@yourhead.com> wrote:
> I publish an open source example of using a OAuth in a standalone mac
> app -- so I'm bought in to the OAuth idea. But it wasn't easy, I had
> to fight to make it appear even somewhat integrated, and the lack of
> security around my apps private keys really freaks me out.
> On the other hand I see a lot of posts like this where I tilt my head
> and say, "what are you talking about?" Because I just don't get where
> you're coming from. It's like there's some hidden assumption someone
> forgot to tell me.
>
> So, please don't take offense, I'd just like to play devil's advocate
> and ask you to back up these reasons with some more info. I'll try to
> be specific about what seems odd, or at least odd to me:
>
> > I really loved OAuth because:
>
> > (1) Ease of coding. I could get OAuth working within a couple of days.
>
> You're saying that OAuth was easier to implement than basic auth? How
> so? Basic auth just places the authorization info into the request --
> oauth requires the entire token request, token exchange, token
> inclusion dance.
> At best I could see someone arguing that it's roughly the same because
> you can use a nice library either way, but saying OAuth is actually
> easier seems a bit far fetched.
>
BasicAuth since OAuth was available when I started developing
twaller.com. I wanted to respond to comments which said, OAuth is hard
to code etc., by saying I didn't feel that way, mainly because I used
the library Twitter4J.
> > Saves me any password maintenance, encryption etc.
>
> But how do you maintain the user's auth tokens? Since they're
> basically as powerful as a password (so long as the user has not
> turned them off) they need to be given the same care, right?
> In my implementation I save them just like passwords. Are other
> developers not doing this? If not why not?
>
someone wants to misuse them, they can potentially misuse them for
other websites beyond twitter. Many people including myself have
similar usernames and exactly the same password in multiple websites.
So if I accidently leak a password, and someone uses that to login a
bank website and make a financial transaction, that will not look very
good.
Oauth token's are limited to Twitter use. At the moment, i am not
encrypting it in my database.
> > (2) Integration with Twitter Branding. With the OAuth scheme, I
> > believe my website is more integrated with Twitter. It would also be
> > nicer if Twitter would maintain their own list of websites they trust
> > with Oauth, just to give users the added confidence that Twitter
> > trusts me.
>
> I'm sure if Twitter decided that tomorrow that OAuth was out, and that
> PAuth or QAuth were the new black, then those would be "more
> integrated." My point being that this is not an advantage intrinsic
> to OAuth, just an advantage of using the currently blessed standard.
> I'll give you that one, if you also agree if that if tomorrow Twitter
> decided Basic Auth was the way forward, Basic Auth would then be more
> integrated than OAuth.
my application is integrated with them. As oppossed to merely saying,
please supply your Twitter name and password to my website.
>
> > (3) Saves me worrying about SSL. A lot of people are finicky about
> > HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth
> > that way in future, we will simple provide it.
>
> But doesn't that mean that people sniffing on the network where you
> host your app could potentially grab the authentication tokens of your
> users as they fly by? Or even just your application tokens if they
> were interested in spoofing you?
> I don't mean to be paranoid, but my rather tiny little site was
> attacked and compromised once a week by evil folks in June -- 4
> different attacks by four separate security holes (note to self, don't
> run a wiki on the same host as my web store).
things on the same host, I will avoid that now.
>These jerks are
> everywhere now, and they're the real deal. They have a lot of cash
> and a lot of patience to think of new ways to exploit your resources
> to their own end.
>
> > The part I hate about OAuth is that the OAUth page is extremely slow
> > to load and sometimes does not load at all. I see this issue with the
> > Twitter website in general as well, sometime postst from the web just
> > don't go through. I would much appreciate if people at Twitter can
> > address scalability problems to OAUTH, because that I believe is the
> > biggest user turnoff.
>
> I've noticed this too. From an outsider layperson's point of view is
> seems as though we're pushing every authorization request through a
> single doorway. My hope is that it's more a lack of my understanding,
> than anything else. Right? Right?!?! ;-)
> Thanks for hearing my devil's advocate argument. Don't feel compelled
> to respond. I don't *need* answers, just curious, that's all.
>
> Isaiah
Isaiah
oshells
version of an open source social network platform).
It`s working as it should be, but I also made further thinking (if by
any chance OAuth gets down) and the first time users join our website
they must complete a "one time" signup process, allowing us to have
the missing parts from theyr account (email - any email they might
choose) and also let them set theyr username/password .
Now, even if theyr password is the same as for twitter it`s md5
encripted and no-one, neither the admins can use it in a "non-right
way".
The signup process is by-passed (from the 2nd time they join our
website using twitter authentication) by saving the twitter ID into
our database linked to the user account (the very 1st time they join),
so everytime the user joins using OAuth a session will be created for
that unique account (ID), but remember that he can also use username/
password to authenticate into our website.
I`ll advice anyone using OAuth to setup this "one-time" account
creation on theyr website (database) too, just in case something bad
could ever happen to OAuth.
If I`m pleased with OAuth? Hell ya, I do..I love it!
Sincerly, Cristian.
Andrew Badera
I used Abraham examples to implement OAuth into Elgg v0.9.2 (last
version of an open source social network platform).
It`s working as it should be, but I also made further thinking (if by
any chance OAuth gets down) and the first time users join our website
they must complete a "one time" signup process, allowing us to have
the missing parts from theyr account (email - any email they might
choose) and also let them set theyr username/password .
Now, even if theyr password is the same as for twitter it`s md5
encripted and no-one, neither the admins can use it in a "non-right
way".
Thanks-
- Andy Badera
- and...@badera.us
- Google me: http://www.google.com/search?q=andrew+badera
- This email is: [ ] bloggable [x] ask first [ ] private
Dmitriy V'jukov
> I suppose this is not so weird. Users are accustomed to giving user/
> pass information even to "foreign" apps.
already gives it much more than just login/password to some service.
And then there is 1000 and 1 way how app can then get all needed info
passing over user.
--
Dmitriy V'jukov
Bradley S. O'Hearne
Just a question along the same lines as Dmitriy's, and forwarding no
opinion one way or the other -- but I'm curious, as security
discussions often end up being debates about one particular facet of a
security scheme while not considering the big picture. What is the
breach that OAuth is primarily concerned with here? Granted that in
principle one doesn't want to be throwing passwords around, but I see
two concerns:
1. Passwords being intercepted as sent across the wire.
Comment: If credentials have to be passed over the wire to
authenticate a session, doesn't HTTPS really alleviate this concern?
In order to breach HTTPS you'd have to either crack the encryption, or
spoof the Twitter endpoint and support it by somehow spoofing the
certificate authority chain. And if someone could do this, then OAuth
is no safeguard, because they could do the same with whatever app or
session token is the key to the city.
2. Passwords being stored locally.
Comment: The application integrating with Twitter is already
effectively "trusted", so the concern should not be with the app
itself. The concern here would be other apps or people being able to
grab passwords off of disk where stored. Again, I think this goes back
to encryption. If all credentials are encrypted locally, then again,
the concern becomes the breaking of encryption, and if that is done,
then again whatever app or session token represents the key to the
city can be acquired to use in OAuth too, if I'm not mistaken.
Now admittedly, I haven't gone through OAuth with a fine-toothed comb,
but I have read the docs and examined the process. If I'm not
mistaken, OAuth doesn't alleviate authentication, it just puts the
actual username and password out of the regular communication and need
to be stored locally, but replaces it with an alternative token, which
does need to be stored locally, and passed across the wire. That token
now becomes the key to the city, no?
In conclusion, as I've been reading this thread, the thing I keep
coming back to is that OAuth vs. Basic Auth seems somewhat a secondary
argument -- the real issue is encrypting over the wire (HTTPS) and
encryption on disk, and whether those can be cracked (or are being
used as they should). From a developer standpoint, given that the
cracking of encryption seems outside the scope of concerns with the
Twitter API, what is analog is which one serves the user better -- and
I think it is clear that the Basic Auth case has fewer steps and
quicker to the result.
Please correct my misperceptions if I'm wrong, as I'd love to hear
what details I've overlooked.
Regards,
Brad
Andrew Badera
*snip*
Ahhhh ... have you missed the last 12 months of Twitterverse drama? You can't trust random third party apps who demand your credentials. How do we know what they'll do with it? There was a breach just this week, wasn't there? The concerns of passing and storing passwords over-wire and on-disk are, by and far, secondary.
Yes, "we" may have the best of intentions, but I don't know you from Joe Six Pack or Johnny Spammer.
Duane Roelands
Encryption on disk and encryption over the wire are not the issues and
really don't have very much to do with the Basic vs. OAuth decision.
The most important issue I see is that Basic Auth requires you to give
your Twitter credentials to a person you do not know. This is a BAD
IDEA.
Basic Auth is great for prototyping and testing and getting the core
functionality of your app working, but at some point you should bit
the bullet and implement OAuth. It's better for your customers
(security) and it's better for you because your customers can use your
application with peace of mind.
If YOU wouldn't hand over YOUR Twitter credentials to a stranger, it's
silly to expect your users to do so.
On Jul 30, 11:40 am, "Bradley S. O'Hearne" <brad.ohea...@gmail.com>
wrote:
Bradley S. O'Hearne
I understand the concern. But I think the conversation is moving
closer to the actual issue. Your example of turning Twitter
credentials to a stranger basically makes the application (or
computer) that the user has already willfully chosen to use "a
complete stranger". I would debate that is necessarily the case, but
let's for the moment assume it is the case, and see the problem with
that assumption.
In that case, OAuth *still* requires production of credentials to a
complete stranger. Because it supposedly redirects to the Twitter web
site for authentication doesn't save you from the either originating
web site, the browser, or the machine itself spoofing the redirect --
I mean you've already labeled them "a complete stranger", so you have
to allow now for that possibility. Additionally, that login directly
into Twitter also doesn't save you from keyboard logging or phishing
on the machine -- or, and I'm not 100% sure on this one but I think it
is possible, malicious browser plugins. So here we get into the issue
of not just a single trusted / non-trusted app, but whether it is a
trusted box or not.
Perhaps I'm still ignorant, but unless I've completely missed the
boat, credentials are still being produced -- i mean, at some point
they have to be, otherwise they wouldn't be credentials, something
else would be. I think what I'm really responding to here is the lack
of context given to discussions surrounding OAuth's security -- there
are blanket statements being made about not giving a stranger
passwords, and OAuth somehow solving that. Well, that "stranger"
happens to be the machine you've chosen to trust. Just because OAuth
exists, it doesn't make Twittering or accessing Twitter data from
Facebook on an Internet Cafe computer any safer necessarily. There is
a degree of trust somewhere that is being trusted as a beginning
prerequisite. I do not believe there is a no-trust scenario here. What
I really want to hear stated, or read on a FAQ, is the pre-requisite
security trust, that in that scenario, it necessarily makes OAuth
superior to basic authentication.
Brad
Andrew Badera
Duane Roelands
credentials to anyone but Twitter.
Basic Auth requires you to give your Twitter credentials to someone
other than Twitter.
Therefore, OAuth is more secure than Basic Auth.
This is not rocket science.
On Jul 30, 7:07 pm, "Bradley S. O'Hearne" <brad.ohea...@gmail.com>
Jesse Stay
Abraham Williams
As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer.
Abraham
Abraham Williams | Community Evangelist | http://web608.org
Hacker | http://abrah.am | http://twitter.com/abraham
Project | http://fireeagle.labs.poseurtech.com
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States
Dmitriy V'jukov
> OAuth lets you access the Twitter service without giving your Twitter
> credentials to anyone but Twitter.
> Basic Auth requires you to give your Twitter credentials to someone
> other than Twitter.
> Therefore, OAuth is more secure than Basic Auth.
> This is not rocket science.
situation is not that way. You do give password to application (or
application can take it if it wants). You are just fooling yourself,
and this makes security even worser. With basic auth you are aware of
the fact you are giving application credentials, so are able to make
thoughtful decision. With OAuth you (ordinary user) are not aware of
the fact that you give application credentials, so you are under wrong
illusion that you may use any application and you on the safe side. In
reality you give application everything when installed it to your
computer. In this situation basic auth becomes more secure because it
shows situation to a user as it is ("stupid! you must trust any
application you are installing!"), OAuth panders security threats
("relax, you may think as if you may not trust the application,
because you are as if not giving it credentials").
--
Dmitriy V'jukov
Dmitriy V'jukov
wrote:
> 2. Passwords being stored locally.
> Comment: The application integrating with Twitter is already
> effectively "trusted", so the concern should not be with the app
> itself. The concern here would be other apps or people being able to
> grab passwords off of disk where stored. Again, I think this goes back
> to encryption. If all credentials are encrypted locally, then again,
> the concern becomes the breaking of encryption, and if that is done,
> then again whatever app or session token represents the key to the
> city can be acquired to use in OAuth too, if I'm not mistaken.
indirect security token too. Assume: application asks user for
credentials, verifies them on the server, in response server issues
unique indirect security token, application discards original
credentials and stores token.
This will depend on the application's "security culture", though.
--
Dmitriy V'jukov
Nicole Simon
I am surprised nobody is bringing up these too points:
- people will use the more secure thing once they are educated. you know the kind of stuff where you tell the people you support that they will not get tech support any more if they do this.
- the argument about 'having to agree on something' is not as bad as it sound because they do it every day on facebook. The one thing I do mind that even I always have to search aruond to find the place where my apps are located.
Nicole
~~~
--
Jetzt im Buchhandel:
"Twitter - Mit 140 Zeichen zum Web 2.0"
Amazon: http://tinyurl.com/6at9c5
http://mit140zeichen.de - http://twitter.com/m140z
Kontakt:
http://twitter.com/NicoleSimon
https://www.xing.com/profile/Nicole_Simon
skype: nicole.simon / mailto:nicole...@mit140zeichen.de
phone: +49 451 899 75 03 / mobile: +49 179 499 7076
Duane Roelands
credentials, so are able to make thoughtful decision."
"thoughtfully" gave their Twitter credentials to TwitViewer and got
their accounts stolen.
"With OAuth you (ordinary user) are not aware of the fact that you
give application credentials"
anyone except Twitter.
It's a bad idea to give your account credentials to a third party.
Basic Auth forces you to give your account credentials to a third
party.
Therefore, using Basic Auth is a bad idea.
On Jul 31, 8:09 am, Nicole Simon <nee...@gmail.com> wrote:
> I am surprised nobody is bringing up these too points:
>
> - people will use the more secure thing once they are educated. you know the
> kind of stuff where you tell the people you support that they will not get
> tech support any more if they do this.
>
> - the argument about 'having to agree on something' is not as bad as it
> sound because they do it every day on facebook. The one thing I do mind that
> even I always have to search aruond to find the place where my apps are
> located.
>
> Nicole
>
> ~~~
>
> --
> Jetzt im Buchhandel:
> "Twitter - Mit 140 Zeichen zum Web 2.0"
> Amazon:http://tinyurl.com/6at9c5
>
> http://mit140zeichen.de-http://twitter.com/m140z
>
>
> skype: nicole.simon / mailto:nicole.si...@mit140zeichen.de
Otávio Ribeiro
Christopher St John
O'Hearne<brad.o...@gmail.com> wrote:
>
> I really want to hear stated, or read on a FAQ, is the pre-requisite
> security trust, that in that scenario, it necessarily makes OAuth
> superior to basic authentication.
>
The problem here is that you're paying attention, instead
of just accepting "oauth is better because it is!" statements :-)
For desktop apps (and in any case where the application has
has control of the UI and/or your computer) OAuth has no
security advantage (since the app can snoop the interaction)
I'm sure bad people are working on a way to make this true
in browser apps as well, but I don't know of any examples.
For web applications, many commentators acknowledge an
increased risk of phishing as a potential problem with OAuth,
although I haven't personally read any studies that indicate
whether it's a theoretical or practical problem at this point.
In any case, the primary benefit in OAuth is not protecting
the user immediately from an evil application (since the
authorization tokens an OAuth server hand out are just as
powerful as passwords and must be protected like passwords)
it's that:
- the owners of the service can (in theory) administratively
ban an application without forcing all the users to change
their passwords (a potentially very big benefit, maybe the
single benefit that justifies the general inconvenience)
- an individual user can ban an application by revoking its
authz token without having to change their password (a
moderate-at-best benefit, since you could always just
change your password)
- an individual who is using exactly the same password
at many sites doesn't have to expose out their mono-password
to an app (people mention this a lot, but come on, should
security system try to make people feel better about hitting
themselves on the head with a hammer? but this gets
mentioned a lot, so there you go)
So, the security picture is actually a little fuzzy. There are
some big wins for service administrators, some real (but
medium-sized?) wins for users, some fundamental limits
of applicability (web-apps only) and some open questions
about phishing and snooping. And lots and lots of hype :-)
-cks
--
Christopher St. John
http://praxisbridge.com
http://artofsystems.blogspot.com
JDG
--
Internets. Serious business.
Jesse Stay
Josh Roesslein
without having to store your password in plaintext on the hard disk. This way if the computer is compromised or stolen later on your password is not compromised.
I still think the UX with desktop based oauth apps isn't the most joyful and could be improved upon. One possible solution that has been brought up is allowing the desktop app to "authorize" on your behalf using your username and password. This way the app can get the access token without the user having to visit the SP's site. Once the access token has been retrieved the application can "forget" the password and remain logged in even if the password changes in the future. All resource requests would then be done using oauth with the access token.
Overall I think OAuth is a good solution for API authentication. Its secure and provides benefits to the user, consumer, and sp.
Josh
Doug Williams
That is not true. With the Sign in with Twitter flow (not the standard OAuth flow which is also available) -- If the user is logged in and has previously approved the app, they will be immediately redirected back to the application without ever seeing a Twitter dialog.
Thanks,
Doug
Jesse Stay
Doug Williams
If it is not, then it is a defect. That is the intended functionality.
Thanks,
Doug
Bradley S. O'Hearne
It is good to see that someone understands the bigger picture here.
This conversation suffers from a presumption of a specific use-case
(web application communicating with Twitter), and a particular
presumption of trust, or lack thereof. The particular comments such as:
> You can lead a horse to water ...
and
> This is not rocket science.
pretty much demonstrate a very narrow contextual view, in which their
view might make sense, but outside of which it does not. Restated,
this is optimistic thinking from the perspective of their particular
use case, and ignores the perspective of either other use cases, and
overlooks someone trying to exploit a security vulnerability. To my
knowledge, and certainly in this conversation, OAuth is being touted
as an across-the-board superior security approach for ALL use cases.
Having spent the better part of the last two and half years doing
secure data storage development far more complex than that of just
authorization, but also securing the payloads across an entire cloud
and desktops, and the network as a whole, my comments here are simply
to see the claim of OAuth being undisputably superior supported with
fact against legitimate breach points. I'll give an example.
My personal development use case for security is communicating with
Twitter from an iPhone app. Applying the same broad brush "you
wouldn't give your data to a complete stranger" comments to the
iPhone, your "complete stranger" here is the iPhone app you are using.
So effectively, your "complete stranger" assertion maps to the
following:
1) You've downloaded an app from the App Store with the intention of
using it for communicating with Twitter, yet it is considered a
"complete stranger", and untrusted.
2) You use the app, and explicitly initiate communication to Twitter
within this very "complete stranger".
This "complete stranger" assertion is absurd. First, you haven't
treated the iPhone app like a "complete stranger". You explicitly
downloaded (and likely paid money) to explicitly put this application
on your phone. Furthermore, it doesn't really matter if you pull up
the OAuth login page within your iPhone app. That "complete stranger"
iPhone app could capture keyboard events and/or filter EVERYTHING you
send across the wire prior to any encryption being applied.
Furthermore, even if OAuth itself isn't breached, as soon as your
token is acquired, what's to prevent the app from then going
absolutely haywire with your account, posting malicious status,
following / blocking who it chooses, etc.?
Furthermore, all of the "other apps" comments don't directly apply --
every app on the iPhone is sandboxed, which protects it from any other
app tampering or accessing data. The only breach of this, of course,
is jailbreaking, but then again this is analogous to someone hacking
and "owning" the desktop you are browsing on, in which case OAuth is
no protection again.
The variance for desktop apps is that they aren't sandboxed away from
other apps on the machine, but other than that, most of this all
applies to that environment too.
Unless other information surfaces, Christopher, best I can tell, you
are spot on. OAuth seems particularly relevant to web applications,
and relevant to desktop and iPhone apps primarily if your desktop /
iPhone are NOT password protected, and the application in question has
stored credentials, and you either lose or have stolen your desktop /
iPhone.
In conclusion, addressing one last example of ATM cards and pins --
you picked the safe example. A credit card is far less safe than all
of this, because lose one of those, and the finder is on a shopping
spree, no ID or pin required. And I'd bet 99% of this mailing list,
including the OAuth devotees, carry a credit card, and don't think
twice about the fact that they are one hole in their pocket away from
receiving a truckload of Shamwow's delivered to their house.
Regards,
Brad
JDG
In conclusion, addressing one last example of ATM cards and pins -- you picked the safe example. A credit card is far less safe than all of this, because lose one of those, and the finder is on a shopping spree, no ID or pin required. And I'd bet 99% of this mailing list, including the OAuth devotees, carry a credit card, and don't think twice about the fact that they are one hole in their pocket away from receiving a truckload of Shamwow's delivered to their house.
I assume that's what you meant, anyway ;)
--
Internets. Serious business.