Authentical

Courtesy message sent by a service machine

2012-02-07T19:34:00.002-05:00

We love you. And we have only your best interests at heart. Really.

Changing your password more than 1x within 24 hours makes us suspicious

2012-02-07T19:25:00.000-05:00

Just create 9 versions of your password, and we'll leave you alone.

If you allow your password to expire, you will not be able to receive email

2012-01-12T17:50:00.001-05:00

Not having access to email wouldn't be so bad, really.

What I love is the confirmation message at the bottom. We've just told you to change your password. Someone has changed your password, but we don't know who. We hope you do.

Interesting that there are no actual password rules here, only expiration warnings.

Your password will be automatically reset

2012-01-11T16:11:00.001-05:00

Why should I change the password as soon as possible, if it doesn't expire for 10 days?

Your password will expire in 10 days

2012-01-09T14:23:00.000-05:00

I'm collecting expiration and password policy information. Have you received an email like this one? Send it on! Let's collect them all!

(I won't show any personally identifying information or company/organization names.)

I love that getting an error message is step 13.

Hassle factors of 2-factor authentication in banking at HSBC

2011-10-04T11:43:00.000-04:00

Random factoids I've encountered in authentication user research so far

2011-09-22T11:04:00.001-04:00

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.

Oh, Etsy. How could you?

2011-03-21T17:18:00.004-04:00

During the last holiday season, I called Land's End. I hardly ever call; I'm a huge fan of their online experience. I wanted to send a special order to my mother, putting two matching things in the same gift box. Landsend.com isn't really set up to do that, but the site instructed me that I could do it, so I called.

The sales rep was friendly and efficient, and very helpful. She pulled up my order-in-progress and put everything in the box that I wanted to be in my mother's gift. When she asked me if there was anything else she could help me with, I blithely said, "You could check my mother's account and tell me what she's sending me for Christmas." The sales rep giggled, teased me a little bit by telling me that she could see my mother's account, but told me I would have to wait until UPS delivered it to find out. She protected the relationship between the seller and the buyer. She also protected the relationship between two buyers – me and my mother -- at least for that episode. If I wanted to find out what I was getting for Christmas, I'd either have to wheedle it out of my mother or wait.

Respect and research. That's all I ask.

Facebook had a go at Beacon, a service that broadcasted out to all your friends the purchases you've made outside of Facebook, without permission. The Federal Trade Commission sued, and Facebook eventually settled and took down the "service" in 2009.

Facebook has a history of screwing with the privacy of its users. Beacon was a prime example. The main problem here is the lack of permission. And that's the case for Etsy's new People Search, too.

The designers of Etsy decided it was a good idea to make everyone on Etsy searchable by name, including buyers. So, if you have ever bought anything on Etsy, you can now be found there by anyone else either by your real name or your username. Your whole profile is viewable, including your purchase history. Not only that, it'll all show up in Google search results.

The idea is that buyers would form social "circles" on the site to share information about their purchases.

Uninformed by research, guided by gut

These are the kinds of things that happen when an organization puts business goals before customer goals. It's also the kind of thing that can happen when an executive wakes up one day and says, We want to be one of the cool kids. And right now, to be one of the cool kids, you have to have social media. How do we do that?

What made Etsy think it needed a social layer on its beautiful, engaging site? It's the kind of thing that happens when teams decide to strap social on rather than looking at the conversation they're already having with customers and that customers are already having with one another.

I'm sure a lot of thought went into this decision of Etsy's. I fear this is a vacuum-sealed decision. Here's my imagined scenario, a scenario I've seen played out in other, similar decisions at other, similar organizations: Management, who forgets that their site is not the center of the universe for anyone outside that room, went to the product manager and asked for some of the social awesomesauce that is out there to turn up the buzz a notch. The product manager brainstormed with the team. The best idea they could come up with is to get customers to talk about the fun, beautiful, interesting stuff they'd bought on Etsy online with one another. (Never mind that we already have Twitter for this.)

Where is making use of the conversation that Etsy is already having with its customers or that buyers and sellers are already having together? They probably can't make use of these conversations because they haven't observed them. Where's the research to support this design decision?

It's hard for me to believe that if Etsy had conducted user research and even informal but realistic usability testing on the idea that they would not have quickly seen the privacy violation. They could have avoided the damage control they now have to deal with because of the breach of trust they've had with buyers who already love the experience of shopping there.

How Etsy could have avoided the problem and discovered a possibly great idea for engaging buyers even more

1. Analyze the risks of a social media strategy to users' privacy, security, and trust. Where was the business plan for allowing search of users? How does having social "circles" support the business model, exactly? How would the social media strategy be supported on the back end? More than all that, let's look at others who have gone before us: Beaon on Facebook and Boden USA come to mind. What happened there? What could the Etsy team learn from those mistakes? Oh, and, why duplicate Facebook in any way?

2. Proof the concept with real people who shop on Etsy. This is pure conjecture based on my experiences with other organizations: Etsy may have thought that to up their game and get people more engaged in the site, they needed to get buyers talking with one another and not just to sellers. Charming idea. But how do you find out if people find that useful?

Focus groups? If there were focus groups, I'm just going to guess here that participants liked the idea, but there was no exploration of the implications of this profile information being public rather than private. Not ideal.

What else could they have done? Invited friends and family. This approach still perhaps is not optimum, because friendly participants might not have exposed the privacy problems. They are, after all, friends and family, so there's automatic trust and wanted connections there already. How about rolling it out to a very small number of key buyers -- 3 or 5 -- and watch what happens for a week or a month as they connect to their people, or until something bad and unintended happens?

3. Conduct usability testing with real people in real contexts to learn the ripples to real relationships. Let's say they did usability testing. Did they bring in real buyers to use a working prototype with their own data? Did it occur to anyone that now my ex can Google me (like he does) and find out that I bought my sister a Star Wars crochet pattern, or my current paramour a hand made can coozie? Or what about the fact that my clients could see all the personal things on my Etsy wish list?

A usability test with a limited "circle" on a closed sandbox (like a walled-off development or testing server) for a couple of weeks might have given them some clues about what might work and what might not.

Etsy, I love you, but I have to go now

Not only will Etsy have to clean up its own site by making the social opt-in, but they'll also have to figure out a way to recover buyers' privacy. How does a web organization reclaim data that is now not in its control? If they could invent a big Web eraser to drag behind them as they invite buyers back to the site, they might have a chance.

Sources and resources:

http://arstechnica.com/web/news/2011/03/etsy-users-irked-after-buyers-purchases-exposed-to-the-world.ars

http://forums.penny-arcade.com/showthread.php?t=138661

Against the braindeadness of password policies: Andrew A. Gill's "Password Manifesto"

2011-01-17T11:36:00.001-05:00

I was struck by the rational thoughtfulness of Andrew A. Gill's write up about password rules. Read the original post. I learned about it through a Twitter post from @mediajunkie.

With Andrew's permission, I'm excerpting here.

The Password Manifesto

by Andrew A. Gill

...
For both of the people on the internet who do not know, Gawker's user databases have been compromised and the passwords stolen. I tried to log in to my account over there with any of the throwaway passwords I use when I don't care if I get compromised, and that did not succeed, so I'm pretty sure that I never changed it in the first place.

All of this makes me (much like this guy) wonder why I needed a password for that in the first place. I'm not interested in the Gawker community; I just wanted to let someone know that the Flight of the Bumblebee is not Fantasie Impromptu. Ideally, I should be able to sign up for an account, comment, and then disable the account, unregistering any password for it, requiring e-mail authentication if I ever want to comment again.

... The process of password generation for multiple accounts doesn't need to be a difficult process, but it invariably is because of the brain dead password limitations that the web sites give you.

Or, more often, don't give you. I have several passwords that are less secure than they could be because I'm not sure how long they can be, or in some circumstances because they have to be kept in sync with passwords that have to be shorter or can't use anything other than all caps or other idiocy.

And then these have to be kept alongside passwords that have to have letters and numbers and specials and have to have a number in the second position and can't have a capital on the last letter.

There is no reason why any password cannot have the 62 characters of [:alnum:], and you'll even have the rest of the printable ASCII characters left over to escape anything that Bobby Tables might throw at you. I should demand that all websites use Unicode for passwords. There are many different open source solutions to handle form input (with or without i18n) out there without counting the proprietary ones. But let's settle for the `normal' characters just to get to some sort of common ground now.

But it's time to get to the manifesto. Yes, I know that most of you reading this already know what I'm going to say. Still, we need to make sure that this information is clear and easily understood by everyone so that we can come up with a standard set of procedures to implement.

(1) If nothing else, show the users what options they have for selecting passwords. What is the minimum? What is the maximum? Which characters are allowed and which are disallowed? Are there going to be password hints? Is the password stored on the remote system or the local system, both, or neither (with a system like shadow passwords)? If the remote system is keeping a copy of the password, will that password ever be sent to me in plaintext? Is that code going to be used as a password hint to be given by the local system or as a token given by the remote system to prevent phishing?

Without this information, users will default to using worse passwords than they can. If one password is compromised on your system, it might allow an attacker access to another part of the system where another flaw would leave your entire system compromised. It's bad enough that many systems don't allow good passwords, but we don't need to encourage people to use less secure passwords than they want to.

(2) Allow good passwords. The only excuse for disallowing any Unicode character in a password is that you're running a legacy system that disallows it and you cannot upgrade the system. There is no excuse for disallowing any of the 95 ASCII printable characters (32-126), and if your system disallows some of the 62 characters of [A-Za-z0-9], there's something seriously wrong with your input handling, which wouldn't even be able to handle LadiesMan217. And if you allow those for your usernames but not for the passwords, you've got your priorities backwards.

I suppose I shouldn't have to say this, but I have more than one password or PIN number that is less than ten digits long, and must be numbers. It may sound like I'm being sarcastic when I talk about Unicode on legacy equipment, but I get it. Many people still have legacy equipment and can't change for whatever reason, but unless you're transmitting passwords via Teletype, your system can handle it.

(2a) Allow long passwords. My WPA wireless password can be up to 63 characters long, and that's not the most sophisticated security out there. If every wireless hardware manufacturer has figured out how to implement that length, there is no reason why every software password system can't allow one that long. If the passwords are stored as hashes, increasing the size of the password will not increase any storage requirements on the remote system, since verification is done by checking the result of an cryptographic transformation on the password, and the results are a set length.

This naturally will get into a discussion of passphrases later. Be aware that simply using passphrases doesn't make you more secure--we tend to use a few common words for passphrases, with the result that one word in a passphrase may be worth only two or three printable characters in a password.

(3) Allow bad passwords. Good passwords are a good idea, but so are bad passwords. That doesn't mean allow four number passwords, but it does mean getting rid of the smarmy messages about how ihatethisstupidpasswordchecker is not a strong password since it is composed of words found in a dictionary.

People use passwords for different things, and sometimes they might want to use a bad password for one of a few reasons. I understand that you are concerned that your whole database of which username wants to marry which character from Naruto. This is obviously vitally important to keep secure and thus justifies the randomly generated FIPS-181 password that changes once every two weeks and cannot be set by the user—in case they have some burning desire to add another spouse to their fictional online polyamorous relationship. But it it at least conceivable that lebowskifan87 might not be too concerned that someone finds out that she likes Coen Brothers movies.

(4) Use some real thinking to determine when require good or bad passwords. Does this password give you access to your money? Or other people's money? Perhaps confidential client information. You'll probably want to use a good password for that. But you won't force users to use good passwords if they don't care about your security. They'll use technically good passwords like Ab(d3 or write them down in an unsecured location. How often do you need to enter a particular password? If you have to enter it every time you come back to your PC or send a message, you'll probably want a short password, while a longer password may be useful for things that you have to do once a day or so.

I have several passwords that I either no longer remember or had to write down in an unencrypted file because the ones I wanted to use were too insecure for the webmasters at some blog that forces people to register in a lame attempt to convince its readers that they're part of a `community.' I also have several passwords that I have to use for work to handle client data, and do things like log onto my work PC, which I lock every time I get up from it. I choose high-entropy, difficult to remember passwords, and let muscle memory take me the rest of the way. A couple days after changing the password, and I have no trouble entering the whole thing, even with my typical fat-fingeredness. If I got locked out after a few bad passwords, I'd quickly find myself out of a job trying to enter a 63 character passphrase blind.

(5) Never default to send a user's password via plaintext e-mail without a prior request to do so. Plaintext e-mail, as has often been said, should be treated like a postcard. Expect that any plaintext message can be intercepted and read, because, well, it can be intercepted and read. For whatever reason, some users may want to use plaintext e-mail to have their passwords sent to them from time to time, either as a reminder or as part of a forgotten password recovery procedure. We aren't going to see that go away anytime soon, but many users are not going to want their passwords routinely transmitted insecurely, and we should honor their wishes. At the very least, the user should have to opt in to this type of behavior.

I have had to change passwords on multiple occasions when they were sent to my e-mail address in plaintext, usually as helpful weekly password reminders. This is just downright silly.

Well, that's pretty much it, but here are some advanced tips that I don't expect can be used in every case. I recommend using them in every case, even when there are legitimate objections to them because they are part of best practices, and I suspect that the objections will be overcome in a few years, at which point, these will be part of the standard operating procedure.

(A) All passwords should be transmitted through encrypted communications. This means using SSL for your servers. SSL and certificates aren't cheap, so I understand why you might not want to do this, but there are other ways to encrypt a password if this is not available to you. If you need to send a password to the user's e-mail, send it using the user's public key encryption, if available. If you can't afford to do any encryption at all, consider if you really need users to give you secure passwords if you're not going to keep them secure.

(B) Passwords should be stored as hashes of the password, not the password itself. By doing this, the password itself is not stored and if the password database is cracked, no data are compromised. The cracker would have to generate a hash collision to get a password. Doing this also means that you won't be able to alert the user that the third digit of her four digit PIN number is the same as the previous password she used for this account. Good riddance, in my opinion.

(C) Users should be able to temporarily or permanently disable accounts, removing all passwords from the remote server's database. Whether that's because the user rarely comments, or because the user is paranoid, or because the user gave up the internet for Lent or because the user has been convicted of wire fraud and can't use a computer for the duration of her sentence is irrelevant.

(D) A very long password, like a sentence or some other multi-word phrase may indeed be better than a shorter password, but it might make sense to include it as a sort of two-factor identification. Enter your passphrase at the start of a session, and that passphrase enables the operator to use the shorter password to authenticate when the program notices a five minute idle and logs you out. The password is useless to any attacker who is not physically at your computer while you are logged in with your passphrase.

There's the ripple: From Gawker comments to personally identifying information

2010-12-15T08:39:00.006-05:00

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:

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.

Truly secure security questions

2010-08-18T12:51:00.000-04:00

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?

RANT: What makes you think your content is this important?

2010-07-28T07:34:00.000-04:00

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

SOUPS: We're asking too much of users and not enough of researchers

2010-07-26T08:40:00.000-04:00

SOUPS was new for me. I have been working in usable security for only about a year, so I was hoping for flashes of inspiration, insights from the people who have spent their careers on the topic. I was not disappointed.

The Symposium On Usable Privacy and Security (SOUPS) is a little conference, this year there were about 200 attendees. Microsoft hosted the event in July. Many in attendance were academics, graduate students, or researchers who work in corporations. There's mostly an HCI - computer science bent, I felt. There were a few corporate practitioners of security and compliance sprinkled in the crowd, though.

Highlights: Beyond authentication
As you might expect, the presentations reflected the mix of attendees. For me, this wasn't ideal, as I'd just completed a lit review that demonstrated pretty clearly that most of the academic research about usable security out there was not applicable to real situations that normal people face every day. So I was delighted on the morning of the last day to hear reports from researchers who had gone out in the world to look at some interesting problems that real people actually face.

Dinei Florencio and Cormac Herley from Microsoft reviewed security policies from web sites and theorized about what motivated them. Rick Walsh, of Michigan State University, reported on a pet project to understand people's mental models of security in home use of technology. Khai Troung, reporting for his colleagues David Dearman (both of University of Toronto) and Justin Ho (of Google), showed us the ways people name and secure (or don't) home wireless networks and why there are risks. Matthew Kay presented work that he and his partner Michael Terry from University of Waterloo had done on information design of online license agreements.

All were good work: solid research, thoroughly done, (mostly) with people outside universities, looking at some question the answer to which could make things better for users.

Useful lessons from the talks
Password requirements are the opposite of what you'd expect.
Password policies for e-commerce seem to be about making access as easy as possible, whereas policies for university and government sites make security policies strong (and difficult) because they can. The least attacked sites have the most restrictive policies.

Home computer users defend against myths of threats out of ignorance. Botnets take advantage of these "folk models."
You can install all the firewalls and anti-virus software available and still not fight threats effectively. The software is difficult to use; keeping it up takes constant vigilance. Most people Rick talked to identified two threats: viruses and hackers. Though he neatly presents eight insightful folk models of threat scenarios, it comes down to these beliefs of users: viruses are more or less automatic, probably released by hackers; hackers are malicious people who are actively working to break in to computers.

People rely on the default settings, assuming that the way the manufacturer set them is good enough.
Anyone who has installed a home network on a Windows platform knows that setting up wireless access is frustrating and difficult. So, although strong security is built in to wireless routers, giving access control definitions and levels of encryption, people don't know what those are. The usability of the installation and configuration software strongly affects the strength of security applied. When the team tested a configuration wizard they'd designed that helped users know what to do, they found that people made better security choices.

Design of information helps people see how it is relevant to them.
When Matthew and Michael incorporated a distinct visual hierarchy along with relevant graphics and illustrations, people were much more likely to spend time reading and to remember later what the content said, than they were on text that did not incorporate these features. I have some issues with the way the experiment was conducted, and the lack of background in information design theory and practice, but the outcomes are promising and I hope this team will go deeper on this topic.

We're asking too much of users
Taken together, my conclusion is that people delegate security decisions - to ISPs, to user interfaces, to institutions - for two reasons: First, in some situations they have little choice. Password policies, for example, are forced on users by policy makers in the institutions. Second, users feel they have little choice because the choices are mysterious and difficult to understand. Although one of the tenets of good user interface design is to leave the user in control, it feels like we're surfacing too much to users, leaving them with decisions they can't make because they aren't knowledgeable, asking them questions they can't know the answers to. I hope that next year at SOUPS I'll see some work that integrates security more and burdens the user less.

Unfortunately, these excellent projects were more the exception than the rule at SOUPS. My major disappointment was how many of the projects used undergraduate students for their sole source of data. I get using students for pilot studies. Why not? They're practically free and willing (and in some schools and majors required to take part in research). But it takes only a bit more work and a tiny bit more expense to find people outside the undergraduate population. But then we'd have to be doing research on security problems and solutions that are practical in the real world.

Throw this phish back: Separating the userid and the password

2010-07-08T13:22:00.000-04:00

Many financial services are implementing stronger security measures these days, from chip-and-PIN to security questions. Any credit card that is underwritten by FIA Card Services, if it hasn't already, will be undergoing a new set of measures to prevent phishing attacks.

I encountered the first steps of this on my Schwab VISA the other day: splitting the password from the userid screen. As a security principle, meting out the authentication steps is a spectacular idea to prevent automated attacks. And, because the user is supposed to have personalized the information on the authentication page where she enters her password, eliminates phishing attacks. (Phishing, for those who have been living under a rock for the last 15 years, is the practice of sending emails to people that look real but are not, and which ask for personal information or passwords. When the diligent but unsuspecting user clicks the link in the email, it leads to a web site that also looks real but isn't. The user enters userid, password, and possibly other personal information, and now has surrendered it all to the phishing scammer.)

Because you don't pay attention to who you get email from, we're giving you more work

The ideal interaction works like this:

Authentication page: User sees an image and a pass phrase she has entered into a profile previously and then enters a strong password, clicks Submit, and goes to the site.

The added steps should help customers recognize that they're in the right place when they've clicked a link from an email, without taking more than a couple of seconds extra when compared with the userid/password combined page.

In reality, the interaction works like this:

One day, the user goes to her credit card's web site to schedule a payment for her bill. When she arrives, she finds that the site has changed from having the userid and password on the same page to separating them -- without notice.

On the login page, the user realizes that her personal single sign-on will now not work.

Now the strong password generated and stored by her password-managing software must be exposed, because she has not memorized it. She logs in to the password-managing software and opens the record for the web site, which unmasks the password. Then she can copy and paste the strong password into the new authentication page.

By the way, the answer to her security question is her mother's maiden name, which is easily findable by others. There were 5 images offered, one of which was a flower, which would be easily guessable by someone who knew that the user was a middle-aged American female.

As a security measure, this stinks. As a user experience, it is abysmal.

The credit card company (and other financial services companies that use this authentication schema) has traded off one set of security issues for another. That is, because the financial services company gets blamed when there's a phishing attack, they put more security steps on the user. It is unclear whether the credit card company has weighed the direct cost of the burden of their added steps. Most certainly they have not looked at the user's context to understand how their measures fit into users' goals.

Why the security is still lacking

Splitting the userid and password onto different pages makes using a strong password more difficult. In the case of using personal single sign-on, we now have an opportunity for shoulder surfing, when we didn't before.

The images available as site keys are very easy to guess if you know anything else about the user.

Answers to security questions are easily findable if you know anything else about the user.

A user experience of -3

Imagine that this user has something like 15 to 25 userids and passwords that she uses as frequently as daily or weekly. For today's scenario, the user's goal is to check a balance, pay a bill, or maintain the account in some other way. Authentication enables the task. It is not a task in itself. No one goes to a web site with the goal of logging in.

This so-called enabling task is a burden. And the very things that make it a burden allegedly make each site more secure. The added steps took much more time to implement and then use than the promise suggested. The added steps also had (we assume) the unintended consequence of causing the user to expose her strong password.

Include in the scenario that the change in security measures was a surprise. It's a question of degree: A userid/password combination on the same page is something many people are used to; it was a small bump on the way to accomplishing a task. Splitting the userid from the password was disturbing, distressing, and disruptive. Adding other measures to the authentication page was burdensome, annoying, and failed to demonstrate how implementing them helps the customer.

Making security decisions is complex. Making them in the context of users' work is nearly unheard of. These authentication measures are clunky and burdensome because they've been bolted on to the site rather than built in to the experience. There must be a better way – a more effective, less burdensome way -- to prevent phishing and secure users' data.

Don't make me stop this, rdio.

2010-07-03T21:25:00.000-04:00

What is going on when a company asks you to surrender your credit card information to verify an account but says they're not going to charge the card?

It was a trial. It was the extension of a 3-day trial to a 10-day trial. A *trial.* There was nothing said about We need your credit card to set up an account when you register. (Though I wouldn't have done that, either.)

Are they asking for credit card information to ensure that the account registrant is real rather than a bot? What in credit card information ensures that? Nothing.

What is going on when a company asks a new user to surrender credit card information but says they're not going to charge the card is this: A blatant attempt to secure you as a paying customer, not secure your account or personal information. It's overkill, it's rude, and it is very uncool.

They're trying to manipulate the relationship so you'll automatically become a paying customer when you've exhausted your trial.
They're treating you like you're a customer already, and just giving you 10 free days. So, even if you click the button for a free trial, both of the buttons on the page mean the same thing:

That's not "verifying" the account. That's establishing an account against the will of the customer. That's sleazy.

Don't worry, we won't charge your card? Then why do you want it? There must be some other way to accomplish your goals, rdio, without asking me for payment information you don't need yet.

A better user experience would be to

Not ask for credit card as a verification for the trial, but instead to do something fun, authentic, and clever, like check in with me each day of the trial to see how much I love the service.
Help me tell other people how much I love the service.
Ask me questions about my usage so far

Because I never used my 3-day trial, I don't know how the service is. They could have learned a lot by asking me about why that was and why I wanted to extend the trial when I did.

When I said I wanted to extend my trial, they assumed that I liked the service and wanted to keep going -- and that they could capture me as a customer at the first opportunity. But the opportunity for them was not the seducible moment or method for me. I'm going back to Pandora.

Authentication stinks.

2010-06-28T19:08:00.000-04:00

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.