Unless I'm wrong (it happens), I believe you can do everything the API
offers with OAuth that you can currently do with basic auth.  But even
if that isn't true, preventing basic auth from allowing username/
password changes is a much more direct solution (and easier) than
forcing an OAuth implementation to solve that issue.

Anytime you enter your credentials, regardless of where, you open
yourself to being snooped.  I believe that is far less likely when
communicating with YOUR app on YOUR computer, than it is via a browser
over the open Internet to a 3rd party that may or may not be who you
think it is...

On Apr 26, 7:49 pm, philip crawford <philipha...@gmail.com> wrote:
> With a users twitter password, I can take over their account by
> changing email & password.  Can I do that with OAuth credentials?
>
>
>
>
>
> On Mon, Apr 26, 2010 at 7:43 PM, Ron B <rbther...@gmail.com> wrote:
> > Where end-user credentials are stored is entirely up to the end-user,
> > as is who they choose to share the information with.  OAuth does not
> > and cannot address this, as it shouldn't - and neither should Twitter
>
> > When a user types their username/password on the Twitter authorization
> > screen, they are using someone's browser on someone's computer either
> > of which could harbor malicious software that could capture what was
> > typed, and are communicating these credentials over the open Internet
> > using at best nothing more than the https basic auth uses.  In
> > addition, "training" users to become accustomed to providing their
> > user credentials outside of their apps to requests made over the open
> > Internet makes them a lot more susceptible to phishing attacks.  How
> > exactly is this then "better" security than basic auth?
>
> > The only "real" advantage to using OAuth is more application access
> > control and protected shared user access between application
> > platforms.  There are no real tangible advantages for the end-user.
> > With basic auth, all an end-user had to do was tell the app their user
> > credentials.  With OAuth, they have to leave their app to tell
> > Twitter, wait for Twitter to tell their app, and then return to their
> > app to continue the process.
>
> > At least with XAuth, the user can continue to tell their app their
> > user credentials and have all this OAuth stuff handled behind the
> > curtain for them.
>
> > I understand the very compelling reasons why Twitter wants to convert
> > to universal OAuth access.  But let's quit spinning OAuth as this
> > "great new security enhancement technology" that will benefit end-
> > users  It's not.  It wasn't even meant to be.  It was just meant to
> > help the Twitters of the world communicate end-user information among
> > each other without having to share their end-users' credentials.
>
> > On Apr 26, 7:08 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> >> > What's the latest schedule for increasing the allowed API call rate for
> >> > oAuth users? That seems to have been lost in the shuffle.
>
> >> unclear - we're actively working with our infrastructure and operations
> >> teams on capacity planning specifically so we can increase the rate limits.
>
> >> > Also, is there any advantage to xAuth over the desktop PIN oAuth scheme
> >> > (for a desktop application)? I'm putting together a proposal and can't 
> >> > see
> >> > any real advantage to it on the desktop, especially since I have the 
> >> > oAuth
> >> > code done, thanks to Marc Mims' Net::Twitter. ;-)
>
> >> personally, i would -love it-, if everybody just used the oauth web 
> >> workflow
> >> so that none of you even see a user's username/password.  that would make
> >> the web more secure.  i'm even soliciting suggestions on what we could do 
> >> to
> >> make the web workflow better.  i understand, however, that the PIN workflow
> >> can be off putting for some users.
>
> >> so, implementing oAuth instead of xAuth would make me happy - but i doubt
> >> that's a motivation for most developers.
>
> >> --
> >> Raffi Krikorian
> >> Twitter Platform Teamhttp://twitter.com/raffi
>
> >> --
> >> Subscription 
> >> settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
>
> --
> imby - in my back yard
> An Experiment in Local Professional 
> Networkinghttp://madison.imby.info/p/Philip.Crawford

Reply via email to