Admissibility & Mobile Networks: Security is a Lot More Than Passwords

I am writing this because of the recent attention to mobile network "security" in the wake of the several phone "hacking" scandals. It probably should have been one of those topics in the appendix of the Designing Mobile Interfaces book, but it's been delivered and O'Reilly is actually asking us to cut the appendix down so the thing is only good for holding doors open, instead of anchoring boats. For now, a blog post will do. Before we get into the details, some basics of security. First of all, security is not about preventing access, because straight-up, 100% prevention of pretty much anything is impossible. Any analogy will do, so take fire safety. You cannot build a fire-proof house. But you follow building codes, put in proper-sized breakers, replace worn power cords, don't keep piles of gasoline-soaked rags in the corner, put the family photos in a firesafe, and everyone is aware of where the exits are. You install smoke detectors. If you don't live in a reasonably dense area, you may want to have a remote alarm system. Together, these provide:

• Reduction of risk - Do what is reasonable to prevent things catching on fire.
• Reduction of exposure - If a fire starts, it should not spread too quickly; key systems are hardened or have backups and people can escape.
• Reduced reaction time to incidents - You or your neighbors notice the screeching and smoke, or the fire department gets notified automatically, so arrives to stop the fire before it is too severe.

This is formally considered for things like fire safety. The burn-through time for a wall, or fire door is considered in the context of the structure, it's risk of fire, the type of fire, the response of the fire department, etc. Similar actions occur for physical security. Bank vaults are only so strong, as they have alarms, guards, can be seen from the street, and drilling or cutting will be heard. All you have to do is make sure the vault is hard enough to break into that someone will notice, and can react quickly enough to stop the bad guys. Similar things for technical security, for the same reasons. Cost, and ease of day-to-day use. Reasonable locks, storing things in ways that cannot be exploited once the front door is broken (don't store passwords in plaintext), and baking in ways to be aware of breaches so you can fix them. A common one that I like is the out-of-channel notification. You make a liability-inducing (money changes hand) transaction, or access control (change your password) change via the website,and an email is sent out. The website is more likely to have been breached from several thousand miles away, and they probably don't have access to your email account, so you have a chance to notice, and react before much damage is done.
Moving closer to the topic, as I talked about several years ago there's a standard four tier security model that's been used for years and years:

• Authentication: Who are you?
• Authorization: What are you allowed to do?
• Availability: Is the data accessible?
• Authenticity: Is the data intact?

Which is very nice, and breaks things down well. You can already see that even conflating authentication and authorization is wrong and bad (we won't go into why, but if you are: look it up), and there's more it. That's the key to this post, btw. Security is more than just turning on the password by default, or reducing the session timeout so you enter the (you guessed it) password again. Anyway, Dave Piscitello (an ICANN fellow, security consultant, and generally clever guy) asserts we need a fifth layer. I agree completely, though not everyone does and accepting it at face value has pitfalls, but let's not talk about that yet. Therefore, the kind of thing I do is print this, and stick it on the wall of my cubicle so I don't forget it:

• Admissibility: Is the host device/channel valid and safe?
• Authentication: Who are you?
• Authorization: What are you allowed to do?
• Availability: Is the data accessible?
• Authenticity: Is the data intact?

For the most part, admissibility (well, good admissibility) means SSL or something similar. But mobile networks trump everything else. If you are a mobile operator, and the customer is using service on your network (not roaming, etc.) then you (more or less) own the whole experience. Ignore privacy concerns. Say that you are a mobile operator, and the customer wants to check their minutes. They go to your website via their phone. As far as the customer is concerned, full internet connection, go to the world and check a website. But it's not. In fact, your network has to hand off to the internet at some point, and there's a lot of good reasons to check the DNS requests, and send them down different pipes. When a request for your webserver comes in, you just send it across the hall to that box. So far, all that you get from this is reduced network traffic, and reduced latency to the user. But what else you can do is realize that you own the packet from the webserver to the pixels on the screen. You can, for example, identify the user and show basic information without authentication. No cookies required, first time they go there, the MEID (or other handset identifier) is used as the only key (authentication) to give this information (authorization). Sure, sure, someone can gain physical control of the customer's device, maybe temporarily, so you might want to ask for a passcode for liability-inducing actions, like purchases or password changes. But for lower-priority items, for non-sensitive but personalized data, or when out-of-channel notifications can reduce the risk, identification by network and reasonable degrees of authorization are a good and useful thing.
So, let's bring it back to the security of voicemail systems. Voicemail is one of those that's provided by you, the mobile network operator. Since you own the whole chain, front-to-back, a pretty reasonable solution is to require a password (a good one, but that's a different article) for access from the home phone, while roaming or whatever, but just let the user in when they are dialing from inside your network. Exposure seems minimal. It's voicemail, so is a bit cumbersome to use. You have to listen to it, it takes a certain amount of time to do this, or figure out the prompts to forward it, and there's a tiny bit of a trail. If your boyfriend takes a very long shower so you have time to listen to his voicemail, he's still maybe going to notice the MWI (message waiting indicator, indicating new voicemail) has been cleared, and there's no good way to reset it. I see no serious pitfalls here, for /reasonable/ security. Remember, be reasonable. The service has to be easy to use, and most people provide decent physical access control of their devices. I am so confident in this assertion that I'll even admit I have been part of the decisionmaking for an operator to keep doing exactly this.
But we screwed up. No, not in retrospect, or because we mis-weighed the severity of getting into vmail systems. Nope, much more basic. It was an admissibility problem. See, voicemail systems are provided by third parties. And not the same third party that installs the rest of the mobile switchgear. Don't ask why (because I don't know) but they are. Always, as far as I know, but I could be wrong. In at least some cases, maybe most and maybe all, they are also not particularly well integrated. To the point where they might not be housed at the giant corporate data center. And how do they determine when the call comes from inside the network? Well, at least sometimes, by caller ID. I'll let that soak in for anyone who at all is sad they missed the phone phreaking days. Yes, it's trivially easy to spoof caller ID... There, I just took 90 seconds out of writing this, googled some terms, and sent myself an SMS via a spoofing service (cause it was free; I would have had to pay to use the voice calling services). Anyway, huge breakdown in the security chain. The only lesson being: keep asking questions, and get to the people who know how systems really work. Because using your network the right way is among the more neat things that mobiles can do. If you are just some other web or app provider, you can even get agreements with the operators (or others who broker such deals for you) to get some of this same behavior out of your service. The lesson is not: more and longer passwords, as those are eminently crackable, and are pretty unfriendly to enter (more so on mobiles). Use the right security, but use it the right way.