Slashdot Mirror
Secure Interaction Design
Pingster writes "Next week, ICICS 2002 will take place in Singapore.
Out of
40 papers at the conference,
there will be just
one paper
that looks at human factors.
Though many people know that
usability problems can render
even the strongest security useless,
the security community has only
recently started paying attention to usability issues.
More serious
thinking about usability and security
is desperately needed.
The paper proposes
ten
interaction design principles.
Maybe you'll find them obvious;
maybe you'll disagree with them entirely.
Great!
Let's have a discussion."
Poorly organized. Lynx-optimized website (with only two pages), only two months to write papers, an overly broad topic, and being held in a pseudo-third world country, away from the main countries where most research is being done, don't exactly add up to success. I'll be surprised if they register more than 500 attendees.
This isn't anything new really, the security vs. usability arguement has been a problem forever, and frankly, it's not something to be addressed. The more secure something is, the more you restrict its usage, and the more you restrict it the less useful it becomes. The most secure computer is one that is off, encased in concrete, and buried where no one will ever find it. This is equally true of physical security, as anyone whose ever had to wait at a metal detector will attest. Security isn't convenient, and it probably never will be.
If there is a God, you are an authorized representative. - Kurt Vonnegut Jr.
and other confusing concepts and they'll quickly go into Dummy mode and do whatever you tell them to. For this reason we should make it all more complex, so that those who understand will have an easier time controlling those who don't.
Give a man a fire he'll be warm for a night. Light a man on fire and he'll be warm for the rest of his life.
As it says, most people will work with something that is natural for them. But most computers users are used to current interfaces and ways of working, so will this mean just adapting the new security to existing ways of doing things?
Out of 40 papers at the conference, there will be just one paper that looks at human factors
There is a reason for this: the conference is about security. A large part of security is defining news ways of keeping systems secure, and usability is just one of the myriad factors. I think having even this one paper is overkill - I read it and don't think that it contributes very much.
Before you mod me down as flamebait, read the paper and honestly ask yourself if it tells you anything new at all.
The lack of ease of use security systems are often their greatest security flaw. Good security often make themselves hard to use, and thus undermine their own security. IE
- 10 character passwords, non-dictionary words, alpha-numeric. Safe, but can't remember them. So you write it on a post it note.
- Multiple levels of security. This means multiple usernames and passwords. This means the user keeps a list of them in their palm pilot/wallet.
- Secure systems invite back-doors (same as leaving a key under your door-mat...stupid, but very useful if you lock your keys inside).
Some companies base their security around no-one knowing anything about it. Microsoft is trying to do great things with UI the ease of use, but in doing so they destroy security.
If you do *not* have an easy to use high-security system, people *won't* use it! And if they don't use it, it is totally useless. People will always pick ease of use over security. They will pick IE and OE because things "just work", they will write their passwords on post-it notes on their screens, cause they can't remember them, they will leave keys under doormats.
I actually do disagree with the first: making the path of least resistance the most secure oft leaves the non-obvious approaches open to exploitation.
I already communicated to my sysadmin that my top security usability concern is that the post-it note with my password on my monitor peels off after about two months. We need better adhesives on our post-it notes.
I am very confused by that suggested principle. The most natural way to delete a file is to "rm file.txt". So that should be the most secure way to delete the file? What if I delete the file via my file manager? Should that be less secure?
I'm sure there are more details buried in the PDF files on their site... but the short summary of that principle sure confuses me.
Sex - Find It
I think user centered design is weak. That's what they do in Information Science, Psychology, and a little in the MIS field. What has it brought us? Not much. Not to flame, but concentrate on the system first, thats where you can do most of the changes the fastest. Users are fickle, and the time spent on user design, is time wasted that could be sent on securing the system.
...but, i find it really annoying that I havent found a program(s) that you can simply run on a remote system that you have access to, and it will tell you how exactly you need to configure your remote keys.
Maybe such a program exists? maybe a more specific one for openssh exists that will even give you the exact commands to enter to ssh-keygen.
-- -- --
Help my mini cause: My journal
What seems like an eternity ago myself and a friend were the admins of a beowulf cluster for a university physics department. Often times the user themselves would destroy any system security even before things like the interface was an issue. I can't tell you the number of times I'd walk into the lab where the cluster was stored only to find that someone using the machine logged into the mother node as root, left the machine sitting open to the world in an unlocked lab for 8 hour spans, taped the root password to the monitor, and then insisted that the highest priority we face be tightening up security, because they were having issues that the firewall wasn't detecting. ~growls~ At any rate... back to the debate between useability and security.
In my opinion, it's rare that I've seen anything blend robust power with a simple user interface. Usually in order to make things "more intuitive" for the user they've stripped down a lot of the options from the user. The logic behind this was that if the user has fewer choices, there's less the user has to know or think about when configuring something. On the other side of the coin, I've seen programs that are completely customizable, but you spend three days RTFMing trying to figure out why it doesn't work only to find out that the hexidecimal error message its spitting out is because there is a hidden space where there shouldnt be or some other small syntax error in a 30 page text configuration file.
The best ways that I've seen usability and functionality blended (which is the same as useability vs. any function such as security) have been when the simple choices were offered, but with an option right next to the choice to allow for greater customization of that specific choice.
Anyways, I've probably ranted enough for now. Best get back to work.
----- I want my LART.
Ps. The passphrase is a commonly used word in computers, 3 letters long, with only 2 distinct characters in it.
There seems to be a lot of confusion in the comments about the concept of usability. Usability is not the same as usefulness. Usability is the extent to which the usefulness of your program is achievable by users. This applies to all users, from novice to expert. A program may have a myriad of useful features, but what's the point if nobody uses them?
This is what the article is trying to get across: building security measures into tasks is pointless if the users don't utilize those measures. If the most natural way to do is task is insecure, then people will tend to use that insecure method. Making security quickly and naturally achievable by all users will result in more secure systems; the article is trying to set some guidelines about how to accomplish this.
Poorly organized. Lynx-optimized website (with only two pages) [freewebtools.com], only two months to write papers [lwn.net], an overly broad topic, [csoonline.com]and being held in a pseudo-third world country [krdl.org.sg], away from the main countries where most research is being done, don't exactly add up to success. I'll be surprised if they register more than 500 attendees.
This isn't flamebait or a troll, he has good points, and provided links to back up his claims. Instead of modding him down as flaimbait, why didn't you post a reply saying why you disagree with him?
These "10 principles" are fair as a whole, but it seems like they were more concerned with making the number of principles be 10 than they were with making the principles be unique, distinct, and useful.
look at how similar these are:
-- Visibility. The interface should allow the user to easily review any active actors and authority relationships that would affect security-relevant decisions.
--Identifiability. The interface should enforce that distinct objects and distinct actions have unspoofably identifiable and distinguishable representations.
It would be very difficult to follow one of these without following the other by default. Then when you get to the principle of Expressiveness you get a two-fer.
Most of the principles overlap so badly into each other that I'm not sure how they decided to draw the lines.
I guess they were going for some "magic number" that would feel powerful... like the 10 commandmants. I would be embarassed to have my name associated with that list.
All he did was restate the summary of the paper, and he gets a +4.
Who gets these mod points, and why do they spend them the way they do?
From the article: Clarity. The effect of any security-relevant action must be clearly apparent to the user before the action is taken.
Is this like clicking on that attachment that says "I_love_you.vbs" in Outlook? Or should the computer produce some sort of audible warning on mouse-over?
I don't keep a lid on my coffee so when I walk around I look busy -me
as you can see in the number of comments, this is definitely NOT a hot topic...
The principles seem primarily oriented toward interactive use of a security product and helping to explain how the product works in a GUI sort of way. I can easily see how they would be applied to explaining trust in a PGP situation.
However, most users (depends on the audience of course) aren't interested in security being interactive. They want it to be transparent just like all the other nuts and bolts. The only principle that really captures that idea is "path of least resistance".
I think a good example of the maximum interactivity of a security system might be the military's encrypted telephone lines. Press the "encrypt on" button, call, say "this is a secured line" and start talking. (I haven't actually used these systems, so if that is a misunderstanding, please say so).
I think security could easily be made more "under the hood". Look at the whole DRM thing...pretty under the hood. Imagine a system like that that was written to secure the end-user not the manufacturer.
Test. Purely a test
--
the strongest word is still the word "free"
What a crock. You obviuosly have never really done much secure system work. Security and usability are only in contention when people who only understand one side of the argument start dealing with people who only understand the other side of the problem. It is possible to have secure systems that do not place a significantly larger usage burden on the user if they are designed correctly, and Ping is one of the few people out there who I know has been thinking about this for more than fifteen minutes. This is not about security being convenient, it is about meeting security requirements without going the extreme that you suggest and making the useless system. Sometimes this requires that you add a bit of additional effort on the part of the user, but often it means that you actually use the UI to let the user know that an action they are about to perform has security implications that might not be obvious to a casual user.
There is an old, probably apocryphal story about how someone ran a test on a bunch of users that presented them with a bunch of modal dialog windows in the midst of a task and one of the windows asked the user if they wanted to reformat the disk. When the users get bored or frustrated with poor UI design they will often switch into auto-pilot and in this case they blindly hit the "yes" button because that was the proper response to all of the other modal dialogs that had been interrupting their work. When the users complained the person running the test pointed out that the system asked them if they wanted to reformat the disk and they had said yes.
Security and UI should never be considered independant items in system design, because if you can't communicate what is happening and the consequences of actions to users then the only security policy possible is the brain-dead ones that you suggest.
Why this work does apply almost entirely to GUI issues this is because the GUI is the tool through which 99.99% of the world uses a computer. For related work that shows some better examples by the same author I would suggest that you take a look at this paper (sorry for citing it Ping...) which provides some nice examples of how a GUI that explains the security implications of certain preference settings can be used for a mp3 player, etc. This paper is writen from the capability-semantics perspective, so the standard unix security model is already outclassed, but it will give you a better idea of how security and UI are related.
The seem to have forgotten at least one principle: The user must NOT be an idiot.
"Freedom means freedom for everybody" -- Dick Cheney
Is this like clicking on that attachment that says "I_love_you.vbs" in Outlook? Or should the computer produce some sort of audible warning on mouse-over?
In many cases I'd say it would have to involve a mouse mod that gives a 60kV shock, rather than just a beep.
Don't believe the nonsense, unless you hear it from me directly.
one thing that needs to be done is better components. i have a gpg key pair and an ssh key pair. i should really have just one. or at least have them on the same keyring. wouldn't it be nice if you could set up sshd to only allow key verified connections and only keys that had been signed by one of the admins?
/. posts.
gpg really needs to be made into a library, with the commandline as one user of that library. it would be easier to integrate gpg into mail/irc/web clients if you could make well defined api calls. something akin to ssh-agent might be nice for gpg. it would be nice if you could easily encrypt/sign irc or email traffic with your gpg keys. mutt does a pretty good job, but there are usability holes. it would also be nice if you could do things like sign
US Citizen living abroad? Register to vote!
A non moose cow's "UI with security" commandments:
1. Use logical security defaults. Users should not be burdened with security issues unless they want to be.
2. If a user chooses to look at or modify their security settings, options should be kept simple through massive abstraction, but should intuitively depict the meaning of the settings
3. All aspects of the UI should function the same way regardless of security settings.
Well, I tried to come up with more.. but that pretty much covers it. I guess I could make another list of "logical security defaults". That would be things like: If a remote entity requests a secure transaction, it should be granted without local user interaction.
The other points in the "10 principles" list really either don't apply to security or don't apply to the UI.
******
Mr. Owl, how many licks does it take to get to the center of a Tootsie-Roll Pop?
Jef Raskin, in his book "The Humane Interface" provides an answer to the username/password problem.
Firstly, no username. People know their own name better than any other word. Trying to give them another one is an exercise in futility. Usernames are frequently very easily guessable, and if all the system's passwords are unique, unnecessary.
Passwords should be system assigned, firstly to ensure uniqueness, and secondly to make damn sure that they are from an appropriately large set of possibilities. This particular set, which is quite easy for people to remember but incredibly large is the combination of 3 randomly selected nouns. For example BeachballTruckWaterpipe
The set of possiblities is vast. almost certainly larger than the set of all 8 character alpha-numeric strings, for example. It's not hard for a person to memorise something like this, so they won't have to write it down.
www.cgisecurity.com/lib
Some companies base their security around no-one knowing anything about it. Microsoft is trying to do great things with UI the ease of use, but in doing so they destroy security. You also use the term "IE" about ten times.
Worse, the 10 Priciples linked above are demonstrated with Windoze! Ah, what a waste. The trade off between ease of use and security is fictional. Best practices, such as unprivalidged user accounts, are just as easy to implement as an email account that automaticaly executes code sent by strangers. Sadly, many people think that M$ is the path of least resistance and that if only it can be secured, the world will be better off.
The problem of security in M$ apps is the distribution method - closed source. This can not be fixed and so Windoze can not be made secure. Don't take my word for it. Allow me to quote the this excellent summary from Sonnenreich and Yate's "Building Linux and OpenBSD Firewalls", John Wiley and Sons, 1999. It was true then, M$ has admitted most of it by now, and it will be true tomorrow because the model is the same:
The Windows platform was never built with security in mind; security was added as an afterthought. There are fundamental weakenesses in the operating system that can't be cured with a bandage. For example, background processes can run in a was such that they cannot be detected. ... Part of the problem stems from the fact that the vast majority of Windows packages are closed source. This means that only the original developers can identify and fix bugs in the software. Most Windows-based software products that aren't compiled directly from GNU licensed Unix source code are security disasters.
To make matters worse, companies confuse issues by claiming security though strong encryption. While the data in transit might be secure, that has nothing to do with wheter the program is secure on a fundamental level. For example, often encryption keys and passwords are stored on disks so users don't have to type them in every time. Regardless of how complex the scheme, the orignial information can always be recovered if the password is stored on disk and can be recovered by the program without user input.
Many windows applications are developed using common development libraries, most of which come from Microsoft. Hackers have repeatedly found insecurities such as buffer overflow conditions in these libraries. It becomes trivail to detaermine if an application has been built using such a library. ... These libraries have provided hackers with a reliable and consistent set of exploits.
Laplinck, NetMeeting, PC Anywhere and other remote session control systems for Windows all rely on proprietary unpublished transport mechanisms to create an aura of security. While you may be unable to determine what these programs are doing with your data, rest assured that hackers know exactly how the data are being transported... Since nobody can see the source conde, and since only the vendor can created and distribute fixes, these programs are a hacker's dream.
Add to this the fact that M$ charges an arm and a leg for said development libraries while refusing to be responsible for them and you start to understand why there's a new IE hole every month and how those holes can be persistent and how binary "patches" can introduce just as many problems as they fix.
This flawed distribution model makes Windows the path of highest resistance for securing PC desktops. Microsoft's entire business model of crushing competition and devowering the profit for any and all innovation brought to the masses depends on it and they are unwilling to change. Their "Shared Source" initiative, MSDN and all do fail to share the libraries at fault. Microsoft steadfastly refused to share those libraries throughout their conviction and "remedy" for anti-competitive practices. Time and time again, they have used the power of their postion for abuse of their users instead of following better practices and I have little faith they will do any beter in the future. Follow M$ at your perril.
Friends don't help friends install M$ junk.
I know your post-it notes were a joke, but I just had to pass along what seems to be a good practice. There are so many bad practices out there already. Pet names, silly web based password generators, which leave themselves in chache, kid names, so easy to guese.
Friends don't help friends install M$ junk.
Poorly organized. Lynx-optimized website (with only two pages)
You would prefer Power Point slides as an invitiation? What's missing?
only two months to write papers,
You don't think people have papers ready? Whole books have been written on the subject.
an overly broad topic,
Yah, yah, security is like that.
and being held in a pseudo-third world country away from the main countries where most research is being done
Kiss my ass. What godforsaken little grey town are you from to brag about? Got any chip fab nearby?
I'll be surprised if they register more than 500 attendees.
Singapore might have more than that in it's LUG. The only problem these folks might have is that one or two of them take Windoze seriously, but that will be corrected when the presentations hit the screens and the questions bubble up and the truth is found.
Friends don't help friends install M$ junk.
The article depends heavily on distinguishing data ("objects") from code ("actors").
The distinction between an "actor" and an "object" can only be clear in a primitive system.
Get sophisticated, and the difference between code and data starts to blur.
Is your database report template an object, or an actor? It's both.
The blurring of the code/data distinction shows up in a lot of recent exploits. ILoveYou.VBS is an actor that looks like an object. That one was avoidable, but what about a GET or POST? They're data which causes code to run on the web server. From another point of view their content is a short web server program.
Sure, you can dream about analyzing and controlling the capabilities of data-which-causes-actions. But if you ever let it achieve Turing equivalence you can't even guarantee whether it halts.
[...keep in mind this is 'average office environment,' not 'CIA' here.]
;)
The advantage of having a reasonably secure physical token is that, when it's stolen, you have at least some chance of recognizing "Hey, someone stole my card!" You can then run to your sysadmin (or as sysadmin, you can smile when your user runs to you), get him to revoke that token from the system, and palm you off a new one.
The only trick is that the token can't be easily duplicable- the attack here is not one of 'cracking' the system at the console (presuming fairly reasonable physical security), it's one of copying your key. A 'true,' hidden-secret smartcard is perfect for the occasion... if you have to do a steal-and-scrape operation, or any other such thing, you're going to be leaving evidence that the token is compromised.
Contrast this to the hacks that occur all the time, where users are unaware for months that their accounts are compromised, they've been serving warez off the RIAA's computers, etc.
If you are Bob Worker Bee, trying to discard that spreadsheet with the CEO's salary in it, then yes, the default policy on your machine should be secure (three-swipe, whatever) deletion. If you're Bob, you don't know that rm has an option for 'secure' delete, and/or that if you just rm, it's still recoverable, and so forth. The sad thing is- whether or not the system is putting resources towards security, Bob's going to get a shiny new Dell as part of the company upgrade policy every 3 years.
Now, if you're Jim Software Engineer, and you need to clean up that build directory and get a fresh compile to your betatesters before tonight, you might be willing to use the (hypothetical) "rm --quick," counting on the (hypothetical) "sweep daemon" to clean up any confidential bits of code left in the deallocated blocks after you leave for the night and your workstation goes idle.
The problems with such things "SSL and SSH" is that unless people are aware of the security implications of what they are doing they can easily defeat the best security. SSL, SSH encription wont save you if your certificates are compromised, but people might not see the relationship between running an untrusted program on there system and this occuring. An even more important point, how do you decide what is a trusted program.
This is a very good point and it seems to be a reoccurring theme with computer system. Developers forget to consider people as part of the computer system. Management practices can be as useful and are often more important in improving system security. Are there general work areas where many people who don't know each other will access the system? Are there people actively investigating system security thought the life of the system.
It puzzles me that so many people have posted comments describing one or another common usability-related security problem that the paper discusses, but without even mentioning the solutions the paper offers.
Twitter says:
On Microsoft Windows or Linux, any code you run executes with your privileges by default. Running any code without, say, the privilege to send further email requires great effort with, say, Subterfugue.
Twitter continues:
Licensing Microsoft Windows freely would not solve its security problems; many of them exist in Linux, too, just as the quote you inserted explains in detail.
Beryllium Sphere says:
The paper doesn't really depend on that distinction, at least not in the way you think. One could call a process an actor, but an executable file an object, for example.
Well, if you run it with a ulimit on cputime, you can guarantee that it will halt in at most 10 CPU seconds. :) And if you
run it in a context where it has no filesystem access, you can
guarantee it won't delete any files; and if you run it in a context
where it has no network access, you can guarantee it won't send email.
Etc.
A non moose cow wrote:
Visibility means you can see the things that matter; identifiability means the things you can see don't look the same. They seem quite orthogonal to me.
Someone asked, "What, you mean rm file.c should be the most secure way to delete a file?" And Anonymous Coward responded:
Superb example.
I urge everyone to read this paper, at least. Thinking about security in the terms it suggests will change the landscape of computer security, and it could lead to solutions to the most persistent problems of both computer security and usability.
Sure, if you have the luxury of hand-picking your users and never letting in the idiots, then by all means, build an expert-only security system. But in the real world companies, universities, and other organizations have to deal with whatever users wash up out of the gene pool, which means you deal with idiots, CS geniuses, and also very bright people who happen to be very short tempered and difficult to deal with. IMO the worst category is not the idiots but the last one--the smart people who look for every way they can find to circumvent the system just on principle, or to save themselves a keystroke here or there.
why 10? Yet another academic paper that makes obvious points. I guess that 10 is just a nice number, and they probably stop coming out with more principles. In my experience people dont give a s-h-i-t about secururity if makes tasks harder or difficult to remember........ principle number 11 could be:
'Do not use the name of your pet as password'
We need to educate the users so they are aware of the potential risks. I'm waiting for the dummies series of
"Securing your pc for dummies"
that will be a good step, I think
thank you
I think that one of the best solutions for e-mail is to assign a 'user' to anyone sending a message; this 'user' will not have privileges to run code or send an e-mail or do other malicious things on the machine that the mail has been received.
Different e-mails will have different users: for example, if I receive a letter from my wife, I would have setup her e-mail account in my computer to execute code (of course by receiving the proper password from her email so nobody impersonates her). On the other hand, any spam or other unknown e-mail would be assigned to user 'anonymous' who doesn't have any rights whatsoever other than sending data to me.
Another solution for long passwords is for the PC to have a slot to insert a card where all my user info (including password) will be stored. Then, the PC will load the O/S and the proper account according to the information stored in the card. Of course the problem of stealing the card remains, but that is generic problem concerning all types of cards(only genetic identification would solve the identity theft problem). The card will solve the usability problem of long passwords: the user would not have to do anything else other than inserting the card.
And when you finally have a theoretically secure system but where the interaction design is intrusive enough that people abuse or don't use the security features you've so carefully designed, what have you gained?
User centered design is about making sure that all the time you spend perfecting your system design has any value to it and ends up being useful for the intended audience. Sure, from a far enough overhead view user centered design looks like stating the obvious, this is true for many fields. In reality there is ample evidence that it isn't, because man, do some interfaces suck for the intended audience.
Only by explicitly stating what everyone thought was obvious can we move beyond it. This is in a sense the essence of science.
-
Listen. Strange women lying in ponds distributing swords is no basis for a system of government.
I'm not a big fan of Jakob Nielson. (Especially ever since I meet him at CHI2002. Perhaps snubbed would be a better term.)
Still he has contributed a great deal and has an Alert Box article mentioning some of these same usability considerations as related to security. The article dates back to November 2000. Like many other postings here, the article is mainly focused on password policy and use.
The Alert Box Article
User Interaction Design for Secure Systems
by Ka-Ping Yee
Computer Science Department
University of California, Berkeley
Abstract:
The security of any computer system that is configured and operated by human beings critically depends on the information conveyed by the user interface, the decisions of the computer users, and the interpretation of their actions. We establish some starting points for reasoning about security from a user-centred point of view, by modelling a system in terms of actors and actions and introducing the concept of the subjective actor-ability state. We identify ten key principles for user interaction design in secure systems and give case studies to illustrate and justify each principle, describing real-world problems and possible solutions. We anticipate that this work will help guide the design and evaluation of secure systems.
The way they connect their dialogs to the windows that created them looks a little bit familiar, no?
About the fact that one single paper investigates human interaction: you have to understand how the computer science academic world works.
Conferences (at least the quality ones) and journals publish refereed papers. This means that the papers have to be reviewed by peers who try to gauge their soundness, interest and novelty.
Needless to say, papers about human interaction are difficult to evalute. Many of them are just lists of "pious principles". Few of them are actually backed by real-life studies (those are difficult to conduct well). You would have to take representative sample sets of users and ask them to use various systems and watch their behavior and ask their opinion.
Also, that kind of "soft" science that verges on social studies is traditionnally ill-considered in certain academic circles, which suspects it of being lots of talk and little scientific content.
All this makes it unsurprising that few papers get into such security conferences.