Which authentication mechanism to choose?

Question

Well, on my free time, I'm making this small web site. The site will not require to authenticate, only some actions (like leaving a comment) will require to do so.

I would expect to have up to 100 (probably less) unique visitors a day. I don't really expect more than 50% to (bother to) register.

Right now, I'm thinking of three possible authentication mechanisms (but I'm open to suggestions):

• OpenID authentication;
• HTTP Digest or at least HTTP Basic authentication;
• My own (form based) authentication.

OpenID seems to me a little bit of an overkill for a small site like this. Also, buzzword like "OpenID" on the login page of my site might scare away the less tech-savvy people.

HTTP Digest (or Basic) authentication provides a low security level (or none at all), because the site will not be under HTTPS.

My own implementation would, most likely, suffer the same security problems as the HTTP Digest would. Although, I could implement some more protection against brute-force attacks (display a captcha after three failures etc).

What other mechanisms would you suggest? What are the pros and cons that I'm not seeing? What would you choose?

Answer 1

Well, if you want your visitors to leave comments I really think you're better of with something like OpenID. Because if you provide your own form based authentication who will really bother registering yet another account with some password wondering if they can trust you?

I think it's safe to say that people who like the internet own a gmail account, and all those people have an OpenID (Google account).

I suggest you use that... that's what I would do.

Answer 2

You haven't said what language/technology you're using. It could affect things. But I'd be inclined to just roll your own form-based authentication. It's not terribly difficult. Just remember a few basics:

• Always sanitize user input. It can't be trusted;
• Never store a username or password in a cookie (believe me people do);
• Only store encrypted passwords using a reliable encryption method like MD5 or SHA1;
• Use a non-predictable salt;
• Require cookies to be enabled. Don't try and do URL rewriting.

Answer 3

Why not just have a name field when they post a comment, perhaps remember it in a cookie if you want. Most users just want to identify themselves not have an account.

Just make sure that you have some spam blocking in place as forms attract spam bots. Even if that is just a capcha with the form every time.

Answer 4

Openid is the best I think. Also if you give proer help about open id (or like SOF shows) then people will uderstand. Once less tech savvy people uderstand the use of opend id (no new username and pwd) then they will start liking it.

Answer 5

Definitely go with OpenID - the more people we get onboard, the more familiar people will become with it, and it's not really that strange to use the first time. If you are a microsoft dev, the dotNetOpenID library makes implementation pretty straightforward - I have done this for both ASP.NET and ASP.NET MVC sites with no problems.

EDIT:

With regard to supporting non tech-savvy users, some links / explanation on the login page would go a long way to alleviating concerns. The redirect they will see is quite similar to experiences that they are more familiar with, like credit card or paypal authorization, so should be easy to explain in these terms.

Answer 6

You could distribute some RSA SecurID to your visitors ;-)

Seriously, the main question to ask is: does the total hour of work to implement a decent security system for my users to log in are worth the content that may be accessed if the website security is broken?

Answer 7

You should look into RPX (https://rpxnow.com/), its a layer on top of OpenID and a few other schemes that for most languages is really easy to implement (there is a gem for ruby and I know a friend of mine got it into his php application in a less than a couple of hours).

Answer 8

OpenID rules! As an informed user I'm not sure it's been looked at to the point where it's "bulletproof" for security, so I probably wouldn't use it for financial / medical websites, but for the 95% of other websites, it would save me from having to write down my cheat-sheet of 137 different usernames and passwords. I've used it in a (nonpublic) site I developed and it was a bit of a hassle to get the authentication working properly, but if you can use one of the libraries out there, go for it!

HTTP authentication is standardized but something about it disturbs me. I dunno what. Something about a separate dialog box popping out of the browser makes me suspicious.

p.s. BBC's Digital Planet had a radio program my local radio station aired yesterday (17 Feb 2009) that talked about OpenID. So I guess when the radio talks about it, it must be starting to go mainstream.

Answer 9

My advice: do not reinvent the wheel. Web authentication is a wheel if I ever saw one, and it's remarkably difficult to get all the subtle pitfalls handled correctly. Chances are you'd miss something and end up with effectively no security.

Either go with an OpenID solution, or look into the many auth libraries out there, and pick a thoroughly-tested one.

See also: The Definitive Guide To Website Authentication

Answer 10

It depends in part who your target audience is. If they're all computer geeks, go with OpenID. They're either familiar with it, or will understand what you're doing. If they're not necessarily computer geeks, they may not have been exposed to OpenID authentication yet, so OpenID could present a barrier to entry. In that case, you might want to go a more traditional route, such as register/validate email/login approach, whether roll-your-own or off-the-shelf.