Geek Answers Handbook

What authentication mechanism to choose?

Well, in my free time I do this little website. The site does not require authentication, this will require only some actions (for example, leave a comment).

I would expect that we will have up to 100 (possibly fewer) unique visitors per day. I really do not expect registration by more than 50%.

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 a bit redundant to me for a small site like this. In addition, a buzzword like “OpenID” on the login page on my site can scare away less skilled people.

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

My own implementation is likely to have the same security issues as the HTTP digest. Although I could implement some additional protection against brute force attacks (display interception after three failures, etc.).

What other mechanisms would you suggest? What are the pros and cons I do not see? What would you choose?

+4
source share
10 answers

This partly depends on your target audience. If they are all computer geeks, go with OpenID. They either know him or understand what you are doing. If they are not necessarily computer geeks, they may not have been authenticated by OpenID yet, so OpenID can be an obstacle to entry. In this case, you may want to use a more traditional route, for example, register / check the approach to email / registration, regardless of whether you use your own or ready to use.

0
source

Well, if you want your visitors to comment, I really think you're better off with something like OpenID. Because if you provide your own forms-based authentication that will really try to register another account with some password, wondering if they can trust you?

I think it’s safe to say that people who like the Internet have a gmail account, and all these people have an OpenID (Google Account).

I suggest you use this ... what I will do.

+4
source

You did not say which language / technology you are using. It can affect things. But I would be inclined to just roll your own forms-based authentication. This is not terribly difficult. Just remember a few basics:

  • Always sanitize user input. He cannot be trusted;
  • Never store your username or password in a cookie (trust me that people do this);
  • Save only encrypted passwords using a strong encryption method such as MD5 or SHA1;
  • Use inconsistent salt;
  • Require cookies to be enabled. Do not try to rewrite the URL.
+1
source

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

Just make sure you have spam blocking in place, as forms attract spam bots. Even if it's just a hat with a shape every time.

+1
source

Openid is the best I think. Also, if you give proer help on opening an id (or, for example, SOF show), people will avoid it. After less experienced people realize that you are using opend id (there is no new username and pwd), then they will start to love him.

+1
source

Definitely go with OpenID - the more people we choose on board, the more familiar people will become, and it's not so strange to use it for the first time. If you are a microsoft developer, the dotNetOpenID library makes the implementation pretty simple - I did this for both ASP.NET and ASP.NET MVC without any problems.

EDIT:

Regarding support for non-technology users, some links / explanations on the login page will go a long way to alleviating problems. The forwarding that they see is very similar to the experience they are more familiar with, for example, using a credit card or PayPal authorization, so they are easy to explain in these terms.

+1
source

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

Seriously, the main question that should be asked is that the total hour of work for implementing a decent security system for my users to log in is worth the content that can be accessed if the site’s security violation is violated?

0
source

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

0
source

OpenID Rules! As an informed user, I’m not sure that it has been considered to the extent that it is “bulletproof” for security, so I probably won’t use it for financial / medical websites, but for 95% of other websites it will save I need to write my cheat sheet of 137 different usernames and passwords. I used it on a (non-public) site that I developed, and it was a bit of a hassle to authenticate, but if you can use one of the libraries, go for it!

HTTP authentication is standardized, but something bothers me about it. I do not know what. Something about a separate dialog box exiting the browser makes me suspicious.

ps The BBC Digital Planet broadcasted my local radio station, broadcast yesterday (February 17, 2009), which talked about OpenID. Therefore, I think when the radio talks about it, it should start going mostly.

0
source

My advice: do not reinvent the wheel. . Authentication over the Internet is the wheel if I have ever seen it, and it’s very difficult to properly handle all the subtle traps. Most likely, you will miss something and as a result you will not get any security.

Either go with the OpenID solution, or browse through many archive libraries and select carefully tested ones.

See also: Ultimate Website Authentication Guide

0
source

More articles:


All Articles