There has been a small but vocal brouhaha brought to light by chatty Robert Scoble over Twply, a new Twitter-to-email service which recently launched. The problem started out as the service seemingly spamming Twitter but the conversation has quickly changed gears in to a full-fledged Twitter security incident.
As part of a means of promoting the service, framed in the context of “supporting” Twply, when you first sign-up for the service it sends the following tweet from your Twitter account:
Just started using http://twply.com/ to get my @replies via email. Neat stuff!
Twply clearly states on their front page, directly beneath the Twitter username and password fields, “Support Twply on your first login?” followed by a couple of radio buttons: Yep, go ahead! (default) and No thanks!.
The problem is that nowhere is it clearly defined what functions selecting “Yep, go ahead!” will perform. If Twply had clearly spelled out ahead of time that by selecting the default the service will send a tweet from your account in support of Twply then the amount of anger would be minimal and misplaced. The onus would have been on the user. But because Twply failed to clearly demonstrate what selecting that option will do, the spamming onus is on them.
Outside of that issue, there is a larger one at play. Twply asks users to hand over their Twitter username and password. As of this writing, nowhere on the Twply web site is there a link to a privacy policy or terms of service. Nothing stipulates what Twply will do with your Twitter credentials.
Why the hell would you give this unknown, untrusted service your Twitter password? Most people reuse the same password across a variety of web sites. By handing over your username, which is probably the same if not identical on another service, and password you have now given the unknown, untrusted Twply folks the keys to your kingdom.
Based on the nature of the Twitter API, the passwords given to Twply have no choice but to be stored unencrypted. As far as I know Twitter’s API does not make use of hashed passwords. When I coded MailTwitterPHP a couple years ago, the API required unencrypted passwords.
Twply’s response to the password encryption inquiry is incredulous, stating passwords are stored encrypted. If this is the case, the passwords are not hashed but encrypted with a two-way algorithm, which means the passwords are just as unsafe as if they were unencrypted. The reason should be obvious.
More importantly, why doesn’t Twitter support OAuth? With such large penetration, and most use through third-party applications, it is amazing that Twitter can get away with not supporting OAuth or a similar authentication scheme. Flickr is the epitome of a well crafted third-party authentication scheme which can properly protect your account without giving a unknown, untrusted entity full and unfettered access to your data.
To summarize, there are a few takeaways here:
- In this day and age, if you are giving unknown, untrusted third-parties your password then you have nobody your yourself to blame if, and when, your online identity is stolen or hijacked.
- Twitter should be ashamed of themselves for not implementing some form of third-party authentication, such as OAuth.
- If it walks like a duck and talks like a duck, then surely it’s a duck. Twply looks and acts very shady. Do the math yourself.
- I see absolutely no way to walk away from Twply. The site simply stores a username and password, with no type of account management page whatsoever. Twply is like Herpes and luggage – you have it for life!
Some of the questions I would like to see Twply answer are as follows:
- Why does Twply have no privacy policy posted?
- Why does Twply have no terms of service posted?
- Why does Twply require Twitter passwords when you can merely convert user RSS feeds and email those. Finding @replies is as easy as using the Twitter API, which does not require a users password for most functionality.
- Does Twply store Twitter user passwords unencrypted, encrypted or hashed?
- How does a user who signed up for Twply opt out of the service at a later time?
What do you think? Are people overreacting or is this issue a valid complaint? What are your thoughts?
Meanwhile, people can't afford to buy their medication, genocide is a reality, and the world's losing its economic foothold.
Thanks for the important update.
January 2, 2009 @ 06:28
When you put it in that type of perspective, of course this is as insignificant an issue as any. I just happen to find medication, genocide is a reality, and the world's losing its economic foothold topics I am unable to write about, unless I'm writing the most depressing drama around.
Maybe I should write about a depressed stock broker who is strung out on Ativan and Paxil, who decides to go on a killing rampage on Wall Street, ultimately leading to a foiled US coup but causing massive genocide throughout his campaign to make the world page for his 7 digit bank account disappearing overnight.
Whatcha think? :P
January 2, 2009 @ 06:41
But in all srsns, as shady as it is, this was inevitable.
People do some stupid shit.
January 2, 2009 @ 06:29
Hopefully we can inform some people about what you and I consider obvious security risks which are not worth taking. Or, more importantly, we can pressure developers to build secure methods for third-party interaction with your data on these web sites. Methinks that would be the best option, no?
January 2, 2009 @ 06:43