How to make security usable in a web application?

Question

I'm in the planning stages of developing a web application that I want to make as secure as possible. I'm pretty clear about how to do that from a technical point of view, but there is one massive potential security hole: I want the site to have users.

As anyone who has ever been a user knows, users forget usernames, forget passwords, sometimes forget that they even had an account with your site. Users respond to phishing emails and give away their credentials. If you do anything that they find too complicated they won't use your site, it has to be simple and all happen in as few clicks as possible, but we have to balance that out by making it as hard as possible for users to accidentally give away their credentials and to keep access to the service as secure as possible.

What I'm particularly interested in are strategies that go beyond the standard username and password combination and ways of recovering or resetting passwords that make things easy for users but hard for anyone trying to steal their account. I know a lot of sites provide an extra user-set security question, but because I don't trust users not to create a stupid question like "what is 1+1" I don't see how this can guarantee security.

Are there strategies that could be useable to the most clueless user but challenging to a determined and targetted attack aiming to break into their account? If not what are the closest things we could get? As a user what are the best/worst sites for this you have encountered and why?

Answer 1

The only way I know of to build a truly secure web site is to require a password and have a challenge/response device.

For example, TreasuryDirect.gov sends you a card with a grid of random characters. As part of the logon process, you are asked to provide the characters that are contained in specific cells of the grid. But this is expensive and time-consuming; it requires to get the cards, to track them and to send them out. Plus, if a person loses the card, they can't log in until you get them a new card. In the case of TreasuryDirect, where you could be managing millions of dollars, this hassle is worth it. Only you can determine if it will be worth it for your site.

Another option is to add a validation picture, like a lot of banks do. I believe this option only helps thwart some phishing attacks so if you think phishing will be a problem, this might be an option.

I believe the other alternatives, including what most banks use, seem to be secure but aren't really. Security questions, for example, I believe compromise sites more than they help. Others think this too.

One other thing will be to encourage users to use a "Passphrase" instead of a password as Jeff Atwood recommends. Amazon has taken this approach as well with their newish PayPhrase.

Answer 2

I think you shouldn't reinvent the wheel. Most websites have a solution that works for forgotten passwords, and that's sending a link to the user's e-mail account. The only way that plan goes haywire is if the e-mail account has been compromised.

It's obvious that the more important the user data on your website is, the more security measures you should have, but these extra security measures have an impact on your site's usability. How critical is the data on your site? Should you have 2 or 3 authentication systems like sometimes e-banks do?

The most important aspect is "don't trust user input". If you do this, most security problems won't exist and there won't be an impact on the usability. If you want to be paranoid, go ahead and build a fancy security system, but don't forget that it might impact the way users use your site (for the worst). You have to find a balance between these 2 things.

Answer 3

To the OP: Use standard approaches to security on web sites. There will inevitably be moron users that will drown and walk away from your secure site, but that's the nature of the beast. You want security, you'll have to sacrifice some flexibility (and again, there are known practices on security that have worked well from a user-friendly point of view.)

Besides, when a user walks away, it is usually for things other than security (shitty web design, confusing navigation, poor performance, unreliability, etc.) Obtrusive security is usually the result of a poor architecture, and not of security itself. Keep that in mind.

Answer 4

My only suggestion on the "usable but secure" front would be to have set questions, but user-entered answers (e.g. notable place, first pet's name, notable date). Although these aren't watertight individually, making them answer a combination of two or three person-specfic questions should be good enough.

And don't forget Captcha words or similar to slow down or identify brute-forcing.

Answer 5

You can also use OpenID and OAuth rather than having user create new account

Answer 6

Unless you understand all the edge cases in securely dealing with authentication and sessions, don't implement this yourself.

Broken authentication and session management is one of the top 10 OWASP security issues, and there is a reason for that. "Getting it right" is so complex you have to be a web security expert.

If possible, use a third party auth system. For example, use google accounts. Let them worry about all this stuff.

Answer 7

As per your comment

I don't trust users not to create a stupid question like "what is 1+1" I don't see how this can guarantee security.

You don't need to guarantee security - in fact having a question like that shouldn't be a problem. Let users set the hints they need.

Now for ebanking, there is a juicy enough target that phishers do make good money, so if you are in the same space you could look at what some of the banks do very successfully in the anti-phishing space - antiphishing.org has some useful info, then applications like Trusteer's Rapport provide further security around the connection, and for the higher value areas they use 2 factor auth, often in the form of smart cards.

The solutions for various different risk and usability levels are pretty well understood, so you might find it is simpler to reuse an existing concept than redevelop - the cost of usability testing could be high!