IdP risks, social engineering customer service, & Mat Honan

The blogosphere is on fire with tales of Mat Honan’s being hacked (does anyone say “blogosphere” anymore?). The source most seem to be pointing back to is Wired’s article. The best thing I’ve seen is my bud @NishantK‘s writeup where he breaks it all down. And I’m not just saying that because he points back to my own piece about IdPs and their risks relative to upcoming NSTIC style requirements. But that is part of why I’m writing this short piece. I won’t attempt to say again what others have no said very well about the #mathonenhack and what it means you should do (but I know I finally turned on Google two factor authentication – have you?). I would like to answer a question asked by Dave Kearns on twitter, though:

@dak3 question about IdP risk

He was asking in the original context of the NSTIC comments. But I think it’s underlined by the eerie timing of discussing those risks and them watching this whole #mathonenhack play itself out in the media. In light of what happened and what it means for the risk and responsibility for an IdP, my answer stays the same. I don’t think NSTIC makes any IdP a bigger target then if they are already in the business of maintaining valuable assets for their own profit today. Later on, Dave also stated: “poor 3rd party IDP security practices means IT mgr (& CISOs) will draw the line.” There’s no doubt that there were some poor policies in place. And, as Nishant notes in his piece, Amazon and Apple have both changed some of that. But the key to making this happen comes down to the exploit of the brain of an Apple customer service rep when they decided that they would try to be helpful in the face of ambiguous results from their identity proofing procedures. Has that rep ever even been exposed to the concept of “identity proofing”? I can’t speak for Apple, but I’ve asked others and the answer has always been “no”. Apple in particular goes out of their way to be “friendly” when they can. Here it was used against them with terrible results. In the end, all the best process in the world can be exploited by getting to the right person and getting them to do the wrong thing for what they think is the right reason. At least, that will be true so long as we have people in the position to override our IAM systems.

Apple’s iCloud IAM Challenges – Does Match Need ABAC?

I swear this is not just a hit grab. I know that’s what I think every time I see someone write about Apple. But the other day I was clearing off files from the family computer where we store all the music and videos and such because the disk space is getting tight. I’ve been holding off upgrading or getting more storage thinking that iCloud, Amazon Cloud Drive, or even the rumored gDrive may save me the trouble. So the research began. Most of it focused on features that are tangent to IAM. But Apple’s proposed “iTunes Match” got me thinking about how they would work out the kinks from an access standpoint in many use cases. If you don’t feel like reading about it, the sketch of what it will be is you have iTunes run a “match” on all the music you have you did *not* get from Apple and it will then allow you to have access to the copies Apple already has of those tracks on their servers at their high quality bit rate via iCould instead of having to upload them.

iTunes Match fiddled with by me.

All the string matching levels of h3ll this old perl hacker thought of immediately aside, it became clear that they were going to use the existence of the file in your library as a token to access a copy of the same song in theirs. Now, my intent is to use this as a backup as well as a convenience. So maybe I’m not their prime focus. But a number of access questions became clear to me. What happens if I lose the local copy of a matched song? If I had it at one time does that establish a token or set some attribute on their end that ensures I can get it again? Since they have likely got a higher quality copy, do I have to pay them a difference? I had to do that with all the older songs I got from iTunes for the MP3 DRM free versions, why not this? Of course, if the lost local copy means that I can no longer have access to the iCloud copy, then this cannot act as a backup. So that would kill it for me.

But these problems have bigger weight for Apple than users not choosing them for backup features. There is a legal elephant in the room. How can Apple be sure they are not getting the music industry to grant access to high quality, completely legit copies of tracks in exchange for the presence of tracks that were illegally downloaded? In an industry supported by people paying for software, I’m always shocked at how lonely I am when I say my entire music collection is legal – or, at least, as legal as it is to rip songs from CDs for about 40% of the bulk of it. It’s one thing for a cloud provider to say “here’s a disk, upload what you like. And over here in this legal clean room is a music player that could, if you want, play music that may be on your drive.” But Apple is drawing a direct connection between having a track and granting permissions to a completely different track. Then pile on a use case where some joker who has the worst collection of quadruple compressed tracks downloaded from Napster when he was 12 and pours coffee on his hard drive the day after iTunes Match gave him access to 256 Kbps version of all his favorite tunes.

If this were a corporate client I was talking to, I’d be talking about the right workflow and access certification to jump these hurdles. Can you picture the iTunes dialog box telling you that your music request is being approved? That would be very popular with end users…

OBVIOUSLY Fake iTunes Dialog Box (please don't sue me)