17 August 2009 | Elaine Shi
How many times a day do you enter passwords in different places and multiple times in the same place?
[I enter passwords about 10-20 times a day -- to log onto my desktop, read emails, keep up with friends on social networks, buy books online, do my online banking, unlock my mobile phone, VNC or SSH into my Linux machine, VPN into my company network from home, get some cash back at the grocery store, and so on.]
First, what’s right with them: they’re the most widely used method for authenticating users to computer systems and protecting our information.
But here’s what’s wrong with them:
They’re difficult to remember. We’re told to use different passwords at different sites, which of course makes it even more difficult to remember them. Forgot your password? You probably tried multiple combinations, gave up on your recollections, hunted through an email folder, waited for a reset message, or worse: had to call customer service and wait on hold. Some people give up and just create a new account — but that doesn’t work for everything, and just adds to the problem.
They’re inconvenient. We’re instructed to use complex passwords with long strings of inconveniently mixed characters to harden against dictionary attacks. But on mobile phones, it’s way too easy to mistype letters with “fat fingers”, and too irritating to combine upper/lower case and different characters. Based on our survey of 50 iPhone, BlackBerry, and gPhone users, we found that over half mistype passwords at least 1 out of every 10 times. Users find password entry on mobile devices more annoying than lack of coverage, small screen size, or poor voice quality. [you can get our paper here]
They’re not used, or are used poorly. Many people use the same passwords everywhere, too-easy passwords, shared group passwords, or insecure password managers. Some just throw up their hands and disable passwords altogether.
They’re not always secure. One problem is the limited security of common password reset questions. For example, your mother’s maiden name, the name of your high school, and the make of your first car are not hard to find. [See how Sarah Palin’s email account got hacked.] Password reset questions are also commonly reused at different websites — what happens when one of these sites gets hacked? Another problem is that phishers can send you emails or IMs with a fraudulent link disguised to look like a message from a trusted source like a bank. When you click on the link, you’re directed to a page that looks identical to the trusted source’s webpage — but when you enter your password, you’re giving it away to the attacker.
How can we “authenticate” users without bothering them or interfering with their daily routines? In reality, many things authenticate us: something we know (answers to questions); something we have (a secure ID token); or something we are (biometrics such as fingerprints, voice). But something often overlooked is our implicit habits or routines.
Here are some example routines, all of which can be detected by my mobile phone:
How can these scenarios be used to “implicitly authenticate” me?
To replace passwords. For example, after making a 10-minute call to my boyfriend over lunch, I go to a talk and decide to browse my emails while waiting for the speaker to begin. The habits reflect my pattern, so it’s probably okay to allow me to read my emails without requiring a password.
To provide double verification. I’m much more paranoid about the security of my online finances, so for these websites implicit authentication can be used as a secondary factor to augment password-based authentication. The bank can more easily detect something suspicious if someone steals my password.
To detect fraud early. While my mobile phone detects that I’ve been sitting in a meeting at my company for the past hour — which is confirmed by my phone calendar — someone is using my credit card to purchase a $2000 TV at an electronics store 15 miles away from me. So the credit card company can detect something odd, and flag or deny the transaction up front.
Making implicit authentication possibleThe ubiquity of smart phones and PDAs provides an excellent opportunity for realizing implicit authentication, especially since these mobile internet devices provide rich sources of input (see examples, right). All of these inputs define our habits, and can be used to authenticate us.
Our proposed solution: (1) have your mobile phone collect these events; (2) upload them to a remote authentication server which records your past behavior, learns your habits, and computes your real-time authentication score; and (3) send the authentication score to a party that demands it. When you log onto your banking site, the bank can request the score from the authentication server for higher assurance. [Alternatively, all of the above can also be handled on the device itself, but there are resource constraints and security risks to consider.]
With most of the things our security team works on, we try to ground and refine our assumptions with actual user data. You can help.
Currently, we’re seeking Android users. To participate, please go to the Android Market and search for “PARC” or “implicit authentication”. By installing our app, you’ll contribute data to our research project [here are PARC's privacy and terms of use and here's the Android Market's legal information]. We’ll anonymize your data to protect your privacy. You’ll also be entered in a raffle for one of ten $150 Amazon gift cards.
Related reference
Implicit authentication for mobile devices
Thank you for your comment. I think there are different uses for implicit authentication:
– As password replacement: for this, you probably only want to use it for applications that are less security sensitive. For example, I don’t mind if my friends/family/co-workers are able to unlock my phone, or use my Facebook account (I trust they wouldn’t do anything outrageous!) But I don’t want them to read my emails, so I wouldn’t use IA to replace my email password.
– As secondary factor to augment password-based authentication (e.g., when you log onto your online banking account)
– As early detection for credit-card or ATM fraud
Also, potentially, we can use accelerometer/touchscreen patterns (and other biometrics) to distinguish you and your co-workers/family members/friends…
[...] discussed here before, password entry on mobile phones is not a lot of fun. But Amazon wisely invented 1-Click payments to reduce user burden. Soon this [...]
I think the focus on authentication is leading you to attack the wrong problem. A simpler approach is to give the user an authorization token when an account is set up. Presenting the token takes the user directly to the application with no need for authentication. We’ve been using specially constructed URLs for REST, but other technologies have been used.
Dear Alan,
Thank you very much for your comment. Yes, by storing a token on the device, one can achieve “device authentication”.
However, we are solving a slightly different problem — that is, “user authentication”. We aim to address situations involving stolen or captured devices, where it is evident to a service provider that it is the right device … but not that it is the rightful owner. Our implicit authentication technique also finds applications in fraud detection, such as for e-commerce or online banking applications.
[...] is also exploring the idea that contextual data implicitly authenticates you. It’s a privacy problem because you not only have to worry about what the data is telling [...]
[...] Increased demand for authentication. If cloud computing takes off, personal, financial, and medical data will be hosted in the cloud. Software applications hosted in the cloud will require usable and secure access control, both for consumers and enterprises. We’ll need higher-assurance authentication techniques outside the firewall, including semi-automated authentication from mobile devices. [...]
Great post!
Ubiquitous authentication is a great security mechanism, and its role will increase as mobile computing makes the analysis of behaviors more readily available. I feel it also becomes a convenience to the average user, in so much as its implicit nature uses context-awareness to mitigate the input limitations of small form-factor computing devices.
Artifact-based approaches such as passwords, “secure tokens”, and signatures based on residual information stored on mobile devices will quickly become obsolete. The one thing we remind our audiences of is the fact that a smart mobile device is a computer in a hostile environment (this ties into PARC’s other post about mobile malware.) As such, it cannot be assumed that such information is protected from compromise in the same way it would be on a networked laptop or personal computer. Independently verifiable behavioral information leaves no arbitrary artifact on the mobile device. And in that regard, there is nothing that can be compromised, replicated, and used to launch a fraudulent activity or attack.
I really feel this new paradigm is essential in mobile architectures and cloud authentication technologies.
(As a footnote, I just recently presented a mechanism for obtaining operational efficiencies using transient authorization tokens that are time sensitive and and behaviorally verified.) Behavioral authentication is already in use by certain industries such as credit card companies(banks), and long-distance providers. In those cases, a person’s behavior and security are shared interests between the user and the provider of some service. Since both parties have a vested interest in verifiable activities to minimize risk. Behavioral analysis is accepted by both the user and the verifier as a valid means to authenticating requests.
I think to be successful in behavioral authentication, there’s a paradigm that must be met:
1. The user must see an asset protection or reputation protection value in return for the exchange of their privacy. (I feel the added convenience in mobile inputs provides additional value on mobile platforms.)
2. Context information must be independently verifiable by the verifier(double blind verification) in order to prevent “spoofing” attacks. This can be widely accomplished now using commonly available sources.
3. There should be a historical basis that is relevant to the activity at large. This gets into a more interesting aspect of later developments in implicit authentication.
4. At some point implicit authentication becomes a mean free path type of problem. One has a greater mean free path in behaviors that are identical, and less of a mean free path in behaviors that are slightly varied. Finally there is a stoppage of a given behavior if verifiable activities do not meet a certain benchmark.
Hope all is well,
Jason
augmented reality batteries big data business models cloud computing content-centric networking contextual intelligence DARPA digital design disruptive innovation electric vehicles ethnography future of maufacturing government ideation and beyond information overload intellectual property intelligent automation location-based long tail malware manufacturing MVP (minimum viable product) open innovation PARC Forum portfolio management printed electronics reading list real options recommendation systems social search startups Steve Jobs twitter Wikipedia Xerox
August 17th, 2009 at 6:44pm
Posted by Shourya Roy
I would suspect “habits”/”behaviors” are more known to others and easier to replicate/steal by others than passwords. Many people at my workplace will know my driving pattern, usual lunch hours, workout schedules – so it’s not difficult for somebody else to log in to my email account. However, I agree that this is a more convenient option of authenticating.