Here is the abstract:

I examine the question of how to design election-related software, with particular attention to the threat of insider attacks, and propose the goal of simplifying the software in electronic voting machines.  I apply a technique called prerendering to reduce the security-critical, voting-specific software by a factor of 10 to 100 while supporting similar or better usability and accessibility, compared to today’s voting machines.  Smaller and simpler software generally contributes to easier verification and higher confidence.

I demonstrate and validate the prerendering approach by presenting Pvote, a vote-entry program that allows a high degree of freedom in the design of the user interface and supports synchronized audio and video, touchscreen input, and input devices for people with disabilities.  Despite all its capabilities, Pvote is just 460 lines of Python code; thus, it directly addresses the conflict between flexibility and reliability that underlies much of the current controversy over electronic voting.  A security review of Pvote found no bugs in the Pvote code and yielded lessons on the practice of adversarial code review.  The analysis and design methods I used, including the prerendering technique, are also applicable to other high-assurance software.

Many people contributed to the work.  The more I learned about things that other graduate students have had to deal with, the more I realized how lucky I was to have Dave Wagner and Marti Hearst as advisors — they got back to me quickly, read drafts carefully, and had lots of well-thought-out and constructive comments to offer.  Candy Lopez showed me around the election office in Contra Costa County and patiently explained to me how everything was done in real life.  Noel Runyan and Scott Luebking taught me about accessibility, and I appreciate their advice very much even though the dissertation doesn’t address accessibility as much as it could; the research didn’t include user testing with disabled voters.  Matt Bishop, Ian Goldberg, Yoshi Kohno, Mark Miller, Dan Sandler, and Dan Wallach volunteered a huge amount of time to review my source code.  Joe Hall has been a great help on questions about election law and policy.

• For Diebold and Sequoia, at most one DRE is allowed per polling place, and its results must be audited by 100% manual count.  (Hart DREs and optical scan machines are not subject to this condition.)
• The ES&S InkaVote Plus is decertified.  It may be recertified conditionally after it is reviewed.

For Diebold, Hart, and Sequoia machines:

• All software and firmware must be reinstalled on all devices prior to use in the February 5 primary.
• All tamper-evident seals must be serialized.
• Members of the public may inspect all external security seals.
• If a seal is found compromised or a machine must be rebooted to recover from a fatal error, the machine is removed from service and subject to a 100% manual recount.
• If a machine must be rebooted to recover from a fatal error, the vendor must provide an analysis of the cause of failure.
• Machine vote tallies must be publicly posted outside every polling place.  A second copy of the tally goes to election HQ.  Every poll worker must sign both copies.
• No network connections are allowed to any device not directly used and necessary for voting.  No wireless or modem communication by or with any voting equipment is allowed at any time.
• Vendors must provide a plan to prevent the spread of viruses, at least as effective as the “parallel system” method proposed in the Diebold source code team’s report.  In this method, there are two isolated copies of the election database: a permanent one to prepare the election, and a temporary one just for loading the results, which is then erased after the election.  A separate, isolated computer used for no other purpose is used to erase all storage media after the election.
• There will be new post-election auditing requirements based on the recommendations of the Post-Election Auditing Standards Working Group.
• Vendors are now required to provide a full build environment with their source code for escrow.
• Vendors are responsible for the cost of any upgrade or replacement due to claims of standards-compliance that are found to be false or misleading.

Congratulations, Secretary Bowen!  She must have been under incredible pressure in her position, and what she came up with looks pretty good.

I transcribed the following from Secretary Bowen’s announcement (which was on a noisy conference line):

Let me provide you with a few facts that should put this decision in some perspective.  First, of California’s 58 counties, fewer than half rely solely on direct-recording electronic or DRE machines for elections.  Second, in last November’s election, at least two-thirds of the people who voted in California did so using a paper ballot.  That includes an absentee paper ballot, and voters in that category are rapidly increasing …[?]…  and many use a polling place optical scan.  …[?]…  I certainly don’t want to minimize the impact of this …[?]…  but when you look at how people actually vote in this state, more than two-thirds and probably closer to three-quarters of the 8.9 million people who voted in California last November will not be affected by the DRE …[?]…  that I am …[?]…

Also, Secretary Bowen concluded her announcement by saying:

It is my hope that voting system vendors will, starting tomorrow,
begin to evaluate the competitive advantage that could accrue from moving to open source software.

Don’t forget to add your paper to the HCISEC Bibliography, and to join the HCISEC Yahoo!  group if you’re not already a member.

See y’all at SOUPS 2008.

It is simply the case that there is a huge number of children in the world with little to no access to a quality education system.  There are people working on building schools and creating infrastructure, but that is no reason not to try and get laptops out there now.  The OLPC laptop is incredibly power efficient and has a pretty decent range of hardware functionality intended to just such deployment.

Threat model:

• Software attacks on hardware (such as the harddrive)
• Attacks on OS integrity
• User data loss
• Privacy

These concerns are exacerbated by the fact that the laptops are intended to be open to hacking and exploration.  To protect the system the OLPC project has implemented a security framework named Bitfrost.

Bitfrost design goals

• Prevent hardware damage
• Provide software recoverability without lockdown
• Provide strong, unobtrusive, out-of-the-box security (cannot assume reliable Internet access)

The basic idea behind Bitfrost is to impose container-based virtualization which effectively quardon off the software on the machine so that each app is effectively independent.  The hardware is designed with a hardware latch to protect the BIOS from modification by the OS.  Each container has a token bucket that limits how often it can write to the NAND flash (to combat the fact that flash memory dies after too many reads).  There are hard-wired LEDs for the camera and microphone that authoritatively indicate when the device is on and off.  The base OS is never exposed to the user without a special “developer key”, granting only “copy-on-write” access to the typical user - this ensures the child can still customize and experiment with the OS, but can revert to a known good state at any time.

Laptops ship from the factory “deactivated” and require an activation key delivered out of band from the laptops for initial activation.  This should help ensure that the laptop is not stolen on the way to its destination.  Thereafter the laptops requires daily access to a “lease” server, or else it locks down until it is reactivated, which should help curtain individual laptop theft.

If you’re interested in seeing the OLPC code: http://dev.laptop.org/

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.

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 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.

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.

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.

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.

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

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.

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.

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.

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.

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.

PassPoints is a system where the user clicks five points on an image instead of entering a textual password.  The original studies were undertaken by Susan Wiedenbeck, et al.  (click here for more info).  They found that entry was slower than text but equally memorable and that the smallest acceptable tolerance was 14×14 pixels.

Today’s paper extended this work with a new lab study and a field study.  The lab study sought to confirm the initial results and re-examine the impact of image choice.  The field study sought to expand this further by examining whether it still worked when a user had multiple click-based passwords.

Users in the lab got to interact with a range of images, and universally disliked those with few obviously clickable points.  In the lab study vs.  field study it took users 33 vs.  25-30 seconds to choose their PassPoints, and 7 vs 5 seconds to login, respectively.  Users in the field study had a significantly harder time logging in when they had more than one image for which to remember clicks.  Each study ended with a 10-point Likert-style survey, with most responses in the 6-8 range.  Both groups said the preferred text passwords over graphical passwords, largely out of concern about shoulder surfing. 

Lab results were more positive than field results, which suggests a general need for complimentary field studies to back up lab results.

Concerns:

• type of image does influence success rates
• users had trouble handling multi-PassPoint image
• attackers often able to guess PassPoints due to image “hotspots”

IT professionals indicated that they wanted tools that:

• could be accessed from office/home/hotel, ideally w/ an available command-line interface
• can fit with existing management practices
• offer ease of practical documentation
• minimize the risk of overlooking critical information
• minimize workload

The study is ongoing and they are hoping to gather a wider range of data.  To contribute go to http://hotadmin.org.

Researches proposed an on-line game intended to teach users about phishing.  Users were shown 10 URLs before training and another 10 after, and were trained either using the game or other methods of anti-phishing training.  The results suggested that people learned about phishing better through using this game than through traditional phishing training techniques.

The paper also suggests that if a user suspects a site to be a phishing site they should do a web search for the site they are looking for.  The speaker indicated that they examined Google and found zero instances where a phishing site was returned on the first page.