7

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?

glenatron
  • 8,729
  • 3
  • 29
  • 43
  • What is the question? Do you want to know about better alternatives to passwords? Or is your question about password recovery? – Thomas Lötzer Oct 13 '10 at 13:14
  • Both. Password recovery is an obvious weak point in most web applications in that it seems you can either have it usable or have it secure. But like most bank sites now require more than simply a username and password I think I am likely to require that as well in some cases, so alternatives to passwords are also good news. – glenatron Oct 13 '10 at 13:25
  • 3
    Yes, but most banks suck at security: http://thedailywtf.com/Articles/WishItWas-TwoFactor-.aspx – Thomas Lötzer Oct 13 '10 at 13:43
  • 1
    This is why my goal is to create possibly the first ever site to have usable security that doesn't completely suck... – glenatron Oct 13 '10 at 13:47
  • 3
    If you want to be the first to do it then I am guessing no one will have an answer for you. Just saying. – Chris Oct 13 '10 at 14:24
  • You would think that enough people would have got it at least *partially* right that it would be possible to pull together a few sound ideas though. – glenatron Oct 13 '10 at 16:08
  • 1
    "but there is one massive potential security hole: I want the site to have users." +1 just for that :) – BlackICE Dec 06 '10 at 19:38

7 Answers7

6

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.

Jeff Siver
  • 1,721
  • 1
  • 11
  • 16
  • I like the "thing you have" aspect of having a physical card. But you know there will be the 20% of users who lose it. Then move house so you can't send them a new one to the same address. Then complain that they can't access the site... – glenatron Oct 13 '10 at 14:24
  • Users are stupid and do not even know what a passphrase is so I do not think this satisfies the "usability" aspect of the question. Regardless, good answer from my point of view. – Chris Oct 13 '10 at 14:27
  • @glenatron: Yes, some will lose it. But I believe challenge/response is the only truly secure method for a web site. @Chris: I agree somewhat on the passphrase usability. The biggest challenge is that it is different but I also think you need to be creative with the presentation. I don't know how successful Amazon has been with PayPhrase though to know how well this approach could work. – Jeff Siver Oct 13 '10 at 14:44
  • 1
    I'm wondering if there is a way to play to the ubiquity of mobile phones rather than using a separate usb dongle or whatever. I suspect that for the kind of site I'm thinking of building I probably could assume that most users had a mobile phone. – glenatron Oct 13 '10 at 16:11
  • @glenatron: I agree a phone can work but I think that creates two problems. First, the user must have their phone next to them when logging onto your site. Second, their phone must support whatever authentication method you will build (aka a smartphone of the right type if you have an app). In my mind, these makes phones not ideal unless the app itself has a specific appeal to people with a specific phone. – Jeff Siver Oct 13 '10 at 17:06
  • @Jeff Siver I know several banks that use SMS for verification. You can log in with account number and a PIN, then for every transaction you receive a unique code via SMS you have to enter. – Thomas Lötzer Oct 14 '10 at 07:25
  • @Thomas Lotzer: That is a form of the challenge/response device I mentioned in my post using text messages to provide the response. That is an interesting approach that could be a good alternative that I hadn't thought of. – Jeff Siver Oct 14 '10 at 13:56
  • @Thomas: From the umlaut in your last name, may I guess you don't live in the US? US cell phone companies typically charge for each SMS sent or received, and the charges would be significant if I did my online banking like that. – David Thornley Oct 28 '10 at 21:23
  • @David You're right, I don't live in the US. But how many transactions do you do? I do maybe 5 in a busy month, as do most people I know. For heavy users you're right, when incoming SMS cost money this is not a good idea. – Thomas Lötzer Oct 29 '10 at 09:36
  • Look at HOTP and TOTP if you can assume that your users have a mobile phone (practically any will do, there's some software even for Java ME feature phones). – Mikko Rantalainen May 07 '12 at 12:20
5

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.

Mike42
  • 932
  • 1
  • 8
  • 16
  • You are precisely right, but you've mostly restated my question. For what I'm planning to do, I don't think the single-element authentication/password recovery that many sites favour will be sufficient- hence asking about usable *alternatives* to the standard techniques. – glenatron Oct 13 '10 at 11:20
  • as per Thomas' comment on the question, e-bank authentications is almost always _not_ truly multi-factor (two+) auth. – Matt Ball Oct 13 '10 at 15:44
1

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.

luis.espinal
  • 2,560
  • 1
  • 20
  • 17
1

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.

Stu Pegg
  • 568
  • 2
  • 13
  • As for best sites, I find First Direct's security thorough but unobtrusive. – Stu Pegg Oct 13 '10 at 11:55
  • I have created a site that used these and it was impressive how users managed to subvert them. Thanks for the First Direct tip - I've not looked at them. – glenatron Oct 13 '10 at 12:08
  • I find predefined questions to actually be a reason *NOT* to use a site. Most of the answers to the questions can be googled for many people, making their security value tiny at best. – Thomas Lötzer Oct 13 '10 at 13:06
  • That is the other problem - if it is a question like "mothers maiden name" it is trivial to find this information, hence I'm asking about things that could prevent a targetted attack, which is probably the greatest risk. – glenatron Oct 13 '10 at 13:27
  • @glenatron: In targeted attacks passwords are often easily thwarted too. So, something they don't choose, like a memorable preset passphrase assigned to them from a random selection (e.g. Colour/flower "Yellow Tulip"). – Stu Pegg Oct 13 '10 at 16:46
  • @Thomas: Last time I signed up with a bank, I had non-Googleable answers for some questions, and didn't use the others. Anybody who wants to dig can find my mother's maiden name, but where I'd like a vacation home is different, considering it's not necessarily on this planet. – David Thornley Oct 28 '10 at 21:26
1

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

name_masked
  • 289
  • 2
  • 9
  • 1
    At this point the credentials of the weakest OpenID provider become the weakest link in the chain, presumably? – glenatron Oct 13 '10 at 16:06
  • Stackoverflow itself links the account to Google, Yahoo FB etc .. Do you mean that these sites have weak security setup? – name_masked Oct 13 '10 at 18:12
  • 1
    There isn't really anything about my account on these sites that would really make my life difficult if it was compromised. If I was using it to handle my money or other data I placed a high value on, I would need a lot of reassuring with regard to OpenID. When I was looking into it a while ago it didn't look to me as though OpenID had ever had to confront any serious attempts to compromise the system. Given how easy it is to set yourself up as an OpenID provider, I would worry about organisations having very weak security credentials authentication users for my high-security site. – glenatron Oct 13 '10 at 19:43
  • Makes sense to me know.. Thanks for the information. – name_masked Oct 13 '10 at 20:34
  • 1
    I do think that the more secure a site is the more value there is in using it as a provider for OpenID. – glenatron Oct 14 '10 at 15:32
  • would you mind explaining more on what these resources do and why do you recommend these as answering the question asked? ["Link-only answers"](http://meta.stackoverflow.com/tags/link-only-answers/info "what's this") are not quite welcome at Stack Exchange – gnat Sep 27 '13 at 09:11
0

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.

Joeri Sebrechts
  • 12,922
  • 3
  • 29
  • 39
  • Not, in this case, possible. However, the technical side of it I have some fairly solid experience in and I'm not overly concerned with how to work that. It's more how to make things that are easy for a user to use. – glenatron Oct 13 '10 at 15:16
0

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!

Rory Alsop
  • 326
  • 3
  • 12