I'm looking at putting together a website aimed at ordinary users that will handle personal data which I don't want to be compromised. How can I make the site secure but also usable?

It seems most sites use a user identifier ( email address seems best ) and password, which is fairly well understood.

Some banking sites go beyond this by having a PIN or security questions following on from the standard identifiers or replacing the password. I'd be interested to hear about any alternatives that have proved successful in this respect.

I've also heard of allowing users to choose their own colourscheme or look and feel for a site once they are identified to make it harder to phish account details. Does anyone know of sites using this and how well it works?

The real weakness in most systems seems to me to be the password reset facility. Because users forget their passwords the whole time, we need to have something to help them out here, but it seems really hard to strike a balance between helpful and horribly insecure. Again the user security questions approach seems to be widely used here, but the two sides of this I have encountered have either been having a question that the user sets and provides an answer to or having some immutable questions about the user.

With a user provided question I don't trust them not to make the question "what is 1+1" no matter how hard you try to tell them that this is very important.

With immutable questions - and if you're asking a user's opinions on things rather than simple facts they are more likely to change - they tend to turn into the kind of thing ( parents first name, first pet ) that is actually quite easy to find out if you are targetting a user for attack.

I realise there will always be a compromise here between what is secure and what is easy to use, but it must be possible to do better than most sites do now. Can you suggest any less conventional but reliable approaches to user account security? I've heard talk of image grids, custom captchas and so on - any experience of these in practice? Are there any sites that manage this particularly well and if show how/why do they work?

3 Answers 3


Good question.

Short version

There are several options going beyond username/email/password as most sites do. You can't solve the ultimate security issue, but you can educate. There are alternatives to captchas. Security vs ease of use is a never-ending, healthy debate.

Extra security options during login

  • Yahoo! uses the "sign in seal" concept, where you can choose either some text or an image, and that customisation will be stored in a cookie and displayed on the sign in page when you return. The idea here is that it helps prevent phishing attacks: instead of explaining the technical details of phishing to users, and expecting them to remember things like "make sure the url starts with https://www.yahoo.com", you just tell the user to look for their customised text or image on the page. If it's not there, you're not at the right site, so don't supply your login credentials.

  • World of Warcraft uses the Blizzard Authenticator, which is either a device you can order and have shipped to you, or an iPhone/Android app. Both generate a unique code tied to your account every minute. When you log in, you need to provide your Battle.net registered email address, account password, and that Blizzard Authenticator code. Although it's a game, World of Warcraft is a phishing continent of its own, this approach has proved extremely effective in reducing the number of hacked accounts through phishing (since even if you hack into someone's email account and retrieve or change their World of Warcraft password, you can't log in unless you have that actual specific synched Authenticator code). It's worth noting that the Authenticator is theoretically hackable, but it takes much more work to do so.

  • myOpenID uses a similar sign in seal to Yahoo! called "your personal icon". Since OpenID has additional security implications (eg. if you gain access to my OpenID, you now potentially have access to all the sites I use with that OpenID), any options towards increased protection helps a lot. I don't think most nontechnical users have OpenID accounts with OpenID providers, however, so this might be less of a big deal. Still, good on JanRain for going the extra mile.

What to do when users provide obvious security questions and answers

This is a problem you can't solve, and it's not really your responsibility. What you should focus on is promoting the right behaviour in your users by educating them on what they need to pay attention to. Depending on the type of userbase you have, you can be more or less aggressive about it - for instance, Yahoo! and Blizzard are very aggressive and also implement more proactive security assistance, as mentioned above.

Some things you can do:

  • Remind users to use a unique password consisting of not only alphanumerical characters
  • Explain that passwords should be made from non-existent words, and help explain how to create a memorable password that fits that mold
  • Use clear copy during the flow where users create a security password reset question and underline the importance of asking non-trivial questions that other people won't know the answer to
  • Provide examples of questions that people could use (don't provide examples like "mother's maiden name", which is easily found via Facebook these days)
  • Write a FAQ providing tips on how to secure your account. Since webmail is an oft-used security hole, provide basic tips on securing your email account and how to watch for phishing attempts

Be a responsible website proprietor. I liken it to train stations that have signs up saying "watch out for pickpockets" - it's your responsibility as an individual not to have your wallet in clear view and then complain when it gets stolen. But it's nice of the station management to remind people to keep things in mind. The problem on the Web is that many people don't know what to look out for or how to identify threats. We can help by constantly, consistently educating everyone we come into contact with.

Captchas and alternatives

Captchas exist for two reasons: one, to prevent your site from getting DDOSed and two, to prevent hackers from executing dictionary attacks. But the downside is that, in most cases, they're very unfriendly and completely not "Don't Make Me Think".

If you want to prevent, or at least dissuade, dictionary attacks, consider adding a timer to the login screen that increases for every attempt (after a certain number). Most users will get in after, say, 5 attempts, and any more than that is dubious behaviour. Make dictionary attacks annoying to execute on by causing problems for offenders, not regular users.

Security vs. ease of use

Jakob Nielsen caused a splash last year when he wrote that password fields present a usability problem and should stop masking their input. He argued that masking the input only really prevents security leaks when someone is standing directly behind you, and that's not the case 99% of the time, so why make things harder to use just for an edge case? As a usability expert, it's hard to argue with him. And security expert Bruce Schneier even agreed with him!

So security vs. ease of use is a controversial issue that can't really be resolved. And it's a healthy argument: if things swayed too far in either direction, that wouldn't be good for end users. As a UI designer, it's important to recognise security experts' arguments, and take those into account when designing your user's experience.

  • That was fun. Hope I didn't bore anyone to death with that rant :P
    – Rahul
    Commented Oct 13, 2010 at 20:38
  • Great answer! Loads of different ground covered and really interesting with it. I'm leaning towards the use of a mobile phone app or otherwise integrating the user's phone as a component in the security process - I think for the application I'm planning to create it would be reasonable to assume that users have a mobile phone.
    – glenatron
    Commented Oct 13, 2010 at 21:52
  • 1
    And from a security point of view, never save the password, only save the hash and hence require the user to reset their password when they forget it. Commented Jun 1, 2011 at 1:53
  • I think the Blizzard Things rather may generate a code every minute. Commented Dec 23, 2013 at 14:35

Actually, with most providers out there offering login API's (usually based around Open Auth), you don't even need to deal with user login/authentication issues. Just have your users login with Facebook, Google, Yahoo, Twitter, etc... I feel that Google, Microsoft, Yahoo, et. al. will do a better job of securing login credentials and dealing with password resets than I will. This is really the best case for your users because they don't need to remember a new set of credentials and, in most cases, if they are already logged into their mail, they will not go through entering the password again. It's perfect one-click (no typing) sign-in.

There are two little gotchas to making this work. (1) You must support a relatively large number of login providers to ensure you capture all of your users without inconveniencing them. (2) You must support and encourage account linking so that users can add multiple sign-in providers to their account at your site because the providers can (and often do without warning) change their API or go down for maintenance effectively locking those users out of your site.

On the up-side to you, you can usually retrieve user parameters directly from the provider so that the user doesn't have to enter info such as e-mail address, name, phone, etc…                

  • With point #1, certain users may have no accounts in any of the supported systems, which is where a site-specific login may still be required for those users. As well, users may not be educated and think that logging in using Facebook will open up their account. P.S. You don't need valedictions and your name on answers as your account is right below it. Commented Jun 1, 2011 at 1:56
  • That means that the weakest link in my chain is the security of the OpenId providers I am allowing to access my system. For some types of site that is no big deal - if I was running a blogging platform or something I'd be fine with that - but this application needs to be properly secure and that means I am reluctant to trust other people with the burden of security for a login that could result in someone who has phished a user's credentials on another site entirely potentially being able to cost them money.
    – glenatron
    Commented Jun 3, 2011 at 14:34

To be honest, as a programmer, I don't really like personal question/answer security steps as the answers could be entered incorrectly from a strictly programming point of view. What happens if their answer was a name, but they don't remember if they put the whole name or just their short name or just their given name, or they miss an apostrophe and don't realise.

Captchas (of varying sorts) on the other hand require a black and white answer. It's either valid or it's not. That being said, the readability of the captcha sometimes presents problems for users. Most are readable, but some are just garble.

I think the method of requiring e-mail verification when resetting the password has always seemed fairly safe to me, as it clearly requires me to know my login details for a second system (my mail account) to access the link back to the site to ask for a new password.

  • I think my main concern is probably phishing or identity theft type situations, the risk of someone who is not my user trying to reset their password to access my site. I would like to make this very hard to do in a very easy-to-use fashion. Now a capcha will tell you that someone logging in is human, but won't identify a specific human, which is part of the puzzle I am trying to work out. If I go back to pure email-reminders, the weakest part in my security chain becomes the security of my users' email provider.
    – glenatron
    Commented Jun 3, 2011 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.