Poor Man's Authentication

Question

I'm developing an ASP.NET web site for some small business. The site needs a password-protected area where the site owner will manage the site content. For the rest of the world, the site is completely read-only.

I've designed and implemented the following scheme:

• A user wants to access some protected page.
• Every protected page inherits "AdminIface" master page, that alters the UI so that user knows he's on a protected page, and checks the security cookie. If no cookie or wrong cookie: redirect to auth.aspx.
• Auth.aspx generates a big random number using RNGCryptoServiceProvider, then sends it to the client + password form.
• User enters the password.
• Client-side JavaScript combines random seed + password, calculates MD5 of the resulting string, posts MD5 to the server.
• Server compares the random seed with the value hold by Session, if OK it combines random seed + password, calculates the MD5, compares MD5.
• If the checksum matched – the server generates one more big random number to be used as a security cookie.
• Server stores the security cookie in Session object, and sends the cookie to the client who's now considered authorized.

The correct password is stored as a string constant in the auth.aspx source.

Is this scheme OK?

P.S. I know AD+Kerberos is much better, however on the godaddy's shared hosting I've got no privileges even to create one more application.

Answer 1

Ummm, why not http://en.wikipedia.org/wiki/Basic_access_authentication with https (or even without)?

-- What's the real scenario of a threat?

Your method seems a bit hand-rolled. The usual rule is to try to use an existing security system rather than inventing your own. Inventing a new authentication mechanism that is really secure is known to be a very hard problem.

Answer 2

What is wrong with TLS/SSL? It would provide many benefits here, the least of which is some thread of site->user authentication.

Answer 3

I would just hard code the user authentication into the web.config. This means you can still use the Membership controls. A really good example can be seen here. No database required, nor Membership provider. If you have one user (or very few users) then this is a pretty good option.

If you are worried about the authentication details sitting in the web.config, then you can encrypt specific sections of the web.config.

This would appear to be a much simpler solution than you have implemented.

Answer 4

As kind of already mentioned, why not just use forms authentication with an SSL cert - dead easy to set up (particularly for one user) and you know that it's been tested... You don't know what you've potentially missed.

Answer 5

Many intelligent people (namely the Software Engineers who created WEP) have tried and failed at creating their own security authentication mechanisms and failed. The possibilities for screwing up your own "custom" security authentication are endless (no offense, but it is an extremely difficult problem to handle even for security experts).

I think it's best to use something that is proven to work such as an SSL certificate based authentication method.

Answer 6

It sound ok. Standard HMAC stuff. However your weaknesses:

1. Application: relying on javascript and sessions
2. Security: using a new codebase

Depending on your requirements you might be ok. having said that I strongly suggest using forms authentication, which overcomes these issues and much more.. and it is fairly easy to use.