I’m in ur 4sq, snarfin ur password — Part II

In Part 1 of this discussion on Foursquare’s mobile applications, I demonstrated how the Foursquare Android app utilizes HTTP basic authentication over plaintext HTTP. Another intriguing aspect of all of this comes in the form of a snippet from the Foursquare API documentation:

For most methods, we require either Basic Authentication or OAuth Authentication. OAuth is the method we prefer you use so that clients do not have to hang on to usernames and passwords but can initiate requests on a user’s behalf via a special token.

As mentioned in the above snippet, OAuth is basically a protocol for authenticating and authorizing an entity (such as, say the Foursquare Android app) to perform an action on behalf of a user — without having to know the user’s credentials. OAuth can also provide additional protections such as signatures, timestamps, and nonces (to prevent replay attacks). Why, the very concept of the OAuth signature was designed for non-HTTPS communications. As seen in Part 1, the Android application uses Foursquare’s non-preferred method of authentication.

Looking at the source code of the Foursquare Android app shows that OAuth support exists, but is incomplete (and clearly not used):

This behavior doesn’t end with the Android application, though. Shortly before I drafted Part I, Foursquare announced a new version of their BlackBerry app. I promptly downloaded the app, installed it in a BlackBerry simulator, fired up Wireshark, and observed the same activity all over again:

(Anecdotal evidence suggests that the Foursquare app on iPhone does this, too. I haven’t investigated the new Windows Mobile application.)

This behavior is symptomatic of larger problems that pervade mobile applications: 1. the reliance on simple authentication mechanisms (e.g. usernames and passwords), and 2. the failure to adequately protect those mechanisms (see CWE-522 if you’re so inclined). As noted before, OAuth is the preferred method for API authorization on Foursquare, yet the developer(s) of these mobile applications elected to use the suboptimal Basic Auth method. It may seem that I’m picking on Foursquare, but this is really par for the course. As development shops race to shove their applications out the door, while sifting through the nuances of each mobile platform (RIM, Android, iPhone, BREW, Symbian, etc.), simple AuthN and AuthZ schemes will continue to pervade. Here’s to hoping that changes soon.

(Quick note: I’d originally planned a much more grandiose post, but due to time constraints decided to just call this done rather than complete. If I’m so inclined, time permitting, I’ll consider following up with a Part III)

Both comments and trackbacks are currently closed.