By third party i meant some one like 'TwitViewer'  (some one who would pay
and register their app in appstore and trick the users to believe in them
but who do not work the way they were expected to )

<<You are still keying in your password within the app, in code that the
developer of this so-called "rogue" app developed. >>

NO. With OAuth you are not keying in your password with in the app.

<<the developer could still intercept keyboard events and capture your
password that way. >>
I have to agree with this particularly for desktop apps (But app store
admins catch this.)

<<That said, it seems that the real danger on the iPhone is storing a
password, not having the device as a whole password protected, and then
losing your device. Someone can then go into your phone, and Twitter related
app, and have direct access to your account (which I believe would still be
a danger with OAuth tokens).>>

Now assume your third party app is legitimate and supports basic auth and is
storing password. If some one steals your iphone he could use your password
(doesnt matter whether it is stored encrypted)  as well as your app to
post/delete tweets.  With OAuth it is limited posting/deleting tweets. This
is not to say that Oauth solves all the problems of storing passwords.(It
has its own problems of storing consumer secrets)

If you are not storing password then  basic auth over https from a trusted
app is absolutely fine.

Personally i believe OAuth does not have much to offer for desktop apps.The
debate goes on.
Sooner or later twitter is going to remove basic auth support. We have no
choice but to move on.

On Tue, Aug 11, 2009 at 8:27 PM, Bradley S. O'Hearne <brad.ohea...@gmail.com
> wrote:

> Srikanth,
> Thank you for your thoughts -- good ones. Responses:
>
> <snip>
> But what if the app was developed by some thirdparty devs? you never know
> whether the password is stored or logged some where.
> </snip>
>
> I'm not sure who the "third party" is relative to -- if you are the user of
> an iPhone app, *every* app was developed by a third party. If you are the
> developer of the app, and you are worried about development you've farmed
> out to a third party, well, that's not an authentication issue -- that's a
> personnel / business problem. You shouldn't be publishing code which you
> aren't aware of what it does.
>
> I made reference to this in another thread, but when a user voluntarily
> downloads an iPhone app and puts it on their device, and then runs it,
> they've explicitly demonstrated a level of trust for that app. If they are
> concerned about it being a rogue app, then downloading the app, putting it
> on their device, and running it seems inconsistent with a true concern about
> it being a rogue app.
>
> But furthermore, let's assume there was some concern about password entry
> -- I do not see how OAuth saves you at all. You are still keying in your
> password within the app, in code that the developer of this so-called
> "rogue" app developed. The developer could be phishing with a spoof OAuth
> web page, but even if the OAuth page is authentic, the developer could still
> intercept keyboard events and capture your password that way.
>
> That said, it seems that the real danger on the iPhone is storing a
> password, not having the device as a whole password protected, and then
> losing your device. Someone can then go into your phone, and Twitter related
> app, and have direct access to your account (which I believe would still be
> a danger with OAuth tokens). So the solution seems to not be the means of
> authentication, it seems to be whether a password is stored or not, and
> whether it is transmitted securely.
>
> Brad
>
> On Aug 11, 2009, at 12:02 AM, srikanth reddy wrote:
>
> My thoughts
>
> OAuth wasn't meant for Desktop apps. Its for third party apps (consumers)
> who try to request a protected resource from a service provider  on behalf
> of end users. Typically a consumer offers one kind of service and a service
> provider offers a different service. As you know the advantage of OAuth is
> you are not giving away your password to consumers.
>
> For desktop apps (iphone apps) it is perfectly fine to use basic auth over
> https  But what if the app was developed by some thirdparty devs? you never
> know whether the password is stored or logged some where. There is always an
> element of risk. OAuth solves this problem to a little extent. You are
> giving your password only to twitter and the consumer/app gets the token.
> Even if a rogue consumer steals this token you at least have the option of
> revoking the access to this consumer. But if password is stolen you cannot
> do anything.
>
> As you know OAuth primarily deals with Authorization and Authentication is
> secondary. So its not a question of comparing it with Basic Auth over HTTPS.
>
> These are just my thoughts.
>
> Srikanth
>
> On Tue, Aug 11, 2009 at 2:46 AM, Bradley S. O'Hearne <
> brad.ohea...@gmail.com> wrote:
>
>>
>> All,
>>
>> I don't want to kick this subject to death, as there was a lengthy thread
>> on general OAuth vs. Basic auth -- I want to restrict this question strictly
>> to the scope of iPhone apps. Having pored over the OAuth vs. Basic
>> authentication process, I have a question, given the following assumptions:
>>
>> - The iPhone app is communicating directly with Twitter, i.e. not through
>> some third-party means.
>>
>> - The iPhone app requires authentication at the beginning of each
>> application runtime (i.e. each time the app is run the user has to type in
>> their password).
>>
>> - The password is cached only in memory, for the life of that specific
>> runtime (i.e. when the user quits the app, the password is released).
>>
>> - The password is NEVER persisted anywhere, i.e. never stored to disk.
>>
>> - All network communication with Twitter takes place over HTTPS.
>>
>> If all of those things are true in an iPhone app, how is OAuth superior in
>> any way to basic authentication from a security standpoint? Furthermore,
>> given having to introduce a foreign UI element and extra authentication
>> steps over the web, could OAuth even be considered inferior when evaluated
>> as a whole as an authentication means for the iPhone, when app branding,
>> integration, and ease of use are considered?
>>
>> Mind you, the purpose of this post is not in any way to incite a religious
>> war or stir the pot, it is to definitively establish the true pros and cons
>> of each authentication means within the specific use case of the iPhone
>> only. Many of the other OAuth / Basic auth threads are somewhat overridden
>> with personally charged statements that I'd rather ignore them.
>>
>> Anyway, your constructive views are most appreciated.
>>
>> Regards,
>>
>> Brad
>>
>>
>>
>
>

Reply via email to