The Security Frustrations of Apple’s “Personal” Personal Computer: Device Access, Two Factor ID, and 386BSD Role-Based Security

Image: smsglobal.com

Recently, a FaceBook friend lamented that he could not access his icloud mail from a device bound to his wife’s icloud access. He also expressed frustration with the security mechanism Apple uses to control access to devices – in particular, two-factor authentication. His annoyance was honest and palpable, but the path to redemption unclear.

Tech people are often blind to the blockers that non-technical people face because we’re used to getting around the problem. Some of these blockers are poorly architected solutions. Others are poorly communicated solutions. All in all, the security frustrations of Apple’s “personal” personal computer are compelling, real and significant. And do merit discussion.

One way tech folks get around Apple restrictions on email, for example, is to use multiple accounts. On an IOS device one can use multiple services and setup accounts for these services. For example, most don’t know that “notes” is actually a hidden email client via an imap fetch. Apple does use the appropriate protocols behind the curtain.

In my case, I don’t even use icloud mail. I use dedicated email accounts. I have access mediated by a mail server in our datacenter cloud which we personally administrate.  So all this frustration doesn’t impact me. I don’t see it in my daily life. I’m blind to the impact on others.

But what if I, like most people using Apple devices, want to access icloud mail from any Apple device? Icloud isn’t an ordinary heterogenous service. It is actually bonded to a set of devices. This is the philosophy behind Apple’s “personal” personal computer. The assumption is the customer has many devices tightly held and only used by that single customer. If that’s so, it naturally follows that those device will not easily permit access to a different icloud mail, because there is no need. The security won’t allow it. They expect you to setup another imap account, like Gmail, directly. They expect you to be a “techie”.

As an experiment in trying to understand this issue, I went to a mac that is not bound to an iphone I had in hand. By using “find my iphone”, I logged in as the apple ID and password. It then showed the location of that iphone sitting next to me. I then changed to the mail app within the browser, and it showed me the icloud mail. All this on a mac bonded to a different user. So I did get around the problem.

But it was non-intuitive. It was somewhat absurd. And it did reveal a security issue. Security by obscurity is a bug, not a feature.

I was unable to test this on other devices, such as an ipad, as I was pressed for time. But I’m pretty sure there are ways to get around this even on small devices. But really, seriously, is this sensible?

This entire conversation then segued into a discussion of two-factor identification. In theory, two factor identification is quite straightforward: Since everybody has a phone and some other device, if someone tries to access your account because they cracked your password and it’s not on one of your bonded devices, they send an email or a text to another device known as yours to confirm it’s OK. Simple, right?

Well, theory and practice are called that because thinking and living are really two different things. People live messy lives. Their phone may have been lost or forgotten or not charged up. They don’t know what device is the “mother may I” device.

The fundamental problem is that the nature of the security constraints of the Apple iphone concept requires it to be hermetically sealed. (In contrast, Android is a leaky sieve, and it is quite vulnerable.) This is why the battles between Apple and the government on access to personal iphones is so fraught, because it really is all or nothing.

This is not the only use of two factor identification. Two factor identification is required for a lot of services, such as FaceBook, and is not bound to a particular device walled garden. But the issue of making sure you have access to the primary device and “mother may I” device is still there. You must have all your devices, old and new, standing ready for the occasional incursion. And you must check and update all two-factor identification access points when you update devices. And this, my friends, is absurd.

I actually did a little work on security way back in the 1990’s, where William and I came up with the concept of role-based security as an adjunct to the usual password mechanisms. We even wrote up an article in Dr. Dobbs Journal about it, plus implemented it in 386BSD Release 1.0.

What were the gotchas? Security people didn’t like it because they were obsessed with crypto as a savior – which of course it wasn’t. The IT guys weren’t enamored because they liked administrating passwords and didn’t think it was a problem to change the password all the time, even though people don’t do that because they forget it, or they put it on a post-it on their monitor or write it in their wallet, and use “password” and “12345” as their password.

Two factor authentication is just doing a “mother may I” to a separate device because we have lots more devices, but fails if the device being asked might not be available, hence blocking the user from work. It may not be great, but at this point, it’s really all we have.