You can lead a horse to water ...
On Thu, Jul 30, 2009 at 7:07 PM, Bradley S. O'Hearne <brad.ohea...@gmail.com
> 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.
> On Jul 30, 2009, at 11:52 AM, Duane Roelands wrote:
> > Brad,
> > 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:
> >> 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
> >> On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote:
> >>> On Jul 28, 3:27 pm, chinaski007 <chinaski...@gmail.com> wrote:
> >>>> I suppose this is not so weird. Users are accustomed to giving
> >>>> user/
> >>>> pass information even to "foreign" apps.
> >>> Agree. Anyway, if user just setups desktop app to his computer, he
> >>> 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