Usable Security

http://cups.cs.cmu.edu/soups/2007/proceedings/p122_lieberman.pdf

This study explored user errors related to e-mail, specifically focusing on “Reply All” or unexpected “Reply To” headers sending responses back to the list.  The consequences are usually just embarrassing, but can be serious.  The researchers suggest that even if digitally signed and sealed email becomes widely used, people will still make these errors.  The proposed solution is to display an image of each intended recipient rather than just recipient e-mail addresses.

The study used an extension of Gmail that displays the accompanying recipient photo as an e-mail address is entered.  When the system doesn’t yet have a cached image it searches Google Images, Facebook, etc., to find an image for the e-mail.  The interface makes a very apparent difference between clicking “Reply” and clicking “Reply All”.  The interface was designed to be obvious at a glance, automatic, and scalable.  Facemail is implemented as a Firefox extension, and was used in a “glanceability” study with 84 subjects asked to answer who an e-mail was going to and how many people it was going to after seeing a flash of the mail composition window.  At 1 second Facemail did about as well as normal e-mail address displays, but as the time reduced down the benefit of Facemail became increasingly apparent.

Some risks of this technology are that it may make spoofed addresses more credible, makes message recipients more visible to shoulder-surfing, and may make it harder to lurk on mailing list.  Some common errors that Facemail does not address are the potential dangers of public archiving of e-mail, getting the recipient right but sending too much information, and information disclosure outside of e-mail.

http://cups.cs.cmu.edu/soups/2007/proceedings/p112_conti.pdf

Data gathering and retention is becoming an ever greater part of using the Internet.  Users can choose not to be users, or they can choose to give away their data.  Google was used as an example of such a data gatherer, though it was also mentioned that Google has announced that it will only retain personally identifiable information for 18 months, but many sites have yet to make such assurances.

Goals of research

• Amount of search activity as well as search engine used
• Perceptions of privacy
• Choices made in privacy vs.  functionality

Here are some interesting findings from the paper, but the paper has much more detail:

The study involved 352 non-eng undergraduate students using a web-based 4-point Likert survey with 25 randomly ordered questions asking about web usage, search engine privacy, trust of online companies, data retention, and anonymity.  The study found that 92.44% of the students indicated that they use Google as their primary search engine.  The study then asked why they chose the search engine they did, with only 34% selecting 3 or 4 for “It came with my computer”, 89% indicating 3 or 4 to because “I feel it provides the best search”, and 96% giving 3 or 4 because they felt it was the easiest to use.  Interesting, only 32% said they chose it because of other products offered by the company.  70.69% indicated they were comfortable with the privacy they have using their preferred search engine.

95% of respondents indicated they had used a search engine to search for their own name at least once, with 82% indicating they had used a search engine to look up contact info for friends and/or colleagues.  There was an even split between the users that would choose perfect search vs.  perfect privacy.  The vast majority of results across companies fell between limited trust and reasonable trust.

The study then examined user perception of data retention.  The vast majority of respondents indicated that they understand that data retention is occurring frequently to always, with 38% believing it would be stored for months and 45% believing it would be store for years or decades.  Interestingly, for the group questions 91% of respondents indicated they hadn’t heard about the August 2006 AOL data disclosure.  Only 22% of users indicated that they believed their search engine usage is anonymous, with 85% saying they don’t know any way to go about doing an anonymous search.

Marcia Lausen, http://www.designfordemocracy.org/

Marcia began the talk with a review of the infamous Florida ballot that plagued the US 2000 presidential elections.  She then moved on to demonstrate an almost unbelievably worse ballot from a judicial circuit election in Chicago, which she offered to redesign.  The redesigned ballot was inarguably clearer and easier to understand, raising the question of why interface designers are not more commonly involved in ballot layout.

Information Design :: Legibility vs.  Creativity

1. Mixed-case lettering is more readable than ALL CAPS
2. Centered type is not the user’s friend
3. Understand + understand the election hierarchy
4. Minimize variance in size, type, width, etc., unless strictly necessary to improve understanding
5. Black type on white is the most legible

The researchers then worked on applying lessons learned to other types of ballots, but ballots are really the tip of the iceberg.  The design principles above were then usefully extended to redesigning voting instructions and manuals for training pollworkers.  Efforts were then expanded to include class participation in design and evaluation of election related envelopes, forms, and other documentation related to the voting experience.  Marcia and her students also got involved in the design of filing cabinets, pollworker trays, and other non-documentation paraphernalia.

Recent efforts have focused on spreading the word about design advancements, encouraging election officials to take interest and get involved, and getting out the vote to normally disenfranchised voters.

http://cups.cs.cmu.edu/soups/2007/program.html#discuss

Have notes from your discussion session that you’d like to share w/ those that attended one of the other ones?  Post them here!

UW2SP: Usable Web 2.0 Security & Privacy
Moderator: Larry Koved (IBM T.J.  Watson Research Center)

The goal of this discussion session is to establish new collaborations in topics related to usable security for Web 2.0 security and privacy.

Standardizing Usable Security and Privacy: Taking It To the Next Level, or Settling for Less?
Moderators: Mary Ellen Zurko (IBM) and Maritza Johnson (Columbia University)

This discussion session will consider the relationship between standards and standardization, and usable security and privacy, including where we are today, and where the usable security and privacy community would like to see that relationship go in the future.

One Laptop Per Child Security
Moderator: Ivan Krstic

A paper on Bitfrost, the One Laptop per Child security architecture, is being presented later at SOUPS.  Usability was a crucial concern in the system’s design, and we believe Bitfrost will resist many security problems seen with today’s computers.  In this discussion session, however, we wish to focus on problems that Bitfrost doesn’t solve.  This includes both problems whose solutions were too hard to design or implement and problems that simply don’t have clear solutions, ranging anywhere from child-friendly authentication schemes to comprehensive browser security.

http://cups.cs.cmu.edu/soups/2007/proceedings/p76_brustoloni.pdf

Users not only ignore dialogs, but will lie to them if doing so is necessary to achieve the desired behavior.  This research employs polymorphic dialogs that change each time to keep the user from learning/giving automatic answers.  Polymorphic dialogs deliberately vary the dialog such that the consequence of automatic answers becomes unpredictable and thus requires greater effort to give goal-directed false answers.

The study considered two examples of polymorphic dialogs.  The first was to vary the order of dialog elements, and the second is to delay the user’s ability to confirm the dialog by keeping the confirmation buttons disabled for a short window.  The study also explored the possibility of audited dialogs which warn the users that their answers may be audited or that answers will be forwarded to company auditors with threats of penalties, and include the capability for auditors to actually penalize the user.  To explore these ideas with real users the study included three versions of Thunderbird - one running as normal, one extended with polymorphic dialogs, and one extended with polymorphic audited dialogs.  Users were asked to role-play as an employee in two scenarios with varied order.

The results confirmed that there was a significant reduction in task completion time and better evaluation of risk with PDs (polymorphic dialogs), and even better results with PADs (polymorphic audited dialogs).  They then compared the PD to the PAD groups and found that it appears that the auditing component had a significant impact.  Users rated the dialogs 3.9/5 as easy to understand, but were divided on willingness to recommend the interface to a friend.

Introduction
Steven Myers

Historically most online banking done with password (single-factor authentication) with the password communicated over SSL/TLS secured channel.  Unfortunately, this system is vulnerable to phishing.  The FDIC and FFIEC required that all banks have “enhanced” login by the end of 2006.  Most banks took this to mean two-factor authentication.

SSL is simply not understood by users, so they give out credentials improperly.  Attempts have been made to help users visualize this by adding security indicators, but they are inconsistent between browsers and users often don’t understand or them, ignore them, or misunderstand them.

What problem is the two-factor authentication supposed to be solving?

• Do we want to prevent credential loss?
• Fraud?
• Money laundering?

How Expensive are the Solutions?

• Initial enrollment costs
• Deployment costs
• Support costs
• Financial industry is phobic of any client-side solution
• If costs per transaction is not lower than teller, ignore it

Who are the adversaries?

• Phishers
• Pharmers
• Crimeware
• Traditional fraud (family members, co-workers, etc.)

Multi-Factor Authentication: Is it Enough?
Jeffrey Friendberg, Chief Privacy Architect, Microsoft

The core of this presentation is a very interesting direct graph depicting the “Internet Battlefield” visualizing users, sites, attackers, and existing defenses.  Though it is obviously not “complete”, it has a whole lot of interesting data.  (link to Internet Battlefield whitepaper)

Key themes discussed in 2005/2006

• Know who’s who - enable strong mutual authentication
• Don’t share secrets - leave bad guys empty handed
• Plug the leaks - comprehensive data governance
• Nowhere to hide - make it easier to catch the bad guys
• Lend a hand - help victims contain damage and cleanup

Some progress has been made

• Agreement on the need for better mutual authn - FSTC, IDSP, Authentication Summit, …
• Easier to spot bad sites - new filters that use block lists and heuristics
• Easier to spot good sites - visual secrets part of ceremony
• New “EV” certs
• Less likely to get owned - easier to run with lower privilege
• Lost laptop not as catastrophic - Vista BitLocker full volume encryption (though similar solutions have existed for a long time)

Two-Factor Authentication
Rachna Dhamija

General consensus of the financial industry: “Every countermeasure we introduce reduces fraud temporarily.”

E-Trade financial tried using a RSA fob as a second factor of authentication, but as of their 11/07/06 financial report their fraud losses continue to increase.  That said, they considered this program a success because users indicated they feel safer and are more likely to provide assets.

BankOfAmerica’s implementation of SiteKey is supposed to protect users from phishing, studies show it does not.  RSA’s response was basically that they considered the program a success because users indicated they feel safer and are more likely to provide assets.

Anybody else seeing a disturbing pattern here?  What appears to matter with two-factor authentication is more about public relations and only tangentially about user security.

Current State of Things
Full panel

Back-End Fraud Detection System
The most common solution in the financial industry has been to move their back-end fraud detection system to their online properties, keeping statistics of behavior and stopping suspicious transactions.  The claim is that this is very effective and does not change the user experience.  Some members of the audience disagreed with the claim, citing examples of transactions being denied in a wide range of situations.

Digital OTP I
These are relatively common, the best known example being RSA SecurID.  This solution is fairly expensive, but still evidently profitable.

Digital OTP II
These are less common than the above, but are embedded in the credit card and not timer based.

Paper Based One-Time Passwords I
Paper Based One-Time Passwords II
Grid Based One-Time Passwords I
Grid Based One-Time Passwords II
Paper card issued by bank with series of one-time passwords, the main difference between them being the intended usage of the cards.

Crypto tokens
These are usually SecureID cards or smartcards bundled with a reading in a nice USB form-factor.

Server authentication via images
SiteKey and other similarly useless technologies.

Server authentication via images

Knowledge Based Challenges
What is your mother’s maiden name?

Out of Band Communication
SMS challenge, identifying cookies, etc.

Facial recognition

On-Screen Keyboard

…  other topics that flew by too quickly to catch the titles …

Extended Valuation Certificates
These are basically more expensive SSL certs that cause some extra stuff to happen in the browser chrome.  The claim is that they are guaranteed to be more thoroughly checked.

Those who think these are a waste of time (or worse) wonder if users ignore browser chrome now it isn’t clear why we think they’d pay more attention by just adding more identifiers to the chrome.  They also point out that users don’t understand the concept of CA, probably don’t know anything about the back-end validation, and isn’t likely to change the site they shop at just because of the new type of cert.

Those claiming it is useful point to the guarantee of the extra checks, the display of the CA info in the bar, and the other UI improvements.

http://cups.cs.cmu.edu/soups/2007/proceedings/p64_bauer.pdf

Grey is a smartphone-based discretionary access-control system developed at CMU which allows for various forms of physical and digital access.  The user can select the resource for which to present authorization from the cell phone screen, and the cell phone transmits a credential to the reader guarding the resource.  If the user does not directly have access she can send a request to somebody that does have access and is able to grant discretionary access.

The researchers ran a year-long trial of the system with 19 users solicited from the CMU population.  At CMU Grey covers 5 perimeter doors, 11 offices, 2 storage closets, 1 lab, and 1 conference room.  The users were interviewed before the study concerning their security practices and types of resources managed and needed, with additional interviews conducted roughly monthly throughout the study.  During the study period there were 19,5000 Grey access attempts with the average user interacting with ~7.4 Grey-protected resources.

Towards the beginning of the study users were complaining about the speed of the system.  Because it was known by developers that Grey and keys required a similar amounts of time to open a door, the researchers videotaped a highly trafficked dor to better understand how doors are opened differently with Grey and with keys.  During this videotape session they recorded 18 users (5 Grey / 13 keys).  It was found that with keys it took approximately 14.7 seconds to open the door vs.  15.1 seconds with Grey.  So why the perceptive difference?  Findings were that user impression of time passage for keys didn’t include fumbling for keys and removing the key from the lock because they were actively involved throughout vs.  some periods of pure waiting with Grey.

Other findings from the study included:

• a single failure would have a significant effect on adoption because the cost of failure is potentially very high
• delays can be interpreted as failures even when the system is functioning perfectly because of human lag on the other end in discretionary access situations
• users would rather choose a suboptimal solution they understand than one with an uncertain outcome
• systems that benefit from the network effect often don’t work well with a small user population
• using Grey participants granted more access than they did previously
• some participants were thrilled to no longer have to stand up to open an office door without standing up and the ability to unlock a nearby door without going over to it
• education and background seemed to have little effect on usage

http://cups.cs.cmu.edu/soups/2007/proceedings/p52_krishnamurthy.pdf

Diffusion of private information to third-party sites is a growing issue.  Such diffusion occurs without direct knowledge of the users (done by browser).  Third-party sites gain knowledge about users (e.g.  IP addresses, cookies), and knowledge allows user access to first-party sites to be aggregated and correlated.  Primary goal of this work is to examine techniques to limit diffusion of private information and examine trade-offs of these techniques in providing privacy protection versus impacting page quality.

Currently available options:

• disable cookies
• disable JavaScript
• filter ads
• block images

Not directly available yet, but doable:

• filter all third-party objects
• remove JavaScript content entirely
• filter requests with identifying URLs (i.e.  URLs with queries)
• filter objects from top aggregation servers
• remove Web bugs

What happens when we do some of these things?

• error occurs - explicit message and no page content
• warning occurs - explicit message with possibly modified page content
• nothing explicit occurs, but the page is deformed, corrupted, or otherwise less usable

The study examined over one thousand websites to examine first and third-party of changes in settings for cookies, javascript, and URLs in which some query param is uniquely identifying (Google Analytics used as an example of this last type of identifying info).  The findings indicated that the average web page incorporates 2.9 third-party accesses, with 41% of those going to one of doubleclick.net, 2mdn.net, atdmt.com, google- analytics.com, 2o7.net, googlesyndication.com, akamai.net, advertising.com, hitbox.com, and questionmarket.com. 

The results include a very interesting chart showing how much usability is lost for each technique, a chart of the cumulative privacy risks of the various technologies, followed by graphs visualizing the privacy vs.  usability trade-offs.

http://cups.cs.cmu.edu/soups/2007/proceedings/p41_clark.pdf

This paper compares four deployment methods of Tor for Firefox.  There are numerous identifiers used while surfing the web, including those that are self-volunteered (pseudonyms, e-mail addresses, etc.), server-assigned identifier, and protocol-based (i.e.  IP address).  Tor itself actually only addresses the IP address.  Tor is often combined with Vidalia, Privoxy, Torbutton, and/or FoxyProxy. 

In most security applications, your security is dependent only on your own ability to use the software.  With Tor, your anonymity is dependent on both your own ability to use the software the ability of other users because anonymity increases in proportion to the number of users.  Therefore it is important to make Tor as accessible as possible to ensure a sufficiently large user pool for the onion routing to provide strong anonymity.

Dangers w/ Tor:

• false sense of completion
• DNS leaks
• Java applets, Flash, and client-side scripting can be exploited to bypass anonymity technologies

The researchers used a cognitive walkthrough premised on a pragmatic user.  The walkthrough focused on the difficulty of installing, configuring, and verifying the use of Tor and friends, analyzing each step against typical usability guidelines.  The overall conclusion is that it is still rather cumbersome to install, configure, and use Tor.  Suggestions from the researchers include improving documentation language by making it task-focused and possibly drawing language from observing users explaining the steps to one another.  They also noted that there are no good solutions for blocking Java, Flash, and client-side scripting exploits.  This last point might make it so that Tor offers a false sense of security on many websites that make use of such technologies.

http://cups.cs.cmu.edu/soups/2007/proceedings/p29_jensen.pdf

iWatch is a webcrawler which builds a central database of global online data practices.  It starts with a seed list of the top 50 websites as reported by Comscore Media Metrix and indexes privacy related practices including cookies, webbugs, P3P, etc., while post-processing indexes data by domain, by country, cross-references lists of privacy seals, fetches P3P policies, etc.  Programatically determine some of these things is pretty complicated.  To date they have indexed nearly 250,000 pages over nearly 25,000 unique domains in 81 countries.  In addition to grouping upon domain and country they also group based on common privacy laws, such as those shared by members of the EU.

The iWatch data allows:

• data mining for better risk indicators
• study the evolution of practices over time and the impact of key events
• directly provide data to aid consumers, legislators, e-merchants, and researchers

The data gathered so far suggests that sites with P3P policies are actually more likely to use webbugs.  The data shows that P3P adoption increased in the US and Canada from 2005 to 2006, but decreased in the rest of the world.  Correspondingly, the use of webbugs increased in the US, but decreased in most other areas.  It is hoped that this data will be useful for e-merchants trying to decide which privacy features to include, to security researchers analyzing privacy and trends, and to end users trying to evaluate their privacy risks on-line.

http://cups.cs.cmu.edu/soups/2007/proceedings/p20_dirik.pdf

More on PassPoints!

Studies on visual attention and eye movements show that most images contain a few portions that humans typically focus on - so-called image “hotspots”.  This study seeks to device a model that enables the prediction of the entropy in a given image.  Such a model would enable the design of automatic “dictionary” attacks or to automatically reject images with low entropy.

There are various methods of image segmentation available that divide an image into discrete regions.  The study hypothesized that users will tend to click on the center of image segments, with which segments the user is likely to choose based on color, intensity, and shape.  There is then a quantization function which estimates the probability of attention for each click-point.

The researchers developed a Java-based PassPoints authentication system that they used for testing, with over one hundred users participating.  The researchers found that their model was rather accurate for the two images tested.  They then used their model to attack the users’ chosen logins, which was successful in the majority of cases once the search space was set high enough.

http://cups.cs.cmu.edu/soups/2007/proceedings/p13_kumar.pdf

Passwords are generally entered through keyboard, mouse, touch screen, or keypad.  All of these are subject to shoulder surfing.  The paper proposes using a gaze-based entry method rather than actually having to enter the password on a keypad, which avoids both shoulder-surfing and possibly keystroke logging. 

Most approaches to combat shoulder surfing add noise/ambiguity for the observer, but this also typically increases the number of interactions the user has to go through, the cognitive load required, and the time it takes to login.  Simpler solutions are available using physical tokens, but such tokens are costly and prone to being lost or stolen.  Some solutions propose the use of biometrics, but biometrics are usually non-secret and not revocable.  The motivation for gaze-based entry is that a typical adversary can observe the keyboard and screen easily, listen to any sounds emanating from the system, and can observe the user’s head motion.  However, it is relatively hard for the attacker to precisely observe user’s eye movements, especially from behind (though there is some concern that as attackers respond to such a system they may develop nefarious eye-tracking systems).

State of the art eye tracking systems tend to run ~$25,000.  But iSight cameras are built into the MacBook Pro, and combined with some infared lights this camera is high enough resolution to enable cheap eye tracking!  Either way, entry is achieved by having the user look at each character and holding their gaze on each character for about half a second (another option is to use a manual trigger).  Research has found such a system works well with all but the thickest glasses and certain types of contact lenses.  One limitation is that the keys of the on-screen keyboard must be relatively large; in the study they used 80 pixels per key with 12 pixels between keys.

The study found that gaze-based entry took about 10 seconds vs.  2.5 seconds for keyboard entered passwords.  The researchers also found that users preferred a QWERTY on-screen keyboard to an alphabetic one, and that gaze-based vs.  triggered entry occurred at about the same speed, though triggered entry surprisingly had a much higher error rate.  In an after-study survey >80% of subjects indicated that they would prefer to use gaze-based entry over keyboard entry in a public place and the time to enter the password was irrelevant because they didn’t enter password often enough for it to matter.

For more on gaze-enhanced UI design see GUIDe.