Usable Security

http://cups.cs.cmu.edu/soups/2008/proceedings/p44Yan.pdf

CAPTCHAs were originally invented at CMU.  The goal of a CAPTCHA is to allow humans through but block automated scripts.  They are now widely deployed as a method of preventing spam.

Text-based schemes typically require the use to complete a text recognition tasks.  Some sites offer a sound-based scheme, typically for accessibility reasons.  There have also been some image-based schemes, such as Microsoft’sw Assira.

This research is on designing usable and robust CAPTCHAs.  Many deployed CAPTCHAs are not very usable.  Many of them are also not very robust - low-cost attacks on schemes by Microsoft, Yahoo!  and Google will be presented at CCS’08.

A framework for CAPTCHA usability:
- distortion
- content
- presentation

It is well known that under distortion some characters as as 1 and l, O and 0, and 5 and S have a high potential for confusion.  In the name of security, Google and Yahoo!  CAPTCHAs have actually created new confusing characters, such as vv and w, cl and d, and rn and m.  It would found that ~6% of the CAPTCHAs received from Google included such confusing characters such that a normal user would be unable to distinguish the intended letters.  In the latest Yahoo!  scheme ~10% of the challenges include such confusing combinations.

An example of a content concern is whether the length of the CAPTCHA string is fixed or variable length.  A constant length is more usable, but is also easier for an attacker to segment the image since they know the proper number of segments. 

A place presentation comes up is in the use of colors in CAPTCHA design.  The researchers found that color can often be an impediment to usability, and sometimes even reduces security.  For example, many CAPTCHAs have a complexly colored background, but machines can usually distinguish the text from the colored noise and extract out the background, so it is has hurt usability without helping security.  In some cases color is overly relied upon because some CAPTCHAs don’t even distort the character, just relying on the confusion caused by colorful noise, but again, the noise can be stripped out relatively easily.

http://cups.cs.cmu.edu/soups/2008/proceedings/p24Dunphy.pdf

Passfaces is a commercial graphical password system where the password is a sequence of face images.  This leverages the fact that humans are typically rather good at facial recognition.  Another motivation of Passfaces is supposedly that it is hard to write down your password to share, but are they?  Often a single-sentence description seems to suffice.

The researchers conducted a study in which 18 participants were asked to describe 15 out of 45 faces (27 female & 18 male).  The average description took 23 seconds to write.  They found that female descriptions were typically longer than male descriptions.  Females used 654 distinct words while males used 567.  Hair was the most common thing described, followed by face shape, eyebrows, and nose.

They then had a completely separate group of users attempt to login to a mock passfaces system based on the descriptions provided in the first part of the study.  This included 56 participants under three conditions:

- random decoys
- visually similar decoys (8 alternate faces of the same sex as the target face)
- descriptively similar decoys (8 alternate faces similar looking to the target face)

In each condition the participant was given either five descriptions written by a male or five descriptions written by a female.  Across all trials, subjects were able to successfully login based on the descriptions 9% of the time (7 for random, 5 for visually similar, and 1 for descriptively similar).  The study found that the both the visually similar decoys and descriptively similar decoys were significantly better than the random condition, though neither method of choosing similar decoys was obviously better than the other.

http://cups.cs.cmu.edu/soups/2008/proceedings/p13Rabkin.pdf

Security questions aren’t always bad…though they often are.  But, the bad news is, they are getting worse.  A secret security question asks for a secret fact.  A personal security question asks about something meaningful to the user, but that they are willing to share.  Unfortunately, if users are willing to share this information in one context they may well be willing to share the same information in another context.

The researchers and volunteers went through the forgotten password mechanism at 20 banks and wrote down the steps in the authentication process, including a list of all accessible security questions.

It turns out most of the big banks and credit cards mostly don’t rely on personal security questions alone.  Many ask for SSN + acct number + PIN.  A few send e-mail messages.  Security questions were much more common with brokerages and on-line banks.

Different sorts of security weaknesses:
- guessable
- automatically attackable
- human attackable

The security of personal security questions are based on assumptions of information-retrieval hardness.  But information retrieval is improving rapidly.  Many answers can often be found, or deduced from information available on, a subject’s publicly available social networking page(s).  Many others can be found with a simple Google search, especially if the subject has a personal website.

Some suggestions to fix this would be to ask recognition-based questions rather than recall-based questions.  It may perhaps be useful to embed media into the questions.  Another approach would be to try different styles of questions; for example, the method detailed in Love and authentication asks the user to indicate Yes/No as to whether they like things in a list of topics where the authenticating subject has to match their initial answers.

http://cups.cs.cmu.edu/soups/2008/proceedings/p1Forget.pdf

The research explored a novel password selection strategy in which subjects would enter a password and have random characters shuffled in to add security to the password.  The researchers explored different methods of selecting and placing the characters.

The goal is not only to help users choose better passwords, but also to build off elements of Persuasive Technology to help them better understand what makes a password secure in hopes that the users will choose better passwords in general.

The research results found that those with shuffled passwords took longer to confirm their password initially, but did as well as the control when recalling them later.  The study had included a mental exercise between sessions to clear the subject’s memory to better simulate having a greater period between attempts.  They ran John the Ripper over the resulting passwords and were happy to find that not a single PTP-improved password was cracked!

Unfortunately, it was found that as users proceeded through the trial they tended to choose less secure initial passwords once they knew the PTP system would add more characters, perhaps limiting the total security gains realizable by PTP.

The second day of SOUPS 2008 opened with the award for Best Paper.

This year’s best paper was selected to be Expressions of Expertness: The Virtuous Circle of Natural Language for Access Control Policy Specification by Philip Inglesant, M.  Angela Sasse, David Chadwick, and Lei Lei Shi.

The SOUPS 2008 Poster Session took place today from 4:00 - 6:00pm, featuring sixteen new posters and showcasing twelve poster previously shown at other conferences.  Each SOUPS poster is accompanied by at least a 2-page abstract, with some linking to full papers.

SOUPS Poster Abstracts

I was able to photograph many of the posters at high enough resolution that they can be easily read by zooming in a bit.  Unfortunately, not every photo was sharp enough to read so a few posters aren’t included here.

SOUPS Poster Gallery

SOUPS 2008 has begun! 

It kicked off with two parallel workshops:

Workshop on Usable IT Security Management

The Symposium on Accessible Privacy and Security

I have just completed my dissertation, which is available on my website and also in the Berkeley EECS Technical Reports archive.

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.

At midnight, I listened as Debra Bowen announced her official decisions on the use of electronic voting systems for next year’s elections.
I have to say I’m very impressed.  A few highlights:

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

I’m posting audio clips from Monday’s public hearing on California’s Top-to-Bottom Voting Systems Review at http://usablesecurity.com/ttbr/.  So far, the presentation of the accessibility and red team reports and the statements by the vendors (Diebold, Hart, and Sequoia) are posted.

Alas, here marks the close of SOUPS 2007.  I hope you enjoyed all the posts.  Let’s keep the discussion going!

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.

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

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/