Consider using OAuth over username/passwords for Twitter Actions (and possibly other web based services that supports OAuth)

[GoogleCodeExporter]

Just read this on the twitter website when studying the feasibility of OAuth 
for issue 47:

http://apiwiki.twitter.com/Authentication

Basic Authentication sends user credentials in the header of the HTTP request. 
This makes it easy to use, but insecure. OAuth is the Twitter preferred method 
of authentication moving forward - come June 2010, we'll be turning off Basic 
Auth from the API.

There is also a great discussion about using OAuth in mobile apps here:
http://stackoverflow.com/questions/1934187/oauth-secrets-in-mobile-apps

Basically, they are having a similar dilemma I had on issue 47.

Original issue reported on code.google.com by renc...@gmail.com on 22 Jun 2010 at 3:44

[GoogleCodeExporter]

Original comment by renc...@gmail.com on 22 Jun 2010 at 5:19

• Changed state: Started

[GoogleCodeExporter]

Original comment by case.and...@gmail.com on 6 Jul 2010 at 2:22

[GoogleCodeExporter]

Even though the username/password seems to be working up till now, I was 
thinking if we should implement this for security reasons. Even if we encrypt 
the passwords, there is still a risk of the attacker being able to recover it 
especially since we have our code available in the public. I think having the 
password compromised is worse than the token being compromised because users 
tend to reuse passwords (or it's derivative) in different applications. I have 
never tried this, but I have read that the user can freely revoke/renew the 
OAuth token as he please, if he believe it has been compromised.

The consequence of implementing this though, is that the existing rules with 
Twitter (and Gmail, since I am thinking of implementing this on Gmail too) 
won't work anymore because a new authentication method is being used. This 
means that the existing users should need to setup the Twitter account once 
again if they upgrade to the newer version.

I personally think that this little inconvenience is justifiable. And we should 
probably do this while the user base is small... What do you guys think about 
this?

Original comment by renc...@gmail.com on 14 Jul 2010 at 3:47

[GoogleCodeExporter]

You'd still have a username/password account management available for other 
services that don't provide OAuth support right?

Ideally I think we'd want to provide a way to nicely "invalidate" rules that 
have been obsoleted by some sort of upgrade.  I can see us needing this in the 
future for other things as well (third party plug-in being removed for 
example), so it may be worth writing this "invalidate" rule functionality.  
What I'm thinking of is that the upgrade does something like this:
1) Search for rules that are affected
2) Marks them as invalid
3) The UI on View Rules would then provide an indication that a rule has been 
invalidated by possibly putting a line through the text for that rule and 
graying out the checkbox.  The user could then View the rule, but be unable to 
modify it, except for deleting it.

This would require adding an "invalid" column in the Rule database table.  
Spawn a new issue to discuss this?

Original comment by case.and...@gmail.com on 14 Jul 2010 at 4:12

[GoogleCodeExporter]

I agree with ren on password being compromised vs token being compromised 
argument.

about invalid rules, this invalid column would be used only once, that is from 
the moment of installing app to the point where users set up account. so maybe 
we could get away without it. 
once users set up, say, twitter account, all the twitter rules should become 
valid.

Original comment by sv767%ny...@gtempaccount.com on 14 Jul 2010 at 5:04