Janole

None, taken. I am a network sysadmin, developer and ultimately businessman so I 
do know a little bit about how they are all related.

I understand you are in a slightly different position having to deal with 
xAuth. However, xAuth is not a secure system in itself. Any system that passes 
a user and password through a third party cannot be secure. Yes you are 
"supposed" to discard the info after the initial tokens are exchanged and 
received back, but there is no proof that actually happens. A third party still 
had access to my username and password.

>From a purely network and security standpoint xAuth should be done away with 
>in lieu of newer more secure methods where no one other than myself and the 
>service I am accessing know my password. For that matter, the service 
>shouldn't know my password either beyond when I submit it as it should be 
>hashed and that token saved instead of the raw password. Authentication then 
>involves comparing two hashes instead of two raw text passwords.

In your case you are limited by the the underlying OS from achieving a 
traditional OAuth flow. Your work around sounds like it will suffice and is no 
less potentially insecure than the existing if properly setup.

You say you "know nothing" about your users under the current system, and 
that's the way it should be. But that is you in your specific case, being I'm 
sure an honest developer. Allowing insecure methods to continue though, lowers 
the security of the whole. It only takes one bad app to screw a bunch of users 
and ultimately it's Twitter who would have the proverbial egg on the face. The 
app developer would be banned and forgotten.

I'm not happy about this change being forced down everyone's throat so quickly 
as much as the next developer. In my option more levels of privacy and security 
should have been rolled out all at once instead of this one change. This change 
fixes one minor problem when a more broad change to add finer-grained 
permissions could have been rolled out and affected third-party developers not 
much more than this current one. 

I also suspect as you hinted there may be other more selfish reasons partly 
behind such changes and have written several articles about the subject. 
http://bit.ly/lFZuZC

But as I said... from a purely network and security standpoint the changes are 
sound. Economics and competition may be a different story.



damonp
On Thursday, May 19, 2011 at 11:14 AM, janole wrote: 
> Damon,
> 
> with all due respect and in all politeness, have you even read what
> this thread is about?
> 
> Do you really think an xAuth application - that knows the users full
> credentials - is getting more secure without the right to access
> direct messages? I mean ... really ;-)
> 
> We both do not know why Twitter tries to introduce this change. I have
> a feeling what it is about, but it's definitely not about user privacy
> or security if it comes to xAuth applications.
> 
> OAuth apps, granted, different story and I could live with that
> change. But as I am not using OAuth, I leave it to the developers
> affected to voice their concerns. They should know better.
> 
> For me, who needs to have xAuth access to provide my users access to
> Twitter - actually to provide it to the Symbian platform ( biggest
> smartphone OS worldwide, 2010 ... ) - these changes are not good.
> 
> And my users do think the same.
> 
> Most of my users love Twitter and I try to provide a client that makes
> them use Twitter a lot - because I love Twitter, too ( well, better to
> say, I am addicted to Twitter. )
> 
> I just don't see any reason why this privacy related change couldn't
> be implemented in a way which does NOT break so many applications.
> 
> We are also talking about preloaded mobile apps here - apps that
> cannot be changed quickly - or cannot be changed at all.
> 
> My planned work-around for this xAuth change ( I still hope it is
> being reverted! ) will include running a Twitter service for
> authentication. That way, I would have access to my users' OAuth
> tokens. I don't like that. It imposes a great risk to me and my
> servers being hacked. So far, I do not know nothing about my users via
> my Twitter client. No password, no credentials. I like it that way.
> More secure for my users.
> 
> As for Linux, yes, we all know Linux is way more secure. That's why
> companies like Sony and Gawker are running their services on top of
> Linux servers ... okay, forget about that one ;-)
> 
> Cheers & please don't feel offended,
> Ole ( @janole / @gravityapp )
> 
> On May 19, 2:44 pm, Damon Parker <cartmet...@gmail.com> wrote:
> > In any security or permissions context the default should be the most 
> > secure and least amount of permissions to get the job done. That is 
> > Computer and Network Security 101.
> > 
> > A user must explicitly configure more loose permissions on their own after 
> > understanding the implications. This is the way computer network security 
> > is and always has been done. This is part of the reason Linux/Unix et al is 
> > way more secure than Windows ever could be.
> > 
> > Just because a user isn't sophisticated enough to configure more lax 
> > permissions to get their needs met isn't a reason to default to lower the 
> > security context. This is what FB did _completely_ wrong when they updated 
> > their permissions system. They defaulted everything to being completely 
> > open, accessible and public for purely selfish reasons. They wanted to keep 
> > more user data 100% public thus increasing the amount of public and free 
> > (as in $ to FB) user-generated content created every day. More pageviews, 
> > more pics, more comments equals more ad revenue for them.
> > 
> > Even though it's a pain in the ass for developer's to rework their apps and 
> > re-auth it's the right thing to do for the end user and the overall safety 
> > of the community.
> > 
> > I commend Twitter for doing the right (even if unpopular) thing in this 
> > case.
> > 
> > Damon
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Thursday, May 19, 2011 at 1:50 AM, janole wrote:
> > > Hi Matt,
> > 
> > > thanks for your feedback. I think the following paragraph can't be
> > > generalized, though:
> > 
> > > > > Why will you not grandfather existing applications into DM access?
> > 
> > > > Grandfathering all existing read/write tokens assumes they all wanted
> > > > access to DMs. The feedback we’ve had from users and developers tells
> > > > us otherwise. We want to give users the opportunity to make an
> > > > informed choice.
> 
> -- 
> Twitter developer documentation and resources: https://dev.twitter.com/doc
> API updates via Twitter: https://twitter.com/twitterapi
> Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
> Change your membership to this group: 
> https://groups.google.com/forum/#!forum/twitter-development-talk
> 

-- 
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
https://groups.google.com/forum/#!forum/twitter-development-talk

Reply via email to