One of the more interesting features for Blipfoto I’ve been quietly working on is an API. The publicly-available data such as journal entries and user profiles is easily done, but where things get tricky is the authenticated side of things. A main benefit of a 3rd party application would be the ability to upload journal entries from outside the site; but of course, this opens up a whole new can of worms.

Its common enough to use techniques such as signing messages with secret keys, nonces (randomly generated strings that are only used once) and time synchronisation to provide a level of security while preventing things like replay attacks. The most difficult issue to deal with is the problem of trust. If, for example, I download an iPhone app and it prompts me for a username and password, how can I be sure that this application is trustworthy? How do I know it won’t steal my details?

Bouncing around the iPhone

While the iPhone is not the only example of this issue, its a good platform to show some of the attempted solutions. An emerging practice is to jump out of the iPhone App into Safari for authentication; the user provides their details to the host web application, which then asks if the user really wants to let the App handle their account. The user’s details never touches the 3rd party. If the user agrees, a custom URL scheme is used to relaunch the App. While this could all be done inside the 3rd party App, there’s no way for the user to know they are talking to the host site and not a faked site. Going to Safari mitigates this problem somewhat as the site URL is visible (although even this could be faked with some effort).

This process is along the lines of OAuth, where the host application controls access to the account, never the 3rd party application. I like the idea, but as with many secure protocols, falls down at the user experience.

The Pownce application utilised this system and noted that 40% of users who downloaded the App never signed in. This could be for a variety of reasons, but I imagine that for many, the process of bouncing between applications was too jarring. Broadly speaking, users don’t care about security – they just want to do stuff.

SiteKey

I’ve decided against the Safari mechanism. It works well in theory, but in practice I don’t think the harm to the user experience is justified by the supposed security benefits. Instead, we could adopt a SiteKey-like approach that many banks use; the user initially gives half their login details, and we show them an image that an attacker would not be able to provide. While this can be a problem with some systems (the user could easily forget an image they provided while registering for a bank account), Blipfoto user’s will easily be able to recall the last image they posted. Only the Blipfoto service could provide this based on the given information, establishing trust.

This system is not perfect from the user’s perspective, as it requires a two-stage login (username then password). Nor is it totally secure, as this flaw in the Bank of America’s system shows. But in my opinion, at least for Blipfoto, it certainly beats jumping between applications. Many developers would like to see Apple promote the Safari mechanism, but even though we want to educate users in security matters, we also can’t let the user experience suffer.