Entries Tagged "usability"

Page 8 of 8

Why Phishing Works

Interesting paper.

Abstract:

To build systems shielding users from fraudulent (or phishing) websites, designers need to know which attack strategies work and why. This paper provides the first empirical evidence about which malicious strategies are successful at deceiving general users. We first analyzed a large set of captured phishing attacks and developed a set of hypotheses about why these strategies might work. We then assessed these hypotheses with a usability study in which 22 participants were shown 20 web sites and asked to determine which ones were fraudulent. We found that 23% of the participants did not look at browser-based cues such as the address bar, status bar and the security indicators, leading to incorrect choices 40% of the time. We also found that some visual deception attacks can fool even the most sophisticated users. These results illustrate that standard security indicators are not effective for a substantial fraction of users, and suggest that alternative approaches are needed.

Here’s an article on the paper.

Posted on April 4, 2006 at 2:18 PM • View Comments

The New Internet Explorer

I’m just starting to read about the new security features in Internet Explorer 7. So far, I like what I am reading.

IE 7 requires that all browser windows display an address bar. This helps foil attackers that operate by popping up new windows masquerading as pages on a legitimate site, when in fact the site is fraudulent. By requiring an address bar, users will immediately see the true URL of the displayed page, making these types of attacks more obvious. If you think you’re looking at www.microsoft.com, but the browser address bar says www.illhackyou.net, you ought to be suspicious.

I use Opera, and have long used the address bar to “check” on URLs. This is an excellent idea. So is this:

In early November, a bunch of Web browser developers got together and started fleshing out standards for address bar coloring, which can cue users to secured connections. Under the proposal laid out by IE 7 team member Rob Franco, even sites that use a standard SSL certificate will display a standard white address bar. Sites that use a stronger, as yet undetermined level of protection will use a green bar.

I like easy visual indications about what’s going on. And I really like that SSL is generic white, because it really doesn’t prove that you’re communicating with the site you think you’re communicating with. This feature helps with that, though:

Franco also said that when navigating to an SSL-protected site, the IE 7 address bar will display the business name and certification authority’s name in the address bar.

Some of the security measures in IE7 weaken the integration between the browser and the operating system:

People using Windows Vista beta 2 will find a new feature called Protected Mode, which renders IE 7 unable to modify system files and settings. This essentially breaks down part of the integration between IE and Windows itself.

Think of it is as a wall between IE and the rest of the operating system. No, the code won’t be perfect, and yes, there’ll be ways found to circumvent this security, but this is an important and long-overdue feature.

The majority of IE’s notorious security flaws stem from its pervasive integration with Windows. That is a feature no other Web browser offers—and an ability that Vista’s Protected Mode intends to mitigate. IE 7 obviously won’t remove all of that tight integration. Lacking deep architectural changes, the effort has focused instead on hardening or eliminating potential vulnerabilities. Unfortunately, this approach requires Microsoft to anticipate everything that could go wrong and block it in advance—hardly a surefire way to secure a browser.

That last sentence is about the general Internet attitude to allow everything that is not explicitly denied, rather than deny everything that is not explicitly allowed.

Also, you’ll have to wait until Vista to use it:

…this capability will not be available in Windows XP because it’s woven directly into Windows Vista itself.

There are also some good changes under the hood:

IE 7 does eliminate a great deal of legacy code that dates back to the IE 4 days, which is a welcome development.

And:

Microsoft has rewritten a good bit of IE 7’s core code to help combat attacks that rely on malformed URLs (that typically cause a buffer overflow). It now funnels all URL processing through a single function (thus reducing the amount of code that “looks” at URLs).

All good stuff, but I agree with this conclusion:

IE 7 offers several new security features, but it’s hardly a given that the situation will improve. There has already been a set of security updates for IE 7 beta 1 released for both Windows Vista and Windows XP computers. Security vulnerabilities in a beta product shouldn’t be alarming (IE 7 is hardly what you’d consider “finished” at this point), but it may be a sign that the product’s architecture and design still have fundamental security issues.

I’m not switching from Opera yet, and my second choice is still Firefox. But the masses still use IE, and our security depends in part on those masses keeping their computers worm-free and bot-free.

NOTE: Here’s some info on how to get your own copy of Internet Explorer 7 beta 2.

Posted on February 9, 2006 at 3:37 PM • View Comments

Petnames

Interesting paper:

Zooko’s Triangle argues that names cannot be global, secure, and memorable, all at the same time. Domain names are an example: they are global, and memorable, but as the rapid rise of phishing demonstrates, they are not secure.

Though no single name can have all three properties, the petname system does indeed embody all three properties. Informal experiments with petname-like systems suggest that petnames can be both intuitive and effective. Experimental implementations already exist for simple extensions to existing browsers that could alleviate (possibly dramatically) the problems with phishing. As phishers gain sophistication, it seems compelling to experiment with petname systems as part of the solution.

Posted on February 8, 2006 at 11:25 AM • View Comments

Passlogix Misquotes Me in Their PR Material

I recently received a PR e-mail from a company called Passlogix:

Password security is still a very prevalent threat, 2005 had security gurus like Bruce Schneier publicly suggest that you actually write them down on sticky-notes. A recent survey stated 78% of employees use passwords as their primary forms of security, 52% use the same password for their accounts—yet 77% struggle to remember their passwords.

Actually, I don’t. I recommend writing your passwords down and keeping them in your wallet.

I know nothing about this company, but I am unhappy at their misrepresentation of what I said.

Posted on February 7, 2006 at 7:23 AM • View Comments

Forged Credentials and Security

In Beyond Fear, I wrote about the difficulty of verifying credentials. Here’s a real story about that very problem:

When Frank Coco pulled over a 24-year-old carpenter for driving erratically on Interstate 55, Coco was furious. Coco was driving his white Chevy Caprice with flashing lights and had to race in front of the young man and slam on his brakes to force him to stop.

Coco flashed his badge and shouted at the driver, Joe Lilja: “I’m a cop and when I tell you to pull over, you pull over, you motherf——!”

Coco punched Lilja in the face and tried to drag him out of his car.

But Lilja wasn’t resisting arrest. He wasn’t even sure what he’d done wrong.

“I thought, ‘Oh my God, I can’t believe he’s hitting me,’ ” Lilja recalled.

It was only after Lilja sped off to escape—leading Coco on a tire-squealing, 90-mph chase through the southwest suburbs—that Lilja learned the truth.

Coco wasn’t a cop at all.

He was a criminal.

There’s no obvious way to solve this. This is some of what I wrote in Beyond Fear:

Authentication systems suffer when they are rarely used and when people aren’t trained to use them.

[…]

Imagine you’re on an airplane, and Man A starts attacking a flight attendant. Man B jumps out of his seat, announces that he’s a sky marshal, and that he’s taking control of the flight and the attacker. (Presumably, the rest of the plane has subdued Man A by now.) Man C then stands up and says: “Don’t believe Man B. He’s not a sky marshal. He’s one of Man A’s cohorts. I’m really the sky marshal.”

What do you do? You could ask Man B for his sky marshal identification card, but how do you know what an authentic one looks like? If sky marshals travel completely incognito, perhaps neither the pilots nor the flight attendants know what a sky marshal identification card looks like. It doesn’t matter if the identification card is hard to forge if person authenticating the credential doesn’t have any idea what a real card looks like.

[…]

Many authentication systems are even more informal. When someone knocks on your door wearing an electric company uniform, you assume she’s there to read the meter. Similarly with deliverymen, service workers, and parking lot attendants. When I return my rental car, I don’t think twice about giving the keys to someone wearing the correct color uniform. And how often do people inspect a police officer’s badge? The potential for intimidation makes this security system even less effective.

Posted on January 13, 2006 at 7:00 AM • View Comments

Metadata in MS Office

Hidden metadata is in the news again. The New York Times reported that an unsigned Microsoft Word document being circulated by the Democratic National Committee was actually written by, wait for it, the Democratic National Committee.

Okay, so that’s not much of a revelation, but it does serve to remind us that there can be all sorts of unintended information hidden in Microsoft Office documents. The particular bits of unintended information that precipitated this news story is the metadata.

Metadata is information on who created the file, what it was originally called, etc. To see your metadata, open a file, go to the “File” menu, and choose “Properties.”

I’ll bet at least some of you will be really surprised by what’s in there. Not because it’s secret, but because it has nothing to do with you or your document. That’s because metadata follows the file, and not its contents.

Here’s what I do when I want to create a MS Word document. Maybe it’s a file I’ve written, and maybe it’s a file I received from someone else. I find some other document that has basically the same style I want, open it up, delete all the contents, and save it under a new filename. MS Word doesn’t change the metadata, so whatever was in the “Title,” “Subject”, “Author,” “Company,” and other fields of the original document remains in my new document. This means that occasionally those metadata fields are filled with information I’ve never seen of before and from who knows where. I’m sure I’m not the only one who uses this trick to avoid dealing with MS Word stylesheets. So metadata is much less a smoking gun than many make it out to be.

I don’t mean this to minimize the problem of hidden data in Microsoft Office documents. It’s not just the metadata, but comments, deleted parts of the document, even parts of other documents (it’s happened).

I have two recommendations regarding Microsoft Office and hidden data. The first is to realize that programs like Word and Excel are designed for authoring documents, not for publishing them. Get into the habit of saving your documents into pdf before distributing them. (Although if you’re going to redact a pdf document, be smart about it or you’ll have similar problems.)

The second is to install Microsoft’s tool for deleting hidden data. (Works for Office 2003; there are third-party tools for older versions.) Or at least read the page about deleting private data in MS Office files. And to follow through on deleting data.

This probably won’t work for many of us, though. The last sentence of the article explains why:

“The real scandal here,” Mr. Max told The Los Angeles Times after Democrats expressed outrage over the White House’s fingerprints on the testimony, “is that after 15 years of using Microsoft Word, I don’t know how to turn off ‘track changes.'”

Posted on November 14, 2005 at 12:07 PM • View Comments

Write Down Your Password

Microsoft’s Jesper Johansson urged people to write down their passwords.

This is good advice, and I’ve been saying it for years.

Simply, people can no longer remember passwords good enough to reliably defend against dictionary attacks, and are much more secure if they choose a password too complicated to remember and then write it down. We’re all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet.

Posted on June 17, 2005 at 8:40 AM • View Comments

Users Disabling Security

It’s an old story: users disable a security measure because it’s annoying, allowing an attacker to bypass the measure.

A rape defendant accused in a deadly courthouse rampage was able to enter the chambers of the judge slain in the attack and hold the occupants hostage because the door was unlocked and a buzzer entry system was not activated, a sheriff’s report says.

Security doesn’t work unless the users want it to work. This is true on the personal and national scale, with or without technology.

Posted on May 2, 2005 at 8:22 AM • View Comments

The Problem with Electronic Voting Machines

In the aftermath of the U.S.’s 2004 election, electronic voting machines are again in the news. Computerized machines lost votes, subtracted votes instead of adding them, and doubled votes. Because many of these machines have no paper audit trails, a large number of votes will never be counted. And while it is unlikely that deliberate voting-machine fraud changed the result of the presidential election, the Internet is buzzing with rumors and allegations of fraud in a number of different jurisdictions and races. It is still too early to tell if any of these problems affected any individual elections. Over the next several weeks we’ll see whether any of the information crystallizes into something significant.

The U.S has been here before. After 2000, voting machine problems made international headlines. The government appropriated money to fix the problems nationwide. Unfortunately, electronic voting machines—although presented as the solution—have largely made the problem worse. This doesn’t mean that these machines should be abandoned, but they need to be designed to increase both their accuracy, and peoples’ trust in their accuracy. This is difficult, but not impossible.

Before I can discuss electronic voting machines, I need to explain why voting is so difficult. Basically, a voting system has four required characteristics:

  1. Accuracy. The goal of any voting system is to establish the intent of each individual voter, and translate those intents into a final tally. To the extent that a voting system fails to do this, it is undesirable. This characteristic also includes security: It should be impossible to change someone else’s vote, ballot stuff, destroy votes, or otherwise affect the accuracy of the final tally.

  2. Anonymity. Secret ballots are fundamental to democracy, and voting systems must be designed to facilitate voter anonymity.

  3. Scalability. Voting systems need to be able to handle very large elections. One hundred million people vote for president in the United States. About 372 million people voted in India’s June elections, and over 115 million in Brazil’s October elections. The complexity of an election is another issue. Unlike many countries where the national election is a single vote for a person or a party, a United States voter is faced with dozens of individual election: national, local, and everything in between.

  4. Speed. Voting systems should produce results quickly. This is particularly important in the United States, where people expect to learn the results of the day’s election before bedtime. It’s less important in other countries, where people don’t mind waiting days—or even weeks—before the winner is announced.

Through the centuries, different technologies have done their best. Stones and pot shards dropped in Greek vases gave way to paper ballots dropped in sealed boxes. Mechanical voting booths, punch cards, and then optical scan machines replaced hand-counted ballots. New computerized voting machines promise even more efficiency, and Internet voting even more convenience.

But in the rush to improve speed and scalability, accuracy has been sacrificed. And to reiterate: accuracy is not how well the ballots are counted by, for example, a punch-card reader. It’s not how the tabulating machine deals with hanging chads, pregnant chads, or anything like that. Accuracy is how well the process translates voter intent into properly counted votes.

Technologies get in the way of accuracy by adding steps. Each additional step means more potential errors, simply because no technology is perfect. Consider an optical-scan voting system. The voter fills in ovals on a piece of paper, which is fed into an optical-scan reader. The reader senses the filled-in ovals and tabulates the votes. This system has several steps: voter to ballot to ovals to optical reader to vote tabulator to centralized total.

At each step, errors can occur. If the ballot is confusing, then some voters will fill in the wrong ovals. If a voter doesn’t fill them in properly, or if the reader is malfunctioning, then the sensor won’t sense the ovals properly. Mistakes in tabulation—either in the machine or when machine totals get aggregated into larger totals—also cause errors. A manual system—tallying the ballots by hand, and then doing it again to double-check—is more accurate simply because there are fewer steps.

The error rates in modern systems can be significant. Some voting technologies have a 5% error rate: one in twenty people who vote using the system don’t have their votes counted properly. This system works anyway because most of the time errors don’t matter. If you assume that the errors are uniformly distributed—in other words, that they affect each candidate with equal probability—then they won’t affect the final outcome except in very close races. So we’re willing to sacrifice accuracy to get a voting system that will more quickly handle large and complicated elections. In close races, errors can affect the outcome, and that’s the point of a recount. A recount is an alternate system of tabulating votes: one that is slower (because it’s manual), simpler (because it just focuses on one race), and therefore more accurate.

Note that this is only true if everyone votes using the same machines. If parts of town that tend to support candidate A use a voting system with a higher error rate than the voting system used in parts of town that tend to support candidate B, then the results will be skewed against candidate A. This is an important consideration in voting accuracy, although tangential to the topic of this essay.

With this background, the issue of computerized voting machines becomes clear. Actually, “computerized voting machines” is a bad choice of words. Many of today’s voting technologies involve computers. Computers tabulate both punch-card and optical-scan machines. The current debate centers around all-computer voting systems, primarily touch-screen systems, called Direct Record Electronic (DRE) machines. (The voting system used in India’s most recent election—a computer with a series of buttons—is subject to the same issues.) In these systems the voter is presented with a list of choices on a screen, perhaps multiple screens if there are multiple elections, and he indicates his choice by touching the screen. These machines are easy to use, produce final tallies immediately after the polls close, and can handle very complicated elections. They also can display instructions in different languages and allow for the blind or otherwise handicapped to vote without assistance.

They’re also more error-prone. The very same software that makes touch-screen voting systems so friendly also makes them inaccurate. And even worse, they’re inaccurate in precisely the worst possible way.

Bugs in software are commonplace, as any computer user knows. Computer programs regularly malfunction, sometimes in surprising and subtle ways. This is true for all software, including the software in computerized voting machines. For example:

In Fairfax County, VA, in 2003, a programming error in the electronic voting machines caused them to mysteriously subtract 100 votes from one particular candidates’ totals.

In San Bernardino County, CA in 2001, a programming error caused the computer to look for votes in the wrong portion of the ballot in 33 local elections, which meant that no votes registered on those ballots for that election. A recount was done by hand.

In Volusia County, FL in 2000, an electronic voting machine gave Al Gore a final vote count of negative 16,022 votes.

The 2003 election in Boone County, IA, had the electronic vote-counting equipment showing that more than 140,000 votes had been cast in the Nov. 4 municipal elections. The county has only 50,000 residents and less than half of them were eligible to vote in this election.

There are literally hundreds of similar stories.

What’s important about these problems is not that they resulted in a less accurate tally, but that the errors were not uniformly distributed; they affected one candidate more than the other. This means that you can’t assume that errors will cancel each other out and not affect the election; you have to assume that any error will skew the results significantly.

Another issue is that software can be hacked. That is, someone can deliberately introduce an error that modifies the result in favor of his preferred candidate. This has nothing to do with whether the voting machines are hooked up to the Internet on election day. The threat is that the computer code could be modified while it is being developed and tested, either by one of the programmers or a hacker who gains access to the voting machine company’s network. It’s much easier to surreptitiously modify a software system than a hardware system, and it’s much easier to make these modifications undetectable.

A third issue is that these problems can have further-reaching effects in software. A problem with a manual machine just affects that machine. A software problem, whether accidental or intentional, can affect many thousands of machines—and skew the results of an entire election.

Some have argued in favor of touch-screen voting systems, citing the millions of dollars that are handled every day by ATMs and other computerized financial systems. That argument ignores another vital characteristic of voting systems: anonymity. Computerized financial systems get most of their security from audit. If a problem is suspected, auditors can go back through the records of the system and figure out what happened. And if the problem turns out to be real, the transaction can be unwound and fixed. Because elections are anonymous, that kind of security just isn’t possible.

None of this means that we should abandon touch-screen voting; the benefits of DRE machines are too great to throw away. But it does mean that we need to recognize its limitations, and design systems that can be accurate despite them.

Computer security experts are unanimous on what to do. (Some voting experts disagree, but I think we’re all much better off listening to the computer security experts. The problems here are with the computer, not with the fact that the computer is being used in a voting application.) And they have two recommendations:

  1. DRE machines must have a voter-verifiable paper audit trails (sometimes called a voter-verified paper ballot). This is a paper ballot printed out by the voting machine, which the voter is allowed to look at and verify. He doesn’t take it home with him. Either he looks at it on the machine behind a glass screen, or he takes the paper and puts it into a ballot box. The point of this is twofold. One, it allows the voter to confirm that his vote was recorded in the manner he intended. And two, it provides the mechanism for a recount if there are problems with the machine.

  2. Software used on DRE machines must be open to public scrutiny. This also has two functions. One, it allows any interested party to examine the software and find bugs, which can then be corrected. This public analysis improves security. And two, it increases public confidence in the voting process. If the software is public, no one can insinuate that the voting system has unfairness built into the code. (Companies that make these machines regularly argue that they need to keep their software secret for security reasons. Don’t believe them. In this instance, secrecy has nothing to do with security.)

Computerized systems with these characteristics won’t be perfect—no piece of software is—but they’ll be much better than what we have now. We need to start treating voting software like we treat any other high-reliability system. The auditing that is conducted on slot machine software in the U.S. is significantly more meticulous than what is done to voting software. The development process for mission-critical airplane software makes voting software look like a slapdash affair. If we care about the integrity of our elections, this has to change.

Proponents of DREs often point to successful elections as “proof” that the systems work. That completely misses the point. The fear is that errors in the software—either accidental or deliberately introduced—can undetectably alter the final tallies. An election without any detected problems is no more a proof the system is reliable and secure than a night that no one broke into your house is proof that your door locks work. Maybe no one tried, or maybe someone tried and succeeded…and you don’t know it.

Even if we get the technology right, we still won’t be done. If the goal of a voting system is to accurately translate voter intent into a final tally, the voting machine is only one part of the overall system. In the 2004 U.S. election, problems with voter registration, untrained poll workers, ballot design, and procedures for handling problems resulted in far more votes not being counted than problems with the technology. But if we’re going to spend money on new voting technology, it makes sense to spend it on technology that makes the problem easier instead of harder.

This article originally appeared on openDemocracy.com.

Posted on November 10, 2004 at 9:15 AM • View Comments

Getting Out the Vote: Why is it so hard to run an honest election?

Four years after the Florida debacle of 2000 and two years after Congress passed the Help America Vote Act, voting problems are again in the news: confusing ballots, malfunctioning voting machines, problems over who’s registered and who isn’t. All this brings up a basic question: Why is it so hard to run an election?

A fundamental requirement for a democratic election is a secret ballot, and that’s the first reason. Computers regularly handle multimillion-dollar financial transactions, but much of their security comes from the ability to audit the transactions after the fact and correct problems that arise. Much of what they do can be done the next day if the system is down. Neither of these solutions works for elections.

American elections are particularly difficult because they’re so complicated. One ballot might have 50 different things to vote on, all but one different in each state and many different in each district. It’s much easier to hold national elections in India, where everyone casts a single vote, than in the United States. Additionally, American election systems need to be able to handle 100 million voters in a single day—an immense undertaking in the best of circumstances.

Speed is another factor. Americans demand election results before they go to sleep; we won’t stand for waiting more than two weeks before knowing who won, as happened in India and Afghanistan this year.

To make matters worse, voting systems are used infrequently, at most a few times a year. Systems that are used every day improve because people familiarize themselves with them, discover mistakes and figure out improvements. It seems as if we all have to relearn how to vote every time we do it.

It should be no surprise that there are problems with voting. What’s surprising is that there aren’t more problems. So how to make the system work better?—Simplicity: This is the key to making voting better. Registration should be as simple as possible. The voting process should be as simple as possible. Ballot designs should be simple, and they should be tested. The computer industry understands the science of user-interface—that knowledge should be applied to ballot design.—Uniformity: Simplicity leads to uniformity. The United States doesn’t have one set of voting rules or one voting system. It has 51 different sets of voting rules—one for every state and the District of Columbia—and even more systems. The more systems are standardized around the country, the more we can learn from each other’s mistakes.—Verifiability: Computerized voting machines might have a simple user interface, but complexity hides behind the screen and keyboard. To avoid even more problems, these machines should have a voter-verifiable paper ballot. This isn’t a receipt; it’s not something you take home with you. It’s a paper “ballot” with your votes—one that you verify for accuracy and then put in a ballot box. The machine provides quick tallies, but the paper is the basis for any recounts.—Transparency: All computer code used in voting machines should be public. This allows interested parties to examine the code and point out errors, resulting in continually improving security. Any voting-machine company that claims its code must remain secret for security reasons is lying. Security in computer systems comes from transparency—open systems that pass public scrutiny—and not secrecy.

But those are all solutions for the future. If you’re a voter this year, your options are fewer. My advice is to vote carefully. Read the instructions carefully, and ask questions if you are confused. Follow the instructions carefully, checking every step as you go. Remember that it might be impossible to correct a problem once you’ve finished voting. In many states—including California—you can request a paper ballot if you have any worries about the voting machine.

And be sure to vote. This year, thousands of people are watching and waiting at the polls to help voters make sure their vote counts.

This essay originally appeared in the San Francisco Chronicle.

Also read Avi Rubin’s op-ed on the subject.

Posted on October 31, 2004 at 9:13 AM • View Comments

1 … 6 7 8

Sidebar photo of Bruce Schneier by Joe MacInnis.