Why would it be hosted in your app? Why can't you open Safari?

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

> Srikanth,
>
> 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 )
>
>
> That's not a valid use case for faulting the authentication mechanism. The
> user has already demonstrated an explicit level of trust in the app. That's
> like saying that if you carelessly trusted someone with your ATM pin number
> prior to them performing a fraudulent transaction with your ATM card, that
> it is the ATM machine's fault. It isn't. The problem there is that you
> trusted a source you shouldn't have. Same thing with executable files
> containing viruses sent to you via email -- if you choose to run a rogue
> executable on your computer, it isn't the computer's fault for running it.
>  It is the user's fault for running the executable.
>
> NO. With OAuth you are not keying in your password with in the app.
>
>
> No? How is it then that you initially get logged into Twitter -- yes, it
> might be a Twitter web page, but it is still hosted within your app, right?
> So whose to say the web page you are viewing is *really* an OAuth page, if
> you aren't going to trust the app? OAuth doesn't protect from that.
>
> 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)
>
>
> You ignored one of my assumptions, which is that passwords aren't stored at
> all. If basic authentication is used, and passwords are never stored, it
> doesn't matter if someone steals your iPhone, they cannot get access to your
> Twitter account. With OAuth, they would still have a degree of access to it,
> unless I'm missing something.
>
> Brad
>
>
> On Aug 11, 2009, at 10:33 AM, srikanth reddy wrote:
>
> 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
>>>
>>>
>>>
>>
>>
>
>


-- 
Internets. Serious business.

Reply via email to