iOS 6 and UDID deprecation

This is somewhat of a follow-up to my posting yesterday re what iOS devs should know about security-relevant changes to iOS 6.

We've all known for some time that Apple would be deprecating the use of Universal Device IDentifiers (UDIDs) in apps. We've also known more recently that attackers have been targeting those UDIDs.

And now, we need to prep our apps because, as of iOS 6, the use of UDIDs is no longer available. (Actually, reports indicate that Apple has been rejecting UDID-using apps for at least a couple months already.) But in iOS 6, Apple gives app developers an alternative in the form of a so-called "Advertising Identifier".

So, the question you might be asking yourself is this: Since this issue relates mostly to advertising, why do we care from a security perspective, and what's the big deal with UDIDs anyway? Glad you asked.

For starters, UDIDs are persistent identifiers. Many app developers have used UDIDs to identify sessions between mobile apps and servers. After all, they're unique identifiers, right? There are a couple of problems with that approach. First of all, if a consumer sells his iPhone, the UDID remains with the device, even if the iPhone gets wiped with a factory reset. Secondly, there are privacy concerns over associating users and persistent hardware identifiers.

So, in our apps, we really should avoid using persistent hardware identifiers to associate with users, sessions, etc. (Advertisers have also used these identifiers, but that's outside the scope of what I'm discussing here today.)

And besides, even if we mistakenly thought using UDIDs was a good thing, Apple has taken that option off the table.

That leaves us, at the very least, with the new advertising identifier. It isn't associated with the hardware, and can be cleaned with a factory reset, so many of the privacy concerns are reduced.

But let's step back a bit and consider this from a security perspective. If we're looking for a session tracking token, why wouldn't we generate a new one with every session, similar to how JSESSIONID works on Java web apps? If we're identifying a user, why not use a username and/or user number of some sort? Isn't then the advertising identifier simply an issue for the advertisers to deal with (as the name would imply)? I believe so.

But the fact remains that many apps have used UDIDs for session tokens, user identifiers, etc., for some time. Those apps will need to be re-tooled, if they haven't already been. I consider the use of something like a UDID to simply be sloppy coding, and we need to do better than that.

We'll discuss using the advertising identifier and other approaches at our Mobile App Security Triathlon in San Jose, on November 5-7.

Cheers,

Ken van Wyk