Open Auth
Kevin Mesiab
We are considering not implementing OAuth in our desktop application.
The interaction seems unintuitive and redundant for users who have
already granted our application 'trust' by installing it. Are we
still to expect basic auth to go away? Is it possible to be granted a
source attribute without OAuth implementation?
--
Kevin Mesiab
CEO, Mesiab Labs L.L.C.
http://twitter.com/kmesiab
http://mesiablabs.com
http://retweet.com
Duane Roelands
"grandfathered in".
Jesse Stay
Josh Roesslein
Josh
Nicole Simon
The interaction seems unintuitive and redundant for users who have
already granted our application 'trust' by installing it.
I can't understand this notion.
Every single day users are sheep enough to do stupid things -
they just need to be guided to do so. And then they will follow.
Every single day (especially the normal users) install dozens of apps on facebook
without even thinking about that box in the middle nor reading it. And 'the experienced
ones' who teach the sheeps make sure that "never use your password" gets drilled
into their heads.
Before there was no alternative. Now there is a better way.From now it is "password?
BAD. Using without password and authorize with twitter: good!"
Yes, they have granted you the trust of installing it, but could you please set the
mindset to the goal? "as part of our x step installation step, this is what is going to happen:
- download app
- install app
- test app
- now the fun part: making sure you get the best ou tof this experience and connect it with
twitter itself, and this is how it looks. We are using the secure process where you
do not need to enter anywhere your password. we never ask for your password, because
we are the good guys!
- do this
- do that
and tada! you can start using our app! thanks for trusting us!"
Where is the problem?
It only is unintuitve when you make it as such. of course the above is too complicated,
so the real steps only should be "3 easy steps to go - download, install, connect, use!" or something like it.
But as long as you treat it as the ugly way you don't want to use, you will not make
it easy on you.
Nicole
--
"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
Andrew Badera
Agreed. OAuth presents a standardized and centralized process, a
universal standard which users can become familiar with, rather than
any given app's arbritrary authorization mechanisms and actual levels
of trustability.
∞ Andy Badera
∞ This email is: [ ] bloggable [x] ask first [ ] private
∞ Google me: http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera)
sausman
Kevin Mesiab
they used for Twitter are now valid for use in uploading media. This
lets users enjoy a bit of a mash-up with a single sign-on. Is this
also true when authorized via openAuth?
Peter Denton
With basic auth, its nice because you can use those credentials anywhere. I was working on a collaboration site, until I heard basic auth was going away, because I was able to use credentials for dozens of services around a single profile.
I asked the same question about oAuth, i.e. can I validate with oAuth and then allow these users to show tokens to other oAuth enabled services and let them proceed. The answer I got then was no.
Hopefully this will change, as the other path presented so many cool options.
Anyway, retweet.com looks very cool.
Peter
Jason Martin
If a user doesn't want the application to access their Twitter
account, why'd they download it in the first place? It seems very
redundant.
But the real problem is for mobile devices, especially for devices
that don't have Copy and Paste functions (like the iPhone, up until
recently). Twitter doesn't have a login page for OAuth that really is
made for mobile phones, so the user has to perform extra actions
(zooming, panning, etc.) to be able to login. The PIN method of
verification doesn't work well for phones that don't have Copy and
Paste (like pre-3.0 iPhone, if you plan on supporting that), but then
neither does the Browser option work, because you can't really launch
an app from a URL (with the exception of the iPhone, but Twitter
doesn't allow non-standard URL schemes).
OAuth on mobile devices doesn't work. Let's go back to the iPhone
(which I use as an example because I am a developer for it). You can't
be contaminated with viruses, you can't get malware, and you can't get
spyware. The only way you can get software at all ("legally") is to
get it from Apple, through the App Store, and Apple already does
filtering, and strips out malicious apps. Since the App Store is the
only medium to get apps, you have to want and then go download them.
There is no third-party here putting malicious code on your device,
and stealing your credentials. There is only the users, who wants to
use your app, downloads it, and then is asked if wants to allow this
app to access Twitter. If he doesn't want to let it access Twitter,
why the heck did the user download the app in the first place?
Sure, I chose the iPhone, but from what I understand, other phones
have app stores of their own: Android has their Marketplace,
Blackberry has one, Palm will soon get one if they don't already have
one. People want to use Twitter on these devices, even full clients.
But trying to login to OAuth on that tiny screen, with a PIN that you
may or may not be able to copy and paste (depending on your device
capabilities), is just a big hassle.
For my Twitter client, I've gone ahead and done all the OAuth
authentication behind the scenes. I'll ask them for a username and
password, and log them into OAuh myself without them having to ever
see a web browser. "Wait! You shouldn't do that!" Whatever! I'm
selling this Twitter client on the App Store for two dollars. If a
user doesn't want to let my app access Twitter, why is he wasting two
bucks to download an app he will not use? It does not make sense!
I understand that OAuth is implemented to give the user an extra net
of security, but I'm not sure that the OAuth system is the best one to
use. What would be best is a system that can be used on any platform,
with any device, mobile or desktop. Modifying the login to do
something different for mobile clients, like a different way of
authenticating (such as choosing a picture. Show a picture in the web
browser, send possible images to the client, then have the user choose
the correct picture they saw), would be fantastic! At the very least,
mobile versions of OAuth login and authentication should be implemented.
On another note, how "Open Source friendly" is OAuth? I'm not sure if
people who write open source software want to be giving out their
Consumer Secret key in their source code for spammers to possible get
a hold of, build a bot using that key and secret, and then spam
Twitter using that key, which Twitter might block, thus, completely
disabling your app for all your users. This is terrible for people who
might write open source iPhone clients, as the approval process for
these apps takes 2 weeks: 2 weeks your users can't use your app, and
might switch over to another client.
- Jason
Chris Babcock
Jason Martin <legos...@gmail.com> wrote:
> On another note, how "Open Source friendly" is OAuth? I'm not sure
> if people who write open source software want to be giving out their
> Consumer Secret key in their source code
Reasoning from a faulty premise.
When you know your code is going to be seen you either avoid doing
stupid things like hard coding credentials or you learn fast that
configuration data is not code.
(Now where I did leave my virtual haddock?)
Chris Babcock
Duane Roelands
myself without them having to ever see a web browser."
authentication protocols is a great way to get your app shut down.
Also, your application is likely to break if Twitter makes changes to
the OAuth page layout.
I have lots of issues with OAuth, but it's basic premise is sound:
OAuth allows people to use Twitter without giving away their Twitter
credentials.
On Aug 17, 6:27 am, Chris Babcock <cbabc...@kolonelpanic.org> wrote:
> On Sun, 16 Aug 2009 18:49:49 -0400
>
Bill Kocik
> stupid things like hard coding credentials or you learn fast that
> configuration data is not code.
mobile device application - open source or closed - that uses my OAuth
credentials in such a way as to protect my credentials from being
discovered?
Seriously, how do you do that?
Chris Babcock
You don't distribute your credentials with the App. You include a
README file that tells implementors how to get and install their own
keys.
Chris Babcock
JDG
Internets. Serious business.
Joseph Cheek
their app key and secret, have you ever run "strings" on your binary?
(for those keeping score, it's basic auth: 2, oauth: 0)
thanks!
Joseph Cheek
@cheekdotcom
JDG wrote:
> Which eliminates one of the biggest features of OAuth for a lot of
> app-writers -- the ability to put their app in the "source" parameter,
> thus eliminating the biggest piece of marketing they have.
>
> On Mon, Aug 17, 2009 at 08:59, Chris Babcock <cbab...@asciiking.com
> <mailto:cbab...@asciiking.com>> wrote:
>
>
>
> > On Aug 17, 6:27 am, Chris Babcock <cbabc...@kolonelpanic.org
Cameron Kaiser
> > > stupid things like hard coding credentials or you learn fast that
> > > configuration data is not code.
> >
> > Fair enough. So how do you do it? How do I distribute a desktop or
> > mobile device application - open source or closed - that uses my OAuth
> > credentials in such a way as to protect my credentials from being
> > discovered?
> >
> > Seriously, how do you do that?
>
> You don't distribute your credentials with the App. You include a
> README file that tells implementors how to get and install their own
> keys.
No barrier to entry there. ;-)
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- "I'd love to go out with you, but I'm rethreading my toothbrush bristles." -
Joseph Cheek
you propose to distribute a usable FLOSS twitter app that uses Oauth to
authenticate itself but doesn't include the app's consumer key and
consumer secret? fetch the key and secret at runtime from a secure
server somewhere? that could be trivially intercepted.
Joseph Cheek
@cheekdotcom
srikanth reddy
You cannot ask every user to get new consumer token/secret.
There is no way you can protect a consumer secret.
@Joseph
server somewhere? that could be trivially intercepted.>>
Srikanth
Paul Gallagher
If you are distributing a server application, then putting the application registration instructions in a README is perhaps not such a big deal. Desktop/mobile apps are another matter though.
It's also worth saying that even if you could find a secure way of distributing a consumer key, you gotta ask if its even the right thing to be doing. I think not. Definitely not. Once the code is "out there", I don't want everyone authenticating with _my_ application registration and consumer key (at this point, I have no way of knowing that the app hasn't been modified in some way that I do not approve of. I risk one rogue instance getting me blacklisted and in turn disabling every other instance. Great, DoS by design).
Since the README approach is such a big no-no for client-side/consumer apps, the question I'd be asking is: where is the API for performing an initial application registration/bootstrap?
i.e. an example of the scenario I have in mind (considering a desktop app):
- user installs the app
- on first use, directs the user through online login to twitter and automatic oauth client app request
- newly registered application credentials transparently returned to the application (securely; somehow)
- application saves the (instance specific) application key and consumer secret; uses these for standard oauth in subsequent sessions.
Does anything along these lines already exist? If so, I haven't stumbled upon it yet.
Regards,
Paul
http://tardate.com
Chris Babcock
Building an enduser distribution is somewhat to entirely different.
First, there really isn't any point to using OAuth for a client unless
the client code lives on the network. The whole advantage of the scheme
is that the user does not have to disclose credentials to one or more
third parties. An application that doesn't access a third party network
should use basic authentication over HTTPS.
If Twitter decides to eliminate basic auth then the correct way (from a
security stand point) to implement OAuth would be to obtain a separate
key for each client. I don't see the current OAuth spec as being set up
to handle bulk key assignments, but you can't distribute a single key to
multiple clients outside of your network. Whether or not the app is
Open Source is a non-issue; It's complete FUD-rucking to imply that it
is any diffent distributing a secret key in a close source app than it
would be to do so in an open source app.
What happens if you try to use a screwdriver as a hammer? It's the same
thing here only someone had to drag Open Source into as if that made
any kind of a difference. To top it off, the OP had a complete
misunderstanding of the consequences of key disclosure. "A Spammer
could use it and get your app banned..." as if that's of any
consequence compared to the users' accounts getting hijacked by apps
impersonating your client.
And what's with keeping score as if Open Auth and basic were a couple
of talking tools on Disney Channel having some sort of ludicrous
rivalry?
Chris Babcock
Chris Babcock
srikanth reddy <srikanth...@gmail.com> wrote:
> @chris
> You cannot ask every user to get new consumer token/secret.
> There is no way you can protect a consumer secret.
I did have a blind spot operating here. When someone says, "Open
Source," I'm usually thinking server software not Joe's ShareWare.
Since we were talking about source code distribution, I wasn't even
thinking about user binaries.
> @Joseph
> <<fetch the key and secret at runtime from a secure
> server somewhere? that could be trivially intercepted.>>
> As far as i know this is the best way to hide the consumer secret.
> This will not stop a determined user who try to intercept the keys
> but you have the option of changing your key/secret values( for a
> consumer) periodically. Other options are obfuscating/encrypting
> secrets at client side (again it will not stop a determined user).
> But the key management is difficult here as you have to download the
> app everytime(or whenever the risk of keys being compromised is high)
It's worse than that. You don't even have to intercept the key, just
use the application itself to obtain tokens for other users' accounts.
How are they going to tell the difference between their copy of TweetX
and someone elses' in their auth dialogs?
Chris Babcock
srikanth reddy
It's worse than that. You don't even have to intercept the key, just
use the application itself to obtain tokens for other users' accounts.
How are they going to tell the difference between their copy of TweetX
and someone elses' in their auth dialogs?>>
The worst you can do is use the key/secrets to trap new users. Even if you assume the app
is storing tokens locally, it does only for that desktop user.True there is a risk if some one steals his access tokens but he is not completely wiped out as he still has the option of revoking the access to the app.
Srikanth
Chris Babcock
srikanth reddy <srikanth...@gmail.com> wrote:
> <<
> It's worse than that. You don't even have to intercept the key, just
> use the application itself to obtain tokens for other users' accounts.
> How are they going to tell the difference between their copy of TweetX
> and someone elses' in their auth dialogs?>>
>
> Sorry. I didn't get this. How are you going to obtain tokens for
> *other * users?
It's a social engineering attack.
If the app contains code to authorize new accounts and all the copies
of the app use the same secret key then Twitter will not be able to
tell the difference between a legitimate token request and a spoofed
request. Send out enough requests and eventually a user will approve
your token giving you complete access to their account.
Chris Babcock
Bill Kocik
On Aug 17, 4:55 pm, Chris Babcock <cbabc...@kolonelpanic.org> wrote:
> Silly me. I thought someone was talking about distributing source code.
> Building an enduser distribution is somewhat to entirely different.
application - open source or closed". I think you're seeing the same
challenge now that many of the rest of us are. Distributing an OSS
server-side app is a cinch; as you said, you put "Go get yourself some
Twitter OAuth credentials" in the README for developers who are using
your code as the basis for their app. The hard part is distributing an
end-user ready desktop app.
OAuth's out-of-band auth flow is intended to solve this for non-
browser based applications, but I think how the developer of such an
app protects their client credentials was sort of "left as an exercise
for the reader". The trouble is, it's pretty much impossible. The
problem we were left to solve appears unsolvable.
This means someone has to go back to the drawing board. This is a
really big, fatal flaw in OAuth that's going to have to be fixed
somehow.
srikanth reddy
Just to make my question clear
How are you going to obtain tokens for other users using the application itself?
The worst you can do is use the key/secrets to trap new users by building a brand new app
(with the stolen consumer key/secrets. And new clients have to trust this app before downloading)
I am just trying to understand why this approach(of getting consumer secrets/tokens from a server which changes the values periodically)is worse than storing the keys at the client itself.
<<If the app contains code to authorize new accounts and all the copies
of the app use the same secret key then Twitter will not be able to
tell the difference between a legitimate token request and a spoofed
request>>
<<Send out enough requests and eventually a user will approve
your token giving you complete access to their account>>
Just need clarification on this statement
"You don't even have to intercept the key, just
use the application itself to obtain tokens for other users' accounts"
Jason Martin
John Kristian
You might might find that informative. Some highlights:
An OAuth Consumer that's deployed to users' desktops or mobile devices
can't keep a secret. One should assume its consumer key and consumer
secret will be known to attackers. Consequently, OAuth doesn't really
assure the user that he's authorizing a legitimate copy of the
Consumer software. (There are other ways to assure this; for example
the user might trust Apple's app store.)
Such a Consumer should avoid revealing a user's token secrets to other
users or other applications on the same platform. I've heard that the
iPhone Keychain is useful for this purpose. There's no need to hide
token secrets from their user (although the user should be discouraged
from revealing his token secrets to other users).
OAuth provides some value in this situation. It enables the Consumer
to avoid storing the user's password, and avoid transmitting the
password with each request to the Service Provider. (Instead, it
stores an access token secret, and signs each request.) It enables the
Service Provider to revoke permission for each Consumer individually,
without changing the password.
Joseph Cheek
the app authenticates itself to the provider.