Showing posts with label user experience. Show all posts
Showing posts with label user experience. Show all posts
Tuesday, October 4, 2011
Thursday, September 22, 2011
Random factoids I've encountered in authentication user research so far
I've been doing user research about the experience around security and authentication for about a year now. Through a combination of interviews, surveys, and diary studies, I'm trying to put together scenarios of what all that authentication is like for people, what the hassle factors are of authentication, and what the burden is. Are there productivity costs? Are there trust costs? Are the tradeoffs worth it?
Here are some factoids that are going into the models and scenarios:
The average person has between 7 and 25 accounts that they log into every day. These are log-ins for computing devices, networks, software, and web sites.
About half of the accounts people log into every day are necessary for their jobs.
People actually authenticate themselves -- prove who they are to someone or some system -- many more times in the typical day than they realize.
People report authenticating about 15 times in a typical work day on average. This is probably grossly under-reported.
People have rational coping mechanisms:
- They try to use the same passwords in as many places as they can.
- At work, they find the account with the strictest password policy, create a password schema to meet that, and use the same password in all the other places it will work.
- Everyone has a personal password schema or algorithm that they think is unbreakable. They're proud that the organization's IT security people have not discovered their schema and made the password requirements stricter to eliminate their schema.
- People will choose to do some tasks on one device over another because the authentication on one is easier (or embedded or automated somehow).
- People choose the strength of the password based on their perceptions of the importance of the account they're registering for. For example, many people say they use weak passwords for social networking sites and stronger passwords for medical and financial web sites.*
Nearly everyone records their passwords somewhere: paper, email, or password locker software.
The stronger the requirements for a password, the more likely the person will write it down.
The stronger the requirements for a password, the more likely it will have to be reset after being changed for expiration.
The less frequently the password is used, the more likely it'll have to be reset at next use.
Remote access to work systems keeps some people from doing work that they would normally do outside of normal working hours.
At work, most authentication happens in the morning, and then in the early afternoon.
* This is probably a bad idea, as there is much more personally identifying information in a social networking profile and the security of the back-end systems is generally less stringent on social network sites than for medical and financial services web sites.
Wednesday, December 15, 2010
There's the ripple: From Gawker comments to personally identifying information
Okay, so Gawker was hacked. One might ask, "Why?" But I think the more interesting question is, "So what?"
On December 12, hackers posted a list of the usernames and passwords from a total batch of over a million users of Gawker Media web sites. (Gawker includes online media properties such as Gizmodo). According to the Wall Street Journal, the passwords were encrypted, but the hackers decoded 188,279 of them and published them. The WSJ.com published a list of the 50 most used out of those decoded.
WSJ.com complains that the most used passwords are extremely weak. But let's keep in mind that there are about 800,00 passwords the hackers didn't publish, and the reason might be that they're too difficult to decode, or at least it would take more time to decrypt them. The top 5 in the decoded dataset were
123456
password
12345678
lifehack
qwerty
The top choice, 123456, came in at over 3,000 uses within the dataset of 188,279. Taken together, it looks like the top 5 cover about 7,000 passwords out of the decoded, published dataset, or about 1 in 4 passwords, more or less.
So people have weak passwords on Gawker sites. So what?
Does it matter here? These are accounts set up so people can leave comments on online articles, thus preventing most spammers from taking over the comments. It's not like it's a big deal. The accounts are a hall pass for access.
WSJ.com goes on to examine whether there are differences in password usage by email provider (I assume they're going by the domain in the email addresses used as usernames for Gawker accounts). I think that WSJ.com is missing the point. There are a few problems with the practice of implementing accounts on comments to prevent spam. First, it puts the burden of keeping a clean site onto the users, rather than implementing stronger security on the server side. Second, having password access for leaving comments may stifle some would-be brilliant insights because people don't want to register on the site - not a great way to encourage engagement. Third, people use the same passwords on many sites. I don't blame users for this when there are sites like Gawkers' that require accounts to do basic things that wouldn't normally risk users' privacy and identity.
Let's talk a bit more about the first and third problems. They have some things in common.
Account management is for the convenience of site owners, not the protection of the users
Gawker Media and other media web sites have forced commenters to create accounts on their sites to prevent spammers from taking over the commenting space. Not having spammers makes it much easier to moderate the comments (if you're going to at all). So, the sites have traded the convenience of their readers for their own. That is, rather than employ someone or some technology to deal with the spam (or a combination), they implement an account management system, thus putting the burden on their readers to prevent comment spam.
Account management systems are often implemented to make it easier for IT and Security to do their jobs. While dealing with password maintenance issues has a cost, the cost is higher for users than for the organization. For the organization that is looking just at saving IT money, it's a win. For the organization that wants to create a loyal audience, registering on a site and maintaining a password create obstacles to participation.
By putting the burden on users to stop comment spam, media companies actually make their users' data less secure
As we know, people use the same usernames and passwords in as many places as they can. On average, people have between 15 and 25 username-password combinations they use every day. People who work with complex systems often have many, many more. So, when users make the tradeoffs between respecting security policy and getting to their goal, they make reasonable choices, usually in favor of their own efficiency. Thus, using the same username and password in multiple places, for both very risky, highly personal situations such as online banking and low security, low risk scenarios like leaving comments on Gizmodo.
A requirement like Gawker's has possibly inadvertently compromised the personal security of more than a million of its readers. When a hacker knows one username and password for you, along with anything else about you, it is fairly easy to break into all kinds of accounts you access online.
The security experience is the worst part of using nearly every site
IT has owned login and registration for so long, that designers and users alike have been trained to put up with whatever security engineers say needs doing. We rarely question the purpose of a security policy, what it is in response to, what the tradeoffs are, how it fits into the larger security plan of an organization, and what we want to the security experience to be for users. Most of the implementations are made without any user research or usability data at all.
As is the case with many security decisions in organizations, each issue is treated in isolation. Who would have thought that comment spam would interact with a) the security of the servers and b) the security of users' personally identifying information?
See also:
from Jeff Attwood
http://www.codinghorror.com/blog/2010/12/the-dirty-truth-about-web-passwords.html
from Richi Jennings at ComputerWorld
http://blogs.computerworld.com/17527/why_not_use_same_password_everywhere_gawker_shows_us?ta
the announcement from Gawker
http://gawker.com/5712615/commenting-accounts-compromised-++-change-your-passwords
ADDED 15 December 2010 at 3:30pm EST, from Karen Bachmann, from an email to me:
On December 12, hackers posted a list of the usernames and passwords from a total batch of over a million users of Gawker Media web sites. (Gawker includes online media properties such as Gizmodo). According to the Wall Street Journal, the passwords were encrypted, but the hackers decoded 188,279 of them and published them. The WSJ.com published a list of the 50 most used out of those decoded.
WSJ.com complains that the most used passwords are extremely weak. But let's keep in mind that there are about 800,00 passwords the hackers didn't publish, and the reason might be that they're too difficult to decode, or at least it would take more time to decrypt them. The top 5 in the decoded dataset were
123456
password
12345678
lifehack
qwerty
The top choice, 123456, came in at over 3,000 uses within the dataset of 188,279. Taken together, it looks like the top 5 cover about 7,000 passwords out of the decoded, published dataset, or about 1 in 4 passwords, more or less.
So people have weak passwords on Gawker sites. So what?
Does it matter here? These are accounts set up so people can leave comments on online articles, thus preventing most spammers from taking over the comments. It's not like it's a big deal. The accounts are a hall pass for access.
WSJ.com goes on to examine whether there are differences in password usage by email provider (I assume they're going by the domain in the email addresses used as usernames for Gawker accounts). I think that WSJ.com is missing the point. There are a few problems with the practice of implementing accounts on comments to prevent spam. First, it puts the burden of keeping a clean site onto the users, rather than implementing stronger security on the server side. Second, having password access for leaving comments may stifle some would-be brilliant insights because people don't want to register on the site - not a great way to encourage engagement. Third, people use the same passwords on many sites. I don't blame users for this when there are sites like Gawkers' that require accounts to do basic things that wouldn't normally risk users' privacy and identity.
Let's talk a bit more about the first and third problems. They have some things in common.
Account management is for the convenience of site owners, not the protection of the users
Gawker Media and other media web sites have forced commenters to create accounts on their sites to prevent spammers from taking over the commenting space. Not having spammers makes it much easier to moderate the comments (if you're going to at all). So, the sites have traded the convenience of their readers for their own. That is, rather than employ someone or some technology to deal with the spam (or a combination), they implement an account management system, thus putting the burden on their readers to prevent comment spam.
Account management systems are often implemented to make it easier for IT and Security to do their jobs. While dealing with password maintenance issues has a cost, the cost is higher for users than for the organization. For the organization that is looking just at saving IT money, it's a win. For the organization that wants to create a loyal audience, registering on a site and maintaining a password create obstacles to participation.
By putting the burden on users to stop comment spam, media companies actually make their users' data less secure
As we know, people use the same usernames and passwords in as many places as they can. On average, people have between 15 and 25 username-password combinations they use every day. People who work with complex systems often have many, many more. So, when users make the tradeoffs between respecting security policy and getting to their goal, they make reasonable choices, usually in favor of their own efficiency. Thus, using the same username and password in multiple places, for both very risky, highly personal situations such as online banking and low security, low risk scenarios like leaving comments on Gizmodo.
A requirement like Gawker's has possibly inadvertently compromised the personal security of more than a million of its readers. When a hacker knows one username and password for you, along with anything else about you, it is fairly easy to break into all kinds of accounts you access online.
The security experience is the worst part of using nearly every site
IT has owned login and registration for so long, that designers and users alike have been trained to put up with whatever security engineers say needs doing. We rarely question the purpose of a security policy, what it is in response to, what the tradeoffs are, how it fits into the larger security plan of an organization, and what we want to the security experience to be for users. Most of the implementations are made without any user research or usability data at all.
As is the case with many security decisions in organizations, each issue is treated in isolation. Who would have thought that comment spam would interact with a) the security of the servers and b) the security of users' personally identifying information?
See also:
from Jeff Attwood
http://www.codinghorror.com/blog/2010/12/the-dirty-truth-about-web-passwords.html
from Richi Jennings at ComputerWorld
http://blogs.computerworld.com/17527/why_not_use_same_password_everywhere_gawker_shows_us?ta
the announcement from Gawker
http://gawker.com/5712615/commenting-accounts-compromised-++-change-your-passwords
ADDED 15 December 2010 at 3:30pm EST, from Karen Bachmann, from an email to me:
Good points, Dana. I recently worked with a client who has a strong financial need to know that they are reaching the right audience, highly specialized professionals looking for detailed technical information. Visitors are currently required to set up an account and have to log in with username and password each time they visit. The information, though, is not restricted. Anyone can create an account.
When I interviewed members of their intended audience, having to log in to get to non-sensitive information was a huge but familiar barrier to entry. Most people were resigned to this with all websites of this type in their field, but none were happy about it. During the interviews, I actually asked people to interact with the site and saw several problems regularly. 1) Those who had created accounts either forgot completely that they had because of time between visits. 2) Visitors who knew they had accounts forgot their credentials, a problem they indicated was common for their interactions with others site of this type. 3) The most Web savvy stated that they had a standard "throwaway" set of credentials that they would always use on a site like this. When asked about their likely use of the site, most said that they would usually just go elsewhere for the information when the credentials got in their way.
Since the basic use wasn't really about guarding access to the information, I recommended to my client that they simply request an email address as a short-term solution, and omit full credentials for access. If they still required an account (more details about the user), account management would require a login. However, in the longer term, technology could actually take most of the burden from users. The company has a huge database of contacts that could be used to cross reference emails entered. Handling this on their servers would actually provide them with even more data about types of users than the account information they collected.
The managers at the client indicated they really just assumed that the only way they could gather their information was with an account and credentials model. They had not really considered their real needs against the user perception and goals. They intend to make the change I recommended as part of their redesign, which is still pending.
Wednesday, August 18, 2010
Truly secure security questions
Organizations from financial services companies to e-commerce web sites have implemented "security questions" in the log on process. The idea is that, in addition to a username and password, your answering these questions correctly, helps authenticate you to a system.
The idea is good: Provide an answer to a question that only you could know is the correct answer.
But many of the questions are weak, either because they're answerable from publicly available information (mother's maiden name; what if that is her name?), or there's a special format to entering them (case-sensitivity is often a problem).
In addition, security questions seem to be bundled by particular vendors, so a user might get the same questions from organization to organization. This could be an advantage for the user, but also for the cracker, acting like single sign-on. For opinion-based or favorites questions, there's a memorability problem: How did I answer this question last time? Did I answer it the same way on all the sites I've chosen it on? The answers to questions of "favorites" change over time. What's your favorite color? This is a question that, if answered incorrectly, can have dire consequences.
Which leads to a classic workaround: Choose the most outlandish question in the list and answer it with a passphrase. Have to answer multiple security questions? Answer them all with the same passphrase. This subverts the purpose of the questions, but makes it easier for the user as she crosses the hurdles to making an investment, making a purchase, or getting lab results from her health care provider.
And so, I offer some of the most ridiculous *real* security questions, followed by some that some friends brainstormed during a rant about this so-called security mechanism.
Garry Scoville writes regularly about security questions and related topics at http://goodsecurityquestions.com. He's an authority on what makes a less weak question (asserting all the time that there are no good security questions). His list of examples is excellent.
Real, ridiculous security questions
Among the real security questions used in real systems are some of these gems, which I've borrowed from goodsecruityquestions.com:
What is the name of the High School you graduated from? (What if you didn't graduate?)
What is your pet's name? (What if you don't have pets?)
How many bones have you broken? (In my own body or someone else's?)
On which wrist do you wear your watch? (The third one)
What is the color of your eyes? (Seriously? It says that on my driver's license)
What is your favorite teacher's nickname? (Mine for her? Or hers for her?)
What is the name of your hometown? (You think I might have moved once in my life?)
What is the color of your father’s eyes? (He has eyes?)
What is the color of your mother’s eyes? (The ones in the front of her head or the back?)
What is your favorite color? (Blue! No - green! Ahhhhh!)
What was your hair color as a child? (Either black or white because that's what color the photos are.)
What is your work address? (I work at home. Hmmm.)
What is the street name your work or office is located on? (Why don't I just tell the hacker what room the PC is in?)
What is your address, phone number? (And, by the way, the list of passwords is stored in the top right drawer.)
Questions I wish they'd ask
What was your first boyfriend's favorite car brand?
What color was your first grade teacher's house?
How long did your first pet live?
When will global warming end?
Why did your girlfriend say that about your mother?
Why am I soft in the middle?
How can you live in the city?
How dare you?
What is the point of these questions?
What's your favorite security question?
The idea is good: Provide an answer to a question that only you could know is the correct answer.
But many of the questions are weak, either because they're answerable from publicly available information (mother's maiden name; what if that is her name?), or there's a special format to entering them (case-sensitivity is often a problem).
In addition, security questions seem to be bundled by particular vendors, so a user might get the same questions from organization to organization. This could be an advantage for the user, but also for the cracker, acting like single sign-on. For opinion-based or favorites questions, there's a memorability problem: How did I answer this question last time? Did I answer it the same way on all the sites I've chosen it on? The answers to questions of "favorites" change over time. What's your favorite color? This is a question that, if answered incorrectly, can have dire consequences.
Which leads to a classic workaround: Choose the most outlandish question in the list and answer it with a passphrase. Have to answer multiple security questions? Answer them all with the same passphrase. This subverts the purpose of the questions, but makes it easier for the user as she crosses the hurdles to making an investment, making a purchase, or getting lab results from her health care provider.
And so, I offer some of the most ridiculous *real* security questions, followed by some that some friends brainstormed during a rant about this so-called security mechanism.
Garry Scoville writes regularly about security questions and related topics at http://goodsecurityquestions.com. He's an authority on what makes a less weak question (asserting all the time that there are no good security questions). His list of examples is excellent.
Real, ridiculous security questions
Among the real security questions used in real systems are some of these gems, which I've borrowed from goodsecruityquestions.com:
What is the name of the High School you graduated from? (What if you didn't graduate?)
What is your pet's name? (What if you don't have pets?)
How many bones have you broken? (In my own body or someone else's?)
On which wrist do you wear your watch? (The third one)
What is the color of your eyes? (Seriously? It says that on my driver's license)
What is your favorite teacher's nickname? (Mine for her? Or hers for her?)
What is the name of your hometown? (You think I might have moved once in my life?)
What is the color of your father’s eyes? (He has eyes?)
What is the color of your mother’s eyes? (The ones in the front of her head or the back?)
What is your favorite color? (Blue! No - green! Ahhhhh!)
What was your hair color as a child? (Either black or white because that's what color the photos are.)
What is your work address? (I work at home. Hmmm.)
What is the street name your work or office is located on? (Why don't I just tell the hacker what room the PC is in?)
What is your address, phone number? (And, by the way, the list of passwords is stored in the top right drawer.)
Questions I wish they'd ask
What was your first boyfriend's favorite car brand?
What color was your first grade teacher's house?
How long did your first pet live?
When will global warming end?
Why did your girlfriend say that about your mother?
Why am I soft in the middle?
How can you live in the city?
How dare you?
What is the point of these questions?
What's your favorite security question?
Wednesday, July 28, 2010
RANT: What makes you think your content is this important?
 |
| vark.com registration dialog |
Dear Vark.com,
I want to ask one question of the Vark community. What makes Vark think that doing that is worth filling out this invasive registration page? Why are birthday and gender required? (What are you doing with that data and how are you protecting it?)
Never mind. I'll just ask Twitter my question.
Thanks anyway,
Dana
Monday, June 28, 2010
Authentication stinks.
I love researching and designing user experiences.
There are so many ways to make them not only not suck, but also to make them good, happy, even wonderful. Designers influence nearly every aspect of the user experience these days. UX people have a seat at nearly every table in the organization, helping to make great experiences for customers and users.
There's one table left: Security.
We don't have a seat next to the CSO because we have neglected that part of the experience, and because (usually), the CSO is a paranoid who is really scary so we think we can't influence that part of the experience.
This is a call for action: Let's make friends with the security people. Let's teach them to look at the tradeoffs between security and usability. Let's help them understand that authentication is part of the customer experience that is so important, it could be killing the business.
Think of all the times you log into something each day, each time you identify yourself to something or someone. What's that like? Why are you putting up with it? Why are you letting your customers go through that?
In this blog, I'm going to catalog every encounter with authentication that I can get my hands on and discuss the design implications of what the imposer of the authentication is creating and possibly missing.
There are so many ways to make them not only not suck, but also to make them good, happy, even wonderful. Designers influence nearly every aspect of the user experience these days. UX people have a seat at nearly every table in the organization, helping to make great experiences for customers and users.
There's one table left: Security.
We don't have a seat next to the CSO because we have neglected that part of the experience, and because (usually), the CSO is a paranoid who is really scary so we think we can't influence that part of the experience.
This is a call for action: Let's make friends with the security people. Let's teach them to look at the tradeoffs between security and usability. Let's help them understand that authentication is part of the customer experience that is so important, it could be killing the business.
Think of all the times you log into something each day, each time you identify yourself to something or someone. What's that like? Why are you putting up with it? Why are you letting your customers go through that?
In this blog, I'm going to catalog every encounter with authentication that I can get my hands on and discuss the design implications of what the imposer of the authentication is creating and possibly missing.
Subscribe to:
Posts (Atom)