Today NoVA Blogger David Schuetz (@darthnull) was recognized for his hard work in uncovering the mystery of the UDID that Anonymous stated was pilfered from the FBI. The fact that the FBI had these (or the threat) opened an interesting and heated discussion around the privacy and security channels. The concerns were on privacy, rights of the users, and of course the weakness of the FBI security controls. Interesting enough the FBI was direct and absolute that they did not have this data / it was breached.
@darthnull interviewed on NBC News discovered it was actually stolen from a small (relative to the FBI) organization in Florida called BlueToad. This organization showed a 98% correlation in the datasets, and put out a press release stating the facts as they know them …
This scenario is actually worse than if the FBI had the data. In this situation we see a demonstration where a single small business recorded the UDID for their application. These UDID are used throughout the App Universes (Apple and Google), despite the providers recommending to NOT use these. The simple reason is these are essentially sensitive data – dare I say eventually PII.
The use of the UDID is even requested as a secure token for enterprise tools such as the GOOD email app messenger. In fact, many tools, apps, games, and other smartphone platform applications utilize these UDID as the key identifier of the user. The problem here is that if each App is collecting each UDID (even if done once and then switched to a better practice), that means there are A LOT of these databases lying around.
The quantity of such repositories of such UDID is large – marketing firms, analytics, games, productivity apps, enterprise MDM apps, etc… It would be interesting to determine how many Apps are using these IDs, but ultimately it is irrelevant when we realize the breadth of these records across so many parties, at some point we just accept the data is retrievable. The UDIDs are especially utilized across the mobile advertising & developer testing industry – as a means, for instance, of tracking marketing for instances, and within analytics (now part of a COPPA legal complaint).
The takeaway here is that enterprises should evaluate as part of their mobile strategy the authentication methods and dependencies deployed for these devices. If the UDID is being utilized in a “multi-factor” / “token” method, it should be reconsidered or at least the risk mitigated given the simplicity and likely broad amount of existing databases with such records. A positive note is that since March Apple has begun rejecting Apps that access these UDID, and a great write-up on the impact and effect can be found here at VentureBeat. To be clear there will be alternatives in the future to UDID, but their unique nature and “assignment” to a person will not likely reduce the sensitivity of the “token”, as it will be employed similarly.
Congrats to David for solving the mystery and helping illuminate this poor security practice of app developers.