KeepItLocked.net

Software needs to do more than just work; it needs to work well under load, with changing requirements, and with sub-optimal users. There are entire subfields of software engineering that aren’t directly about coding – quality assurance, performance engineering, business analysis, etc. I’m particularly interested in two of these computer science sideshows – security and usability. As a recent user experience intern, and a former security consultant, I’ve had the chance to look at how these two software factors get applied in the real world, and I’ve found several common threads.

1. Resistant to "peanut butter"

In 1993, two University of Colorado professors wrote “Task-Centered User Interface Design”, a book discussing the need to consider usability through the development process. They advised against building software and “in the final stages of development, spread the interface over it like peanut butter.” Keeping users in mind early and often in the development process is an oft-repeated principle of usable software design.

In software security, the same theory holds – consider Microsoft, DHS, and OWASP, all of which advocate building security into the software development process.

Addressing security and usability throughout the development process makes sense. They are both inherent properties of software, not just coding techniques, and issues can stem back to requirements. Unfortunately, for several reasons, including those outlined below, people still treat security and usability as an afterthought.

2. Hard to quantify

Security and usability defects, unlike performance and functional defects, can be difficult to measure. One of the most obvious explanations is that they aren’t easy to test directly – penetration tests and usability tests are small-scale and contrived exercises compared to the armies of attackers and users who will eventually attack and use the software.

Another cause is the subjectivity of severity of usability and security issues. Usability metrics like GOMS and security metrics like CVSS aren’t widely used and don’t seem to be very practical. I think one intractable piece of quantifying these practices is the huge dependence on context. Most usability and security assessments rely on understanding people, in addition to understanding technology. People are hard to predict, and their opinions are subjective, which makes definite statements about their behavior difficult to make.

3. Goldilocks dilemma, AKA not too much, not too little

One of the things I learned early on in security is that there is no such thing as 100% security – and even if there were, it wouldn’t be desirable. There are diminishing returns, and security involves tradeoffs, usually including at least time and money. Unless you have an infinite budget, and it’s your job to make the most secure system in the world (e.g. the military), then you have to settle for some amount of risk. At Foundstone we used to call this “secure enough to do business”.

Usability follows the same principle – you don’t want to under- or over-do it. For example, IDEO had a television showcase where three highly talented cross-functional teams designed a shopping cart. It seems unlikely that most shopping cart buyers would see a return on investment from this kind of design process. 100% usability seems absurd by definition – there will always be compromises in user interface designs. I’m not going to say people should only make software usable enough to do business, but anything extra may not be obviously worthwhile.

4. Tradeoffs

A classic tradeoff is security versus usability. If you make systems harder for attackers to exploit, you make them harder for users to use. Strict password policies, short session expirations, and CAPTCHAs are examples of how security impacts usability. But security can have other tradeoffs, like performance, privacy, or even functionality.

Similarly, usable software may need to sacrifice features that confuse users. It may limit users choices around privacy and security, and it could even impact performance if certain tweaks and configurations are hidden from users.

As mentioned earlier, both security and usability cost money and time. That’s why cost-efficient techniques like discount usability engineering and threat modeling are so effective – full-scale reviews that address every corner of the practice are simply out of reach for most organizations.

5. No checklist

Because software security and usability are subjective, contextual, and dependent on human factors, there is no comprehensive one-size-fits-all checklist for security or usability reviews. The appeal of a silver bullet is clear, and while heuristic guidelines in security and in usability are popular and useful, each software system is different enough to require more than rote checklist-level analysis.

6. Who's in charge?

Another challenge to building secure and usable software is determining responsibility, especially in large teams. Until about a decade ago, IT security teams were focused on securing networks and third-party software packages against well-known attacks rather than building secure software. Even now, software security-specific personnel in organizations are fairly rare. When these resources exist, deadlines in development can take precedence over security concerns.

Usability departments face a similar challenge – they have a large amount of work to do, limited resources, and need to win political battles when engineers have to meet deadlines. The way both of these organizations tie in to a large software development or IT department and the power they have seems to vary from company to company. The difficulty getting corporate buy-in may stem from multiple causes including difficulty proving cost-effectiveness and distance from the revenue stream.

7. Everyone's got an opinion

You rarely hear about people getting into debates about performance or quality issues. The subjectivity of security and usability means that two rational people can disagree about a fundamental issue. Some security people are incredibly paranoid, while others may not worry enough. Usability professionals may prefer simple interfaces, or believe simplicity is overrated. There are shades of wrong and right, but precious little that is indisputable (except for anything from Steve or Bruce, obviously).

8. Hard to see value

The results of security engineering often go unnoticed. Good security controls, like good interfaces, are effectively invisible. Unfortunately, bad security and usability may go unnoticed as well. A site that spews out spam or gets targeted by phishers may never realize its problems. Clear text passwords or credit cards may be compromised without raising an eyebrow. Similarly, software that has serious usability problems may slowly lose users to competition without the creators ever realizing why.

This lack of insight has led to a tendency of some to assume that security and usability don’t matter. It’s clear when a customer doesn’t buy software because it lacks a feature. But the risks and rewards of insecure or unusable software can be more difficult to see. When push comes to shove, security and usability can end up on the losing side.

9. Need {social, operational, financial} context

As I mentioned earlier, security and usability depend on context. As we used to say in our security courses, the security requirements of your kid sister’s diary are different from the security requirements for a nuclear bomb silo. Similarly, the required usability for a shell script is different than a search engine. There are no hard and fast rules, only principles, because each system operates in such different contexts.

10. Require "expert" evaluation

Finally, usability and security both require expertise in order to get right. While people have some gut feelings about the subjects, the best security and design minds have a huge amount of experience behind their insight. I think this is why there is such strong design and security communities – people learn from each other, and bring that knowledge to those outside the communities as “specialists”.

As with any top X list, this is just one of many perspectives and there are undoubtedly counter-examples. I’ve also thought of some things that are very different between usability and security. One gives joy, the other confidence. The risks associated with bad usability are usually long term; security risks can be short term. Certainly, the two communities have different cultures and values. But there are also undoubtedly numerous techniques that can be shared between the two fields, and they deserve exploration since security and usability are both so critical to modern software.

Passwords are a tricky business. In real life, we don't need to whisper secrets to prove who we are. Our faces (or identification cards, which are basically certified pictures of our faces) are instinctively easy to recognize. Online, we need to resort to more arcane measures, hence the proliferation of password-based authentication systems.

Unfortunately, people forget their passwords. Once that happens, the one and only thing that stands between a user's account and the horde of vicious Internet attackers is gone. The user still wants to access their Fantasy Foosball account page, but how do we know it's really them?

Forgotten password mechanisms deal with this use case. It would be difficult to operate a web site without one - you'd have to ask people to go to a physical location and show ID. A brief examination of these mechanisms shows how sites employ a variety of approaches and controls. Some are incredibly simple, such as emailing you a new password at a pre-defined email address, while others have multiple steps and safeguards to stop attackers.

Bad password reset mechanisms have led to several noteworthy compromises. Password reset is a classic security-usability tradeoff - the more you lock down the reset process, the harder you make it for the legitimate user to access their account. I wanted to see how major sites deal with the password reset use case, to try to figure out what are the accepted practices.

Additionally, I wanted to point out how the "weakest link" theory applies to password reset and authentication systems in general. You can have an incredibly strong password policy, authentication mechanism, etc., but if all an attacker has to do is guess your pet's name, or brute force a four digit code, it's all for naught.

I was partially (and retroactively) inspired by two papers from the WEIS 2010 conference recently mentioned by Bruce Schneier on his blog. In "Where Do Security Policies Come From?", two researchers from Microsoft discover that the strength of password policies don't correlate with site size, asset value, or number of users, but with competitive ecosystems and advertisement revenue. The more rigorously a site has to satisfy usability needs, the weaker the password policy. Another paper titled "The password thicket: technical and market failures in human authentication on the web" describes an empirical study of password systems at 150 popular web sites, including an examination of password reset protocols. The second paper actually has a great analysis of password reset that expands upon what the brief survey I did for this blog post, so if the subject interests you, I'd recommend following up with it.

There are a few basic security controls employed during password reset processes - secret Q&A, CAPTCHAs, and side-channels.

1) Secret Questions and Answers

When the user registers they provide some information, which may explicitly be for the purpose of resetting their password, which is considered secret enough to prove their identity. This may be accompanied by brute force countermeasures, like CAPTCHAs or request throttling.

2) CAPTCHAs

CAPTCHAs are used to prevent a robot from filling out the password-reset form and performing a brute force attack.

3) Side Channels

When the user registers they provide a side channel address, such as an email address or a phone number, which can be used to verify their identity. The secret communicated through this side channel may be a temporary token or a new permanent password.

One other security mechanism I don't mention here is the possibility of rate throttling password reset attempts, which would, like a CAPTCHA prevent brute force. Because detecting rate-throttling controls requires a much more active form of testing, I didn't include it in my survey.

The following list of 14 popular sites password reset mechanisms shows that there are a variety of practices in place.

Google

Secret Q&A

Only if the account has been idle for 24 hours. Hard to know what's the reasoning behind this, although I'm guessing there's a good one.

CAPTCHA

Email code

27 characters, mixed-case alphanumeric

Other

In addition to sending an email, they also use SMS with a six or seven-digit activation code. This seems like the easiest route for an attacker because it's certainly brute-forcible over the web without any additional protection (which I'm guessing they have, but still)

Yahoo!

Secret Q&A

You can answer two secret questions and answers if your email and phone are not accessible.

CAPTCHA

Email code

160 characters, mixed-case alphanumeric

Other

Yahoo! also uses an SMS code with 8 hex characters.

Microsoft (aka Bing, Live.com)

Secret Q&A

In addition to answering secret question, you need to provide location information (e.g. Country, State, Zip Code).

CATPCHA

Email code

72 characters, mixed-case alpha-numeric.

Apple

Secret Q&A

You can answer a single secret question if you don't have access to your email address on file. In addition to answering the question, you need to provide your email address and birthday.

CAPTCHA

None

Email code

192 characters, hex.

Facebook

Secret Q&A

None

CAPTCHA

Email code

7 or 8 characters, hex. This seems pretty easily brute forcible if there are no other protections in place.

Twitter

Secret Q&A

None

CAPTCHA

None

Email code

32 characters, hex

MySpace

Secret Q&A

None

CAPTCHA

Myspace uses two CAPTCHAs in the reset password process, interestingly enough - one before entering your email address, and one after. They both look like this:

Email code

150 characters, mixed-case alpha-numeric.

LinkedIn

Secret Q&A

None

CAPTCHA

None

Email code

Eight characters, numeric and eight characters, mixed-case alphanumeric.

Amazon

Secret Q&A

None

CAPTCHA

Email code

120 characters, mixed-case alpha-numeric.

Ebay

Secret Q&A

You need to answer a secret question, as well as provide your zip code, phone number, and birth date. This is necessary to get the email code, unlike other sites which only require one mechanism.

CAPTCHA

None

Email code

31 characters, mixed-case alphanumeric and symbols.

Other

If you don't know all of the information required in the secret Q&A section, you can simply answer your secret question and provide a phone number. You will then receive a four-digit (!) code to reset your password.

Craigslist

Secret Q&A

None
CAPTCHA

None

Email code

Seven digits.

Paypal

Secret Q&A

2 questions and answers

CAPTCHA

Email code

60 characters mixed-case alphanumeric

Wikipedia

Secret Q&A

None

CAPTCHA

None

Email code

Wikipedia creates and emails a new password that is 6 character mixed-case alphanumeric

There isn't a clear conclusion to draw here - sites do things differently, and in some cases have what seem to be pretty easily breakable password reset mechanisms. I'd imagine that all of these mechanisms work well enough - the cost of breakins is less than the cost of making things more secure and difficult for users. But I'd encourage people to think of ways that the password reset process could be made more secure and usable so that sites could rally around a better mechanism.

For my User Interface Design class last semester, my team created a CAPTCHA mechanism with an interface suited to mobile devices. I recently made a Mobile CAPTCHA project page describing the project. There's also an interactive prototype at bit.ly/mobilecaptcha and a Video Prototype on YouTube.

Recently, UC Berkeley has announced that they will offer complimentary DNA testing to incoming Letters and Science freshman. The testing will be optional, confidential, and look at three genetic markers related to alcohol, lactose, and folate tolerance. While the project intends to provide a unifying educational experience and help students prevent health issues, it has become the subject of criticism because of the ethical and privacy concerns associated with genetic information.

One dimension of the system that should not be ignored is the threat model. According to the FAQ on privacy for the program, the confidentiality of the system relies on two bar codes sent to each student. The student sends one back and keeps the other to view the results. This description is too simplistic to give me any confidence in the system. In order to provide confidentiality, these barcodes would need to be randomly generated. There would never be a time when the bar codes associated with student names were viewable by another person (who is stuffing the envelopes?). And, the web site that provides the information would have to be free of security vulnerabilities. Given that the only time I'm ever received an SB1386 "sorry, we've been hacked" letter was from UC Berkeley and involved a website compromise, I think that this is a big assumption.

Like other dilemmas involving ethics and privacy, the people responsible for the decision should deeply consider the security risks. Ensuring privacy often means ensuring the confidentiality of information, which is tremendously difficult to guarantee. I'd like to see more organizations analyze and present the security concerns and how they impact privacy before making unfounded guarantees and rushing towards their desired conclusion.

I recently attended the Internet Identity Workshop 10 (IIWX) at the Computer History Museum in Mountain View to learn about the direction of OpenID. I spent many hours this semester researching and writing a paper for school about social factors limiting the diffusion of OpenID. Between the time that I came up with the idea for the paper and I turned it in, the OpenID and surrounding community has become involved a series of fascinating conversations that seem, to me, to be the future of the Internet playing out in a day-to-day drama.

OpenID has had only limited success. There are many reasons - security, usability, trust issues, and legal issues are some of the obvious ones. There are also competitive standards. Sites like Twitter and LinkedIn allow you to authenticate via OAuth. But wait, I though OAuth was for authorization, not authentication? OpenID and OAuth both support authentication and authorization in some form. And the two standards seemed to be in a steel cage match. Enter Facebook.

Facebook had a platform for single-sign on and sharing across the web called Facebook Connect. It was, for the most part, a closed and proprietary standard that didn't acknowledge the existence of OpenID and OAuth and the other elements of the OpenStack. In 2009, Facebook joined the OpenID Foundation and became an OpenID Relying Party (RP) by accepting OpenID accounts. This was in contrast to other large companies like Microsoft, Google, and Yahoo, who are only OpenID Providers (OP) and don't allow you to log in to their services with another identity. Essentially, Facebook said, "fine, you can log in to Facebook with your OpenID. But we want to make sure you log in to other sites with Facebook Connect, not OpenID." Facebook has taken a lot of flak for privacy debacles - from Beacon to their dynamic privacy policies. Some suggested that Facebook Connect was an attempt to make Facebook the identity layer for the web. Since you are always logged into Facebook (right?), sites could access your social graph (not to mention verify your geographic location and age) through the information shared from your profile via Facebook Connect.

Facebook recently revealed that they were killing the proprietary Facebook Connect stack and replacing it with OAuth 2.0. OAuth 2.0 is a re-imagining of the OAuth protocol that promises to make life simple by eliminating the need to perform cryptography on the client with Bearer Tokens and requiring SSL to improve security.

So now, if you want to allow users to log in to your site with their Facebook or Twitter accounts, you had to support OAuth, not OpenID. And guess what, site owners? There's good news. The OAuth protocol gives you a token that lets you get all sorts of fun data about users. So why would you even need OpenID?

At the recent Facebook f8 conference, several influential members of the Identity community hosted a panel discussing the OAuth 2.0 changes. When asked about OpenID, a Facebook engineer replied: "Developers aren't asking for OpenID. OpenID [is] a layer of complexity nobody is asking for." This was followed by an informal poll showing an overall lack of enthusiasm for the OpenID technology.

So wait, OpenID is done for? That's what I wanted to figure out at this conference. A few days earlier, David Recordon dropped the Open ID Connect strawman proposal, which was discussed further at several IIW sessions. Generally, OpenID Connect builds on top of OAuth 2.0 and includes plenty of inspiration from earlier OpenID/OAuth hybrids. The idea is to move the OpenID itself to a single "scope" of an OAuth flow. The move to OAuth 2.0 forces everyone to use SSL, which happens to break OpenID 2.0.

Even if it breaks backwards compatibility, I think OpenID Connect would encourage OpenID adoption. It simplifies OpenID, which is a critical hurdle, and provides default security in the form of SSL. It also gives sites the carrot of an OAuth token and potentially rich social information about its users. This is what concerns me about tightly integrating OpenID and OAuth. I think it will encourage services to only accept third-party logins from sites that have lots of social information about users, as opposed to allowing arbitrary OpenID URLs.

If Facebook, Google, and Twitter are on board, full steam ahead, right? But OpenID Connect is just a strawman proposal. There's an entirely different OpenID charter called v.Next. The two proposals share a lot of the same goals, and seem to involve a lot of the same people. But, in the meetings at IIW, you could sense a tension between the two sides. OpenID Connect is about, at its core, simplicity. The decision to build OpenID Connect on top of OAuth 2.0 is a fait accompli. v.Next wants to support Public Key Infrastructure, it wants to provide NIST Levels of Assurance, it wants to support existing OpenID infrastructure like Attribute Exchange. OAuth 2.0 compatibility is a nice to have. The two sides seem to have fundamentally different visions for the technology. From the OpenID Connect proposal:

Q: Haven't there been OpenID Foundation Working Group proposals for OpenID v.Next?

A: Yes, there have been proposals for working groups on discovery and attributes over the past month (and talk about doing so for almost a year). Combined they have over a dozen new features and there hasn't even been a proposal for the core OpenID Authentication spec yet. OpenID needs to be driven by simplicity and elegance, not by support for over a dozen new features.

So who will win out? My hope is that the next OpenID standard will be a compromise between the two parties. There are several tradeoffs here: simplicity versus extensibility, privacy versus usability, security versus complexity, and so on. I'm worried that the v.Next vision to support everyone doing everything sounds a lot like the WS-* debacle, where there seem to be more specs than there are implementations. On the other hand social behemoths Google, Twtter, and Facebook are prominently involved in the OpenID Connect specification that encourages social sharing and may (just may) disempower users who find themselves forced to share potentially embarrassing information in order to register for sites. Hopefully a fine line can be drawn to protect users interest and support a wide set of use cases, while keeping OpenID simple enough to encourage people to use it.

Irony footnote: Yes, I don't have OpenID enabled for comments on the blog. Yet.