Security and Usability
ewuehler writes "I don't think I've ever heard a security application, be it a consumer anti-virus application or an enterprise IPS application, described as "user-friendly" or "easy to use". When I read the title of the O'Reilly book Security and Usability: Designing Secure Systems That People Can Use, I took the bait and requested a copy for review. The title could also double as my current job description, so I was equally interested from a "job education" point of view. The book is a collection of (mostly) academic articles, grouped in sections and chapters. Each article/chapter is written by different authors; from Bruce Tognazzini who founded Apple's Human Interface Group to Blake Ross of Firefox fame to names previously unknown to me. Read on for ewuehlers' review.
Security and Usability
author
Edited by Lorrie Faith Cranor & Simson Garfinkel
pages
714
publisher
O'Reilly
rating
8
reviewer
Eric Wuehler
ISBN
0-596-00827-9
summary
Designing Secure Systems That People Can Use
Along with the variety of authors, their backgrounds are equally diverse. The majority of the articles come from academia, with a few corporate names and open source authors. While not exclusively US authors, the majority of the articles come from US institutions. Generally, I would expect the "new author every chapter" approach to be a distraction, but the editors have done a good job at grouping the articles and cross-referencing chapters where appropriate. However, I did not find this a cover-to-cover read, the book lends itself well to "flipping and skipping" around.
The editors claim the goal of the book is "first for researchers in the field of security of usability, then for students, and finally for professionals." While I fit in the "professionals" category (not a term I'd use, but I had to pick one of the three), I found the information very helpful and educational with respect to my current job. With a majority of the chapters coming from an academic perspective, there is room for debate and interpretation of the conclusions. For example, several chapters discuss the fallibility of passwords, making it obvious the issue of password security is not just simply whether or not to write them down.
The book is divided into six parts. The first, Realigning Usability and Security, introduces the premise of the book. These five chapters discuss the importance of usability when designing security applications. It is well known that the human element is "the weakest link in the chain" of system security. For example, "Kevin Mitnick revealed that he hardly ever cracked a password, because it 'was easier to dupe people into revealing it' by employing a range of social engineering techniques. He points out that to date, attackers have paid more attention to the human element in security than security designers have." The implication being the less usable the security, the less likely it will be used correctly, no matter how good it actually is. The chapters go on to describe different processes for designing usable secure systems and applications.
The Authentication Mechanisms section discusses the usability requirements around passwords and other authentication techniques. The information in this section dealt more with implementation than theory as compared to the other sections. The expected chapters covering the prevailing forms of authentication; text passwords, challenge questions, graphical passwords, and biometrics are there. I found most interesting the chapter Identifying Users from Their Typing Patterns. This refers to "keystroke biometrics" which "seeks to identify individuals by their typing characteristics." The concept has been around for a while and first suggested for identification in 1975. (Random fact I found interesting, it finds its roots in 19th century telegraph operators who could often identify each other by listening to the rhythm of each individual's Morse code keying pattern.) Despite the fact that the concept has been around for quite a while, it does not seem to appear much on the authentication mechanism radar.
Secure Systems is the "make or break" section covering the secure user experience. These chapters cover things such as fighting "phishing" at the user interface, making PKI easy, and "deleting" files vs. really deleting files. One of the more interesting chapters looks at security tools and practices based on ethnographic field studies. While ethnography (the study of customs of individual peoples and cultures) initially does not sound like a "security or usability" issue, it is used (and the author claims quite effectively) to understand "the work practices of computer users in context, informing the design of computer systems to better suit their needs."
The section Privacy and Anonymity Systems contains a chapter discussing Google's Gmail privacy policy with respect to "informed consent". For the most part, the authors give Gmail high marks, with the privacy concerns rooted in differing definitions of "privacy". For example, if you believe that content-targeted advertisements should require the consent of all parties involved, you (in sending an email to a Gmail user) have not consented to the targeted ads the recipient sees. The chapter describes two other cases of informed consent and presents a list of ten design principles based on the information. Another chapter discusses leveraging social processes for managing browser cookies. The concept being when a cookie is saved stored, it will provide you aggregate community data such as X percent of the people visiting this site blocked the cookie. One obvious benefit is the ability to educate "less knowledgeable" users about "good" cookies vs "bad" cookies.
The remaining sections discuss usability of products, for which the chapter titles are description enough. Overall, I found the book useful. The variety of authors and subject matter made it easy to skip around and choose what piqued my interest at the time. Along with the academic feel of the book, each chapter is generally descriptive enough to get an idea as to what subject matter will be covered. While the book's target is "researchers and students" first, as a "professional" working for a security company, I found it helped me better explain the pros and cons of these topics to the less technical people I work with every day. I'd recommend it to anyone involved with the usability of security applications and systems."
You can purchase Security and Usability from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Along with the variety of authors, their backgrounds are equally diverse. The majority of the articles come from academia, with a few corporate names and open source authors. While not exclusively US authors, the majority of the articles come from US institutions. Generally, I would expect the "new author every chapter" approach to be a distraction, but the editors have done a good job at grouping the articles and cross-referencing chapters where appropriate. However, I did not find this a cover-to-cover read, the book lends itself well to "flipping and skipping" around.
The editors claim the goal of the book is "first for researchers in the field of security of usability, then for students, and finally for professionals." While I fit in the "professionals" category (not a term I'd use, but I had to pick one of the three), I found the information very helpful and educational with respect to my current job. With a majority of the chapters coming from an academic perspective, there is room for debate and interpretation of the conclusions. For example, several chapters discuss the fallibility of passwords, making it obvious the issue of password security is not just simply whether or not to write them down.
The book is divided into six parts. The first, Realigning Usability and Security, introduces the premise of the book. These five chapters discuss the importance of usability when designing security applications. It is well known that the human element is "the weakest link in the chain" of system security. For example, "Kevin Mitnick revealed that he hardly ever cracked a password, because it 'was easier to dupe people into revealing it' by employing a range of social engineering techniques. He points out that to date, attackers have paid more attention to the human element in security than security designers have." The implication being the less usable the security, the less likely it will be used correctly, no matter how good it actually is. The chapters go on to describe different processes for designing usable secure systems and applications.
The Authentication Mechanisms section discusses the usability requirements around passwords and other authentication techniques. The information in this section dealt more with implementation than theory as compared to the other sections. The expected chapters covering the prevailing forms of authentication; text passwords, challenge questions, graphical passwords, and biometrics are there. I found most interesting the chapter Identifying Users from Their Typing Patterns. This refers to "keystroke biometrics" which "seeks to identify individuals by their typing characteristics." The concept has been around for a while and first suggested for identification in 1975. (Random fact I found interesting, it finds its roots in 19th century telegraph operators who could often identify each other by listening to the rhythm of each individual's Morse code keying pattern.) Despite the fact that the concept has been around for quite a while, it does not seem to appear much on the authentication mechanism radar.
Secure Systems is the "make or break" section covering the secure user experience. These chapters cover things such as fighting "phishing" at the user interface, making PKI easy, and "deleting" files vs. really deleting files. One of the more interesting chapters looks at security tools and practices based on ethnographic field studies. While ethnography (the study of customs of individual peoples and cultures) initially does not sound like a "security or usability" issue, it is used (and the author claims quite effectively) to understand "the work practices of computer users in context, informing the design of computer systems to better suit their needs."
The section Privacy and Anonymity Systems contains a chapter discussing Google's Gmail privacy policy with respect to "informed consent". For the most part, the authors give Gmail high marks, with the privacy concerns rooted in differing definitions of "privacy". For example, if you believe that content-targeted advertisements should require the consent of all parties involved, you (in sending an email to a Gmail user) have not consented to the targeted ads the recipient sees. The chapter describes two other cases of informed consent and presents a list of ten design principles based on the information. Another chapter discusses leveraging social processes for managing browser cookies. The concept being when a cookie is saved stored, it will provide you aggregate community data such as X percent of the people visiting this site blocked the cookie. One obvious benefit is the ability to educate "less knowledgeable" users about "good" cookies vs "bad" cookies.
The remaining sections discuss usability of products, for which the chapter titles are description enough. Overall, I found the book useful. The variety of authors and subject matter made it easy to skip around and choose what piqued my interest at the time. Along with the academic feel of the book, each chapter is generally descriptive enough to get an idea as to what subject matter will be covered. While the book's target is "researchers and students" first, as a "professional" working for a security company, I found it helped me better explain the pros and cons of these topics to the less technical people I work with every day. I'd recommend it to anyone involved with the usability of security applications and systems."
You can purchase Security and Usability from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
That A9.com discount sounds like a privacy issue to me. Someone should look into the security implications.
'Sensible' is a curse word.
The reviewer seems to think that security and usability are meant to be attributes only of security applications. That presumption is in error.
What about the children?
This looks like an excellent and long-overdue book. As the t-shirt says, "there is no patch for human stupidity" - making secure systems usable is really the more challenging part.
security != easy.
In fact, lim v->oo s/v = 0, where s=security and v=variables in your environment. No real security, but you try.
I cringe when I see all those books at the local computer mart with titles like "TCP/IP Security" with a cheesy rainbox-colored logo beside it that says "Made Easy" in an italic font. Publishers actually think people trying to secure networks will be fooled by a logo that belongs on a home decorating book or manual can opener package?
Having ranted, I'm sure the O'Reilly book is probably good. It certainly helps to get on top of things if you can at least sort all of your marbles into buckets, instead of watching them roll around randomly underfoot.
The "social engineering" concerns that were brought up in the paragraph about Mitnick have now become large-scale issues that affect everyone from site operators to end-users. Every phishing attack is essentially a social engineering attempt. Many worms, from "I Love You" on to the current IM worm, spread by convincing each new recipient that they're safe to execute— again, a social engineering attack.
It's too bad this 714-page book probably won't be read by the average end-user; the fact that the current IM worm is still spreading is ample proof that users still aren't sufficiently aware of social engineering issues. And that affects all of us; the spam I just cleared out of my inbox probably came through a zombie machine that got infected by just such a worm.
Kai MacTane: Web developer for hire in San Francisco
Sometime this seems to work out well, sometimes not. I thought that the Pattern Languages of Program Design editors did a nice job on making that work, and the same goes for the excellent Game Programming Gems series.
:-)
On the other hand, sometime you can really tell that one author wrote a book and was interested in the topic - i.e., Component Development for the Java Platform by Stuart Halloway comes to mind. This was an excellent book for intermediate to advanced Java programmers and Stuart's interest in how things really work in Java serialization, classloaders, and so forth shines through.
And hopefully the same goes for PMD Applied
The Army reading list
I think residential products are getting easier to use now, with easier and cleaner interfaces. But this is easier to do than corporate applications due to the complexity of what's involved.
KeepTrackOfIt.com - Find the lowest gas prices in your area graphically
Hmmm, $44.95 at both B&N *and* at Amazon, yet you claim "save yourself some money"... oh, wait, I get it. You want that $0.05 referral bonus. Pathetic.
I wish there was a "-1: Bold" mod.
"It's too bad that stupidity isn't painful." - Anton LaVey
Why is parent modded funny? There are some serious privacy issues here for those accepting this offer. From the A9 site: "Just make sure that you are recognized by name when you use A9.com, and your Instant Reward will be applied automatically"
VStrider.
Comment removed based on user account deletion
It MUST be hard to use, or the windoz noobs will use it and then the universe will collapse and burn and bill gaytes rises as the one and only lord and we all get it up the butt and our pets revolt and linux is banned!
Security/Cryptography is not easy, almost by definition, because you are building systems that withstand all attacks -- even ones you cannot foresee at the time of design. Defense is hard when you dont know exactly what to defend against. As opposed to traditional software design, where, you have a very well-defined goal to meet. Such paranoia almost always leads to lack of usability.
I'd say most consumer grade firewall applications are incredibly easy to use. I have had friends fire up that one really popular ZoneAlarm or whatever and get it to lockdown their connections, even as they barely know how to install a piece of software. It doesn't get much easier than that.
Then again, once the little popup messages start rolling in, they have a few questions for me, but all in all I'm impressed with the ease of use.
You're nothing; like me.
Generally speaking, a system that is most easy to use is least secure, and a system that is least easy to use is most secure.
Examples:
An 'easiest' system is where you instantly get what output you desire, no matter where you are relative to the system, without having to provide any input (including identification). Such a system is infinitely easy to use. And since so identification is required, any user can get output from the system, making it not at all secure.
A 'most secure' system is where no matter what inputs you provide, including identification, you cannot gain the output you desire. This system is not easy to use - to the point of uselessness - but infinitely secure.
Web 2.0 == Giant Blogspam Circle Jerk
Information access control and verified identity (and the resulting explicit, rather than implicit, trust) can be quite simple. My company deals with security professionals every day, and they are very pleased with the simultaneous high security and ease of use in our product. We're handling compliance requirements for some tightly-regulated industries, without requiring any changes in the way they do their business.
(Unfortunately for this comment, I've promised not to do any astro-turfing for my company.)
Before UPnP routers started to play nicely with Yahoo and MSN Messenger, getting a messenger with voice communication to work properly behind NAT was a NATMARE [said with southern accent for some humour]! Hardware and software can definitely be improved to be more user friendly, while at the same time be more secure, since it's better to have a router with a firewall or at least NAT, than to be connected to the Internet naked just so you can use MSN Messenger with Voice. And I mean the computer being naked, not the user.
Saskboy's blog is good. 9 out of 10 dentists agree.
In contrast, the easiest systems require no passwords, no authentication, and let the user do anything they want to any file, anywhere. But that is not secure.
Yet I'd argue that security can be made easier. Single sign-on and password keychains help (although these arguably reduce security somewhat). The bigger solution is goal-oriented UIs, not mechanism-oriented UIs. Current security often assumes that the user understands the internals of the system -- that particular ports provide particular functions or vulnerabilities. Easy-to-use security software would guide the user is defining what they want to allow or disallow and hide technical details of how that is implemented.
Even if we add a wonderful UI to security, it will never be perfect. Security is about saying "no", ease of use is about saying "yes." To that extent, the gap between security and ease-of use is permanent.
Two wrongs don't make a right, but three lefts do.
Little Snitch (which unfortunately is only OS X) is the most usable security type of application I've ever used.
It's essentially a network monitor app similar to Zone Alarm for the PC but IMHO 1000% more usable.
When a request is made either by an app on your machine or from a remote machine to access a port, Snitch pops up a dialogue that asks you whether you want to allow or deny it, for that port or all ports, until the app quits or forever.
This simple selection is enough to cover 99% of all cases. ie: if you're not sure what the app is doing, you can deny it temporarily (game server X on ports 6003 7002 27010 27015 27025 ) and look up what it's trying to do, then restart the app and allow it for the duration of your session; if you know you want it to continue you can set it to allow/forever/ports (browser X on port 80 forever); if you know you don't want it to continue or ever work again (warez app x on port that tells anti-warez company x that you've got warez) then deny forever.
This is the best firewall you can ask for. You don't have to know all the ports you want open precognitively but you still have control over your apps and your ports.
If you mess up, there is a simple control panel that lets you edit or delete your preferences per app.
It's beautiful... it only gets in the way when it's needed and it's easy to understand, in fact I started it up without even looking at a readme file much less a manual of documentation.
That's usability AND security.
What it won't do is filter traffic on a port, so a good net filter or anti-virus is still useful (granted it's OS X so maybe not that useful) but worms, unwanted intrusions and various types of phone-home spyware won't be causing any problems (ie a key logger you didn't know about). Also, you become much more aware of what/who your computer is talking to in the background, very enlightening.
A fool throws a stone into a well and a thousand sages can not remove it.
It's called a power switch!
Once you fleep it "off", you can be sure your system is safe!
But security doesn't have to be hard, either. Look at desktop firewalls. I last looked at them (zone, sygate, symantec)maybe two years ago, so perhaps they have gotten better, but, user install it and all of a sudden they get a bunch of pop-ups asking if this or that can access the internet and do you want to let it.
:-)
Security is a process, not a product. More on this below.
Now.... People usually say "there is a tradeoff between usability and security." What they really mean is "There is a tradeoff between usability, security, and the amount of effort required to design and maintain the security of the system." You can have very good security if you take the effort to design a good, secure network with unintrusive security technologies, avoid undue consolidation of both software and systems, and otherwise take care to minimize and compartmentalize damage from any security compromise.
If you see security as a product and not a process than something that gets through your Great Security Product will have free reign on your system. So instead it is a common practice to include stuff like assessment of applications, etc. Products alone cannot buy you security. This is why security is always hard and will always be hard, as long as there are insecure apps in the world
LedgerSMB: Open source Accounting/ERP
There are more than a gaggle of senior gov't officials (carreer and political appointees) who routinely compromise national security because they can't be *bothered* to use even the simplest of solutions. Official gov't business is conducted DAILY over Yahoo Mail. I'm not kidding. And no, of course nothing is encrypted.
Why do you think the USN killed all webmail? Next we need every other military service to do the same thing and especially the civilian arm of the Defense Department.
Instinct tells us that computer security and computer usability are inversely proportional to each other. In other words, the tougher and stricter the security is, the less usability there is, and vice versa. However, there have been plenty of cases where both computer security and computer usability went hand in hand with each other and actually improved together. In the last few years security has been the biggest buzzword in computer systems and as such has become part of our computer systems. Before that, computer systems were all about getting it done faster and easier, but now they must also do it securely. Can the two continue growing together? We believe they can, as evident by the most recent Indian Assembly Election.
a bility.pdf2 0246
http://rozinov.sfs.poly.edu/papers/security_vs_us
http://it.slashdot.org/article.pl?sid=04/11/15/14
You can also have insecure systems that are horrible to use.
>As the t-shirt says, "there is no patch for human stupidity"
Industrial and aerospace safety made their big improvements when they stopped blaming accidents on stupidity (or more politely, "pilot error" or "operator error"). Professionals in those fields took a step back and investigated whether the "stupid" user was even getting the information s/he needed, whether that information was being buried by irrelevancies, and whether the user was trained to understand the system well enough to build a correct mental picture of it.
Not exactly usability engineering, but closely related.
Unfortunately it hasn't been updated for some years, but it's a good starting point for someone looking to put together a more complete bibliography.
Parity: What to do when the weekend comes.