Slashdot Mirror


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.

65 comments

  1. Re:Buy it HERE! by Daniel_Staal · · Score: 2, Funny

    That A9.com discount sounds like a privacy issue to me. Someone should look into the security implications.

    --
    'Sensible' is a curse word.
  2. "security applications and systems" only?? by 44BSD · · Score: 4, Informative

    The reviewer seems to think that security and usability are meant to be attributes only of security applications. That presumption is in error.

    1. Re:"security applications and systems" only?? by Proaxiom · · Score: 4, Informative
      Good point. Designing security into general applications that does not interfere with the user experience is a far more interesting problem than designing usable security systems.

      The adage that security is the opposite of usability is false, of course. The problem is that people aren't very good at making intelligent design decisions when faced with both sets of requirements.

      There is a great paper on this subject by Ka-Ping Yee here (PDF link).

    2. Re:"security applications and systems" only?? by Anonymous Coward · · Score: 0

      I noticed that too. For someone working in the security industry, I'd hope he realizes that security is not a product, but a process. When I think of security and usability, I don't think of how user-friendly specific programs are. I think of finding the right balance between getting work done, and getting work done according to your definition of "security". This whole review comes off as a 4th grade Hardy Boys Book Club type affair.

    3. Re:"security applications and systems" only?? by timeOday · · Score: 2, Insightful
      The adage that security is the opposite of usability is false, of course.
      IMHO they generally are. Having worked at a secure facility, it is expensive and inconvenient. That trickles all the way down to the desktop PC, having apps broken by firewalls, not being able to install software needed to get the job done, being unable to get access to network services I need because I can't keep track of dozens of randomly generated passwords that change every 6 months, having a computer that runs like molasses because of virus checking and software inventory daemons, being way behind the upgrade curve... it just goes on.
    4. Re:"security applications and systems" only?? by jesser · · Score: 2, Informative

      Ka-Ping Yee also maintains a blog on the subject: usablesecurity.com.

      --
      The shareholder is always right.
    5. Re:"security applications and systems" only?? by Jherek+Carnelian · · Score: 4, Insightful

      Having worked at secure facilities for longer than I care to remember, I am familiar with all of the problems you list and more. But the key at all of the secure sites I've worked at is that usuability is not a requirement put upon those who create and implement security policy. So they often make decisions based on how easy it makes their job as a security officer and not how difficult it makes life for the users. Thus they tend to come up with all manner of silly policies that marginally improve security while seriously degrading usuability. As long as they don't cause work to completely halt, they usually get away with such draconian policies.

      If the security guys had to take responsibility for the indirect costs of their policies, I believe we would see a marked improvement in the usuability of the facilities being secured, probably bringing with it an increase in actual security because there would be less incentive for people to do bad things like write down a list of their 15 different passwords and what not.

    6. Re:"security applications and systems" only?? by georgewad · · Score: 1

      >If the security guys had to take responsibility for the indirect costs of their policies,

      There would be no security.

      --
      Karma: It's not just a good idea. It's the law.
    7. Re:"security applications and systems" only?? by SCHecklerX · · Score: 1

      It's easier for me to copy a file using a passwordless ssh key than it is to use ftp. It's easier for me to remotely run a X11 app over ssh than it is to manually telnet into the box and run the app. It's easier for a client to have a client side certificate to authenticate to a web site than to have them remember a userid and password.

    8. Re:"security applications and systems" only?? by TheRealSlimShady · · Score: 2, Interesting
      Thus they tend to come up with all manner of silly policies that marginally improve security while seriously degrading usuability. As long as they don't cause work to completely halt, they usually get away with such draconian policies.

      They either get away with them, or the users find subtle ways to work around them, thus negating the policy completely. Either that or the users ignore the policy completely. The best security policies are the ones you can explain to the people who are affected by it and have them understand both the risk, and why you've implemented the policy. If you can't explain how the policy addresses a security risk, it's probably not a good policy...

    9. Re:"security applications and systems" only?? by timeOday · · Score: 1
      It's easier for me to copy a file using a passwordless ssh key than it is to use ftp.
      But don't you see, the inconvenient password-protected applications you mention wouldn't need passwords at all if not for security.

      It's true that a particular app can be more secure and more usable than another particular app; insecurity certainly doesn't guarantee usability! So, yes, I think a book like the one being discussed could be a great thing. Besides, in the real world security is sometimes more important that usability.

      But I still hold that usability and security are essentially in tension. Usability is about enabling people to do things, while security is about preventing people from doing things. Ideally you'd prevent all the bad things while allowing all the good things, but in the real world that never quite happens.

  3. rofl by Anonymous Coward · · Score: 0, Troll

    What about the children?

  4. Interesting by Pandora's+Vox · · Score: 2, Insightful

    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.

    1. Re:Interesting by Anonymous Coward · · Score: 0

      I believe you should stfu

  5. not called "easy to use" because... by fdisk3hs · · Score: 2, Interesting

    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.

    1. Re:not called "easy to use" because... by hal9000(jr) · · Score: 4, Insightful

      security != easy.

      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. No context, no explaination, your lucky if you can get the file path. So users start saying yes and pretty soon, that desktop firewall is swiss chese. Couldn't the vendors have at least profiles Windows services and common applications and told the user something like "The Windows Messenger service is trying to listen for connections. If your a home user, you probably don't need this, so say No. If your an company user, ask your IT staff if you need it." rather than some long path. That's useability.

      What about all the vendors selling home internet firewalls? Most home users don't need a firewall, they need a NAPT router. If they are running games or an on-line service, then perhaps they need to port forward, but all the rest of that stuff is cruft. But for $50 more you can get a stateful firewall. You don't need it, but you can get it.

      These are examples of making the deploymnet of security needlessly complex. Oh, and it gets no better in enterprise security.

      There is a lot that could be done to make security easier to deploy while still being robust.

    2. Re:not called "easy to use" because... by Anonymous Coward · · Score: 0

      ZoneAlarm Pro does that; when it asks the user whether they want to allow or block something at the firewall, it'll give its recommendation, which for the most part is correct.

    3. Re:not called "easy to use" because... by Anonymous Coward · · Score: 1, Funny

      you iz 31337 calculus skillz!!! pwned!

    4. Re:not called "easy to use" because... by fdisk3hs · · Score: 1

      Ahh, it's just a way to say that if you have a little of something divided into infinite badness, your little bit of something is a drop in the bucket. I use this as a joke at work: if b=botnet infected computers, and h=happiness, then lim b->oo h/b = 0 happiness.

    5. Re:not called "easy to use" because... by Fortran+IV · · Score: 1
      ZoneAlarm Pro does that; when it asks the user whether they want to allow or block something at the firewall, it'll give its recommendation, which for the most part is correct.
      Maybe so, but ZoneAlarm free edition, at any rate, has some extraordinarily foolish shortfalls.

      For instance, if you update Windows or your AV/AS software and ZA gives you the "This program has changed since it last ran" message, ZA won't tell you what settings you had for the program before it was updated.

      Also, despite ZoneLab's insistence to the contrary, every time ZA has updated itself, it's erased every program setting in its database. I now keep screenshots of the settings I've decided are correct.
      --
      I figure by 2030 or so my 6-digit UID will be something to brag about.
    6. Re:not called "easy to use" because... by Anonymous Coward · · Score: 0

      The problem is that the naive user -- the one who most needs the desktop firewall -- is not going to think it's doing anything unless it pops up messages from time to time.

      The popups are about marketing, not about security or usability. If it's not popping up windows, how does the user know it's there?

  6. Social Engineering Becoming More Serious by kmactane · · Score: 3, Insightful

    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.

    1. Re:Social Engineering Becoming More Serious by CastrTroy · · Score: 2, Interesting

      Social engineering will always be the broken part of security. You can have a system that requires users to have a 20 character randomly generated password, as well as a smart card, and they will still pass their password around along with their card, which will have the password written on the back. Until people start taking computer security seriously, there will be no end to the security breaches. One of the real problems is that we tend to put a lot of the blame on those breaking into the systems. The user is usually not only relieved from blame, but also get pitied for being the poor user that was attacked by the nasty con artist. While some of the blame lies with those doing the cracking, more blame should be put on the users, especially when they should know better. Phishing techniques when you get directed to some website, where you proceed to enter your username and password are in most cases completely avoidable. But people still sympathize with them, and blame it on the bad guys. Nobody would give people the same kind of sympathy if they handed their wallet over to the wallet inspector on a downtown street corner, or got their possessions stolen after leaving their door wide open. Why are we so quick to feel sorry for people, just because it happened on a computer?

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    2. Re:Social Engineering Becoming More Serious by Spril · · Score: 2, Insightful

      > You can have a system that requires users to have a 20 character randomly
      > generated password, as well as a smart card, and they will still pass their
      > password around along with their card, which will have the password written
      > on the back.

      Don't miss the correlation here. If you require users to have a 20 character randomly generated password, how could they remember it? Like rational beings presented with an impossible problem, they wouldn't--they'd write it down.

      When security people come up with ridiculous, badly-designed security requirements that make it difficult for users to get their jobs done, the users will find workarounds. Rather than shoving their responsibility onto users by creating onerous hoops to jump through, security people need to understand usability, to make systems which are actually secure, and not which are theoretically secure only when impossible requirements are met, in your case that normal people can memorize a 20-character string of nonsense characters.

      That's apparently what this book is all about.

    3. Re:Social Engineering Becoming More Serious by CastrTroy · · Score: 1

      The problem is, is that if you allow people to choose any password they want, many will choose a short, easy to guess password. I guess if they don't have to write it down, then it's more secure than a 20 character password which they do write down, but it is still very insecure. Making the system vulnerable to stuff that people can give away will always make it less secure. Until we move to something like retinal scans, the password will always be able to be given away by the user. And social engineering will therefore be trivially easy. Even with retinal scans, you could still fall prey to social engineering tricks, where new guy in the office asks to use your retinal scan, because his isn't working.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    4. Re:Social Engineering Becoming More Serious by kentborg · · Score: 1

      > The problem is, is that if you allow people to choose any password
      > they want, many will choose a short, easy to guess password.

      A good password needs to have some significant randomness in it and
      people are really bad judges of randomness. Even some pretty nerdly
      folks can be really näive on this.

      > I guess if they don't have to write it down, then it's more secure
      > than a 20 character password which they do write down, but it is
      > still very insecure.

      What's wrong with writing down a password? Honestly, what is so wrong
      with it? Yes, the proverbial postit note with the password stuck on
      the edge of the monitor provides nearly* no security for a foe who is
      sitting front of the computer, but the monitor is probably in your
      home (where you store other valuable things), or in your office (where
      a stranger walking in might be noticed by a coworker). The recent
      scary innovation is that the bad guy who guesses that your password is
      "Frodo" might be anywhere in the world where there is an internet
      connection, which is a lot bigger than the small space in front of
      your desk.

      To have good security one has to stop and consider what the problem
      is. What are you trying to protect, from whom, for how long?

      Take the person with the password "jumbo-joker-basil" (a password used
      for only one purpose) written on a piece of paper in his wallet, and
      compare him with the person who uses a Really Good Password like
      "Oog3gear" in many places but doesn't write it down. Which is better?

      The jumbo-joker-basil password that gets written down is probably more
      secure. The risk of someone stealing the wallet, knowing the
      significance of jumbo-joker-basil, being interested in doing something
      with it, and actually doing something about it before the person with
      the lost wallet can get the password changed, is limited. On the
      other side, the chances that someone who *is* interested in passwords
      manages to compromise some other account that also uses the Oog3gear,
      is very real, and when it happens, unlike the stolen wallet example,
      the authorized user probably won't know the password has been stolen
      and won't know to quickly change it. Writing down a password, if it
      makes it possible to not reuse passwords, is almost always a worthy
      tradeoff--particularly if it can be "written down" encrypted in a PDA
      with something like the free Palm application "Keyring".

      As for the two example passwords above, disregarding whether they are
      reused or written down, which is more secure? The one with the most
      entropy in it. Which is that? "jumbo-joker-basil"

      "Oog3gear" is a pretty weak password. It is probably OK if your foe
      can only try guessing passwords at a slow rate, but if your foe gets a
      chance to brute force it quickly (i.e., if used for cryptography) it
      is terrible!

      This password was generated by pwgen in its default mode. In this
      mode it produces passwords that are:

      - Exactly 8 characters long,
      - Have exactly one capital letter,
      - Have exactly one numerical digit, and
      - Are pretty easily pronounceable for an english speaker.

      Because of the redundancy in english-like words, and because of the
      other constraints on pwgen output, the number of possible outputs from
      pwgen is not as large as one might first guess.

      But the real killer for pwgen is that by default it spits out a whole
      screen of suggestions and a human gets to pick one "at random". I
      have not seen a scientific study on how subjects pick from this list,
      but *my* tendency is to pick an easy to remember item, one that
      includes a real english word, one with repetition, one that is
      capitalized in a language-like way. The result is that the universe of passwords
      actually chosen from pwgen output are likely a small, relatively
      predictable, set. I once estimated that the number of bits of entopy
      in a typical pw

  7. "new author every chapter" by tcopeland · · Score: 1, Interesting

    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 :-)

  8. Residential products by Barkley44 · · Score: 1

    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
  9. Mod down, same kaleidojewel spam as always by Anonymous Coward · · Score: 0

    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.

  10. Re:In case of slashdotting by Mr2cents · · Score: 1, Funny

    I wish there was a "-1: Bold" mod.

    --
    "It's too bad that stupidity isn't painful." - Anton LaVey
  11. Re:Buy it HERE! by VStrider · · Score: 2, Funny

    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.
  12. Comment removed by account_deleted · · Score: 2, Funny

    Comment removed based on user account deletion

  13. Re:Buy it HERE! by Anonymous Coward · · Score: 0

    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!

  14. Security and usability are mutually exclusive by calvin1981 · · Score: 2, Interesting

    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.

    1. Re:Security and usability are mutually exclusive by CastrTroy · · Score: 1

      In the same way, it's very hard to have a home PC that functions without bugs. Its impossible to know what kind of software the user will be running, as well as what stuff the user doesn't even know their running. I've run many windows systems that were very stable over the years. The trick is, keep the installed software base small, and only install that which is completely necessary. Most of the buggy, crashy windows installations I see are own by people who install everything they see, without even stopping to think what the program may do to their system, or whether they will really even use that software after 3 days. This is the reason no software vendors garauntee that their software will even do what it is supposed to do. Because they have no way of knowing the conditions under which is was run, and therefore can't control whether it will work or not. If you want to have a system that works perfectly all the time, be prepared to pay a lot for it, and be prepared for it to have very little functionality.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    2. Re:Security and usability are mutually exclusive by offal · · Score: 1

      So don't get immersed in cataloging all the things in the wild, that burns too many cycles and changes everyday. Just catalog that which needs to be done. Once you understand what needs to run, and how, and with who, etc. configure your systems and networks to accomodate those needs, and only those needs. Apply all rules such that you permit what you need to, and default to drop. It makes the world much smaller and less scary, and much easier to manage. This is a condensed version of Markus Ranum's "Six Dumbest Ideas In Computer Security" (google it) that did wonders for my ability to more effectively resource those limited resources.

    3. Re:Security and usability are mutually exclusive by calvin1981 · · Score: 1

      So don't get immersed in cataloging all the things in the wild, that burns too many cycles and changes everyday.

      Aha, here goes the point. One can pare down a software system by limiting the number of situations in which the software is supposed to work correctly. This is not possible in security -- you can limit what you do, not what a malicious adversary can do. It is a much scarier situation to deal with, and that is why crypto is hard.

    4. Re:Security and usability are mutually exclusive by twiddlingbits · · Score: 1

      No, you CAN pare down the variables into discrete sets so that you cover 95% of the threats for a reasonable cost and time. Occam's Razor and Paretos Rule apply in security just as in other parts of IT. You cannot make a system 100% secure for all situations unless you have infinte time or money so you have to compromise wisely. People and weak security processes are more likely to cause loss than purely a technological attack. After all, 90% of the hacks come from INSIDE the company.

    5. Re:Security and usability are mutually exclusive by offal · · Score: 1

      But if you architect your environment such that network checks and host checks complement your policy, so you don't rely solely on one or the other sentry to do it's job, there's much less wiggle room for an exploit to work. One example is not allowing IRC if you don't use it. Many worms and rootkits attempt to open up an IRC channel, so this layered approach would prevent the potential zombie from "reporting in" via the firewall, which is configured to block IRC ports. Likewise configuring hosts to only run what they need minimizes exposure from a network breach. It's like securing a "real life" event by knowing who "should" be there, not trying to remember who "shouldn't" be there. That creates a smaller set to focus on. I'm not saying it's simple, just easier.

    6. Re:Security and usability are mutually exclusive by Anonymous Coward · · Score: 1, Interesting

      Security and usability are only mutually exclusive when you are stuck with old (traditional modern) security approaches. It does not have to be this way. The book contains an article by Ka-Ping Yee that points the way to resolving this apparent conflict. Software systems that demonstrate the points made by Yee include the Polaris secure desktop being developed at HP, the CapDesk secure distributed desktop developed by Combex, and the Web Calculus secure bookmark system developed by Waterken. These example systems have all been created by members of the object-capability community, you can read more about their work at http://www.erights.org./

    7. Re:Security and usability are mutually exclusive by Anonymous Coward · · Score: 0

      What a buttload of crap. Secure design simply means enumerating the states you want your software to be in and ensuring that only those states are reachable. You don't have to worry about "attacks", all you have to worry about is writing type-safe code, and ensuring that the types you choose express the proper functionality of the system. For instance, sendmail has been notoriously filled with holes, but it's really just a very simple concept. The problem is that none of the pieces are properly designed, and they're all hacked together. A proper mailserver defines what messages are (sequences of bytes) which a well defined header which is either well defined and parsable or is in error and the message is rejected. Part of the problem is that Unix doesn't really use this design approach with regard to security or anything else for that matter. Everything is a file, which completely ignored the actual relationships between the files and the processes and users that access them.

      Unix's ideal of everything being a file must die, or at least change to incorporate the definition of functions and types in terms of files, and allow proper security to be enforced over functions and types. Only then will software programming be "easy" again, in terms of getting security right.

  15. Firewalls? by LilGuy · · Score: 2, Interesting

    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.
    1. Re:Firewalls? by Tankko · · Score: 5, Insightful

      Problem is, those little boxes start to pop up almost immediately. One of the first is "Microsoft Subsystem Spooler is trying to access the Internet. OK?".

      What the hell if the Subsystem spooler? Can it be used by other programs to avoid detection? I have no idea. It would be nice if Zone Alarm spend an once of effort explaining what all these things were.

    2. Re:Firewalls? by Anonymous Coward · · Score: 0

      Yeah, all my neighbors seem to have figured out how to get their wireless routers up and running, no problem.

  16. Inversely Proportional by MrNougat · · Score: 0

    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
  17. you're in the wrong realm by ChipMonk · · Score: 1

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

  18. Instant Messaging by saskboy · · Score: 2, Informative

    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.
    1. Re:Instant Messaging by Paul68 · · Score: 1

      And this is a MAJOR security issue! Allowing a PC to open outside ports to itself is the perfect vehicle for creating a backdoor into the system. I always turn UPnP off for that reason.

      It may be possible to make something that is both incredibly easy to use and secure but this is definitely not it.

  19. Why security can't be easy to use by G4from128k · · Score: 2, Insightful
    Security is all about preventing undesirable events. Yet these systems will always be subject to false-positives -- preventing the user from taking a legitimate actions. For example, I hate *nix file permission systems because its too easy to set the permissions too restrictively and run into "permission denied" problems when working across several accounts and file systems. Sure, I can chmod things, but that's an added hassle (each added step or command is to the detriment of ease of use).

    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.
    1. Re:Why security can't be easy to use by Anonymous Coward · · Score: 0

      False positives are pretty much an accepted evil
      I can't believe you would state that you hate the security system that makes it too easy to be secure -- maybe you should just realize the fine detail work that it actually takes? Easy to use, difficult to master!

      Other than that, I agree. That gap will remain permanent until the end-user starts to see things from the paranoid view of the net security analyst. Then they'll happily accept a few permission denieds, knowing that it probably means someone can't break in. Or at least will have a harder time doing so.

    2. Re:Why security can't be easy to use by zestyping · · Score: 1
      Security is all about preventing undesirable events.
      True — but so is usability. It improves both security and usability to ensure that desirable events do happen and undesirable events don't happen.
      Even if we add a wonderful UI to security, it will never be perfect.
      Real usability isn't about "adding a wonderful UI" to things. Real usability means changing what the system requires you to know, changing how the system forces you to do things, and changing how the system responds to your actions, so that it does what you're telling it to do. If the computer knows what you're telling it to do, it can set the security parameters appropriately to suit your intent.
      Security is about saying "no", ease of use is about saying "yes."
      This is a common argument about the conflict between security and usability. I agree with you that it holds today for many systems, because those systems embed the idea that security is an indiscriminate no and usability is an indiscriminate yes. However, i believe it doesn't have to stay true. If we design systems from the ground up that are centered on user intent, good security and good usability both follow. If you have a few minutes, you might want to look at an article i wrote about this last year.
  20. Usable security app example by foniksonik · · Score: 1

    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.
  21. I found user-friendly and absolutelly secure! by Ruvim · · Score: 2, Funny
    I found user-friendly and absolutelly secure solution!

    .

    .

    It's called a power switch!
    Once you fleep it "off", you can be sure your system is safe!

  22. The errors in your reasoning by einhverfr · · Score: 2, Insightful

    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
  23. Laziness will always trump ease of use by Anonymous Coward · · Score: 0

    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.

  24. Are Usability & Security Opposites in Computin by krozinov · · Score: 1

    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.

    http://rozinov.sfs.poly.edu/papers/security_vs_usa bility.pdf
    http://it.slashdot.org/article.pl?sid=04/11/15/142 0246

  25. Re:Are Usability & Security Opposites in Compu by Anonymous Coward · · Score: 0

    You can also have insecure systems that are horrible to use.

  26. The point is, it's usually not stupidity by Beryllium+Sphere(tm) · · Score: 1

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

  27. Bibliography by starfishsystems · · Score: 1
    Another very useful resource at that site is a bibliography on security and usability compiled by Rachna Dhamija.

    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.