Sean Coates: PHP, Web (+Beer)

This morning, via a colleague, John, I stumbled on a service called gdzlla that allows you to use Flickr as an alternative to the other de facto Twitter media posting services (twitpic, yfrog, etc.), from Tweetie on the iPhone. The idea is great, but unfortunately, the implementation is dangerous.

Intrigued by an integrated media-posting solution, I started browsing the gdzlla site, and one of the first pages I saw grabbed my attention... in the wrong way.

The idea of random web sites asking for credentials is hardly a new concept—especially when it comes to Twitter. Almost a year ago, news broke about a now-defunct site called Twitterank that was created by @brianoberkirch to illustrate the danger of carelessly sharing Twitter credentials with third parties. Since then, Twitter has implemented OAuth to avoid this exact scenario, but uptake has been slow: many third parties who provide a Twitter-related service still require users to submit their Twitter credentials to authenticate.

What struck me about gdzlla's login page was the text at the bottom of the form: "(Your password gets hashed, we won't ever know it)." Thinking about ways to implement this (the password could be hashed in JavaScript, before the form is submitted, for example), I turned on Firebug, and discovered that the value is actually submitted with the form, in plaintext:

I suspected that the gdzlla guys were not actually being malicious here, and would actually hash the value prior to storage on their side, but the text was misleading at best, so I tweeted about it:

http://tr.im/D78s "(Your password gets hashed, we won't ever know it)" <-- misleading at best; lies at worst.

coates

John noticed that I linked to the form processor page, which didn't work properly, so be brought that part to gdzlla's attention:

@gdzl_la link from @coates http://bit.ly/2qVAUb http://bit.ly/2jDBHS gave this page http://bit.ly/3eIvMV Edge case, likely, but undesirable.

JFSIII

This kicked off a conversation with @gdzl_la:

@coates lies? how so? Don't want to pry, but I get the feeling you're making some assumptions.

gdzl_la

@gdzl_la that form submits my password to your server. It's not hashed before it's sent, so it's perfectly possible for you to see it.

coates

@coates We do filter passwords out of the logs, so while possible, yes; we've taken steps to make sure that we don't ever see them.

gdzl_la

@gdzl_la it's still bad form. You may be honest people, but there's no proof (I'm not calling you dishonest; just possible). Use OAuth.

coates

@coates Agreed. The unfortunate truth is that tweetie only sends user/pass, so it's the only option for the time being. http://bit.ly/TZ9EG

gdzl_la

@gdzl_la sadly, you're right. Tweetie is doing it wrong. The text on your sign-in page is still wrong, though (you can see password). )-:

coates

Their reply shed some light on exactly how they're integrating with Tweetie. The iPhone app allows users to supply their own custom image service URL. When submitting media, if this value is filled in, Tweetie sends the raw image data (and other information, see below) to the third-party URL and expects to receive a URL where the media is hosted, in return.

This type of integration is actually a really great idea. More apps should allow customization of third-party services. It's exactly how web services should be used.

Unfortunately, as @gdzl_la pointed out in our conversation, Tweetie's actual implementation of this feature is horribly insecure, and prevents gdzlla from using OAuth—gdzlla doesn't even use your Twitter credentials to post to Twitter, that's Tweetie's job (as indicated in their instructions).

So, why does gdzlla require users to submit their Twitter credentials if they're immediately transforming your password into a hashed form that would prevent them from actually using it to access the Twitter API? The simple answer is that this is the only way for them to integrate with Tweetie's poor implementation of a great feature.

gdzlla presumably collects your Twitter credentials and then has you authenticate against the Flickr API. It then links the accounts to associate your Twitter and Flickr accounts, on the gdzlla side.

The tragic flaw in all of this is that Tweetie uniformly sends the user's Twitter credentials to the custom image URL as part of the image hosting request. There's no other way for gdzlla to associate the incoming data with a particular Flickr account.

Tweetie's instruction page says that it will send the following as POST data:

• username - Twitter username
• password - Twitter password (plain text, thus HTTPS is strongly recommended, and may be required by future versions of Tweetie)
• (other information such as the data for the media)

There's really no good reason for Tweetie to do this. They could just as easily ask the user to supply credentials for the third-party media hosting service. In fact, they absolutely should ask the user to supply this information on the setup page. Providing a user's Twitter credentials to third-parties is irresponsible at the very least, and leaves legitimate third parties in a pinch because there's currently no good way to implement authentication in this system—not even OAuth will save the day. (This also leads to non-security usability problems with services like gdzlla—handling password changes must be a huge headache for them.)

Hopefully the Tweetie developers will recognize this problem and fix it. In the meantime, my suggestion is to avoid using any service that implements the Password Anti-Pattern, even if you trust them.