Recently at the 21st USENIX Security Symposium, researchers from the University of South Carolina and Microsoft released a paper titled, “Progressive Authentication: Deciding When to Authenticate on Mobile Phones.” The paper raises some interesting issues about how and when to authenticate end users of mobile phones. They call their scheme “progressive authentication,” but to my mind they are discussing the concept of “least privilege” and “privilege escalation” and applying it to low risk environments.
Regardless of what you call it, it’s a worthy discussion point. The authors of the paper claim that they can reduce the number of authentication transactions by up to 42% while not compromising the security of the applications and data on the phone.The sample size of their prototype system is only 9 individuals, so I’m not sure I’d put a lot of credibility into the 42% number. But their research does paint an interesting picture worthy of discussion.
The core problem is that most users have a mix of apps on their phone with varying degrees of sensitivity. Some apps don’t have any particular security requirements while other apps access very sensitive information like banking information. But authentication on mobile phones is more typically an “all or nothing” approach. You either set up authentication such as a PIN and have to use it every time you use the phone or you don’t set up authentication and you never have to authenticate yourself to use the phone. This is very inconvenient for most end users who want to check their friends’ Facebook status or check their inbox multiple times per day (or hour!). So many end users simply turn off the phone’s authentication mechanism.
The researchers gave their study subjects the choice of classifying their apps as needing authentication or not and found that the participants needed at least 3 levels of security classifications to feel comfortable classifying all their apps:
“Most participants chose to have a final configuration with one unlocked level, one weakly-protected level for private, but easily accessible applications, and one strongly protected level for confidential content such as banking.”
Makes sense to me. For the most part, Facebook is a benign app as far as I am concerned. I have no super sensitive information stored in my Facebook account and pretty much the worst thing that can happen is someone posts something to Facebook in my name that might be embarrassing to me. I’d have to change my account, make apologies. But this level of hacking is not so bad that I feel the need to authenticate every time I check my Facebook news feed. On the other hand, if someone gets access to my credit union account through my mobile app, that’s bad, very bad.
So the idea of moving the decision from an “all or nothing” scenario, which is the typical case for phones, to a deciding about when to require authentication on a per-app basis seems like a step in the right direction to me. Those low end apps that are mostly benign can be set up to be authentication-free and the escalation of privilege using authentication only occurs when running a sensitive app. That’s why I think of this idea as the “low end of privilege escalation.”
But there is precedent for going even further with the idea which we see in day to day use already. The example that pops into my mind is the checkout process on Amazon. I can use Amazon without logging in. This spares/denies me (depending on your perspective) receiving recommendations from Amazon about what I should be interested in. If I choose to be logged in, my shopping experience is perhaps a better experience. But being logged in isn’t an all or nothing authentication. If I do anything that affects my account settings or if I start any activity that has financial implications, Amazon requires me to supply my password again, even though I’m already logged on. Even though you are giving the same password you used when you logged in, entering the password just before starting these riskier activities is arguably a stronger credential because of the immediacy and therefore its valid for the privilege escalation necessary to conduct these more important transactions. You might have logged on two weeks ago and a Bad Guy has gained access to your browser or in some other way gained access to the cookies representing your credential. So requiring this privilege escalation scheme helps mitigate that risk.
Kudos to the authors for raising this issue. I think they rightly point out that moving the authentication closer to the invocation of the sensitive apps while, more importantly, eliminating the need for authentication of non-sensitive apps is a step in the right direction. But ultimately I think it’s going to be the app’s responsibility to decide the level of sensitivity and the when and how of requiring authentication. I can’t imagine my Amazon app not requiring that additional authentication step when I start to check out because it (somehow) knows that the phone the app is running on authenticated me. (Not to mention an inability to agree on what “me” is, credential-wise.)
While phone’s PIN authentication requirement is a nice feature to have, and I can see the advantages presented in the paper for when and how to require authentication, App designers who are dealing with information or activities that are at all sensitive or confidential must assume the phone is a hostile environment. The App cannot defer authentication and privilege escalation to the phone. It’s the apps responsibility to protect itself and the data it stores on the phone from unauthorized access.