What's the best way to enforce a user authentication mechanism for a Web application, wherein we have 5000 concurrent users? The environment is ASP 3.0/SQL Server 7.0/IIS 5.0.
There are a number of Web sites I go to where there's a simple Web server password on the pages. This is very low security -- everything's in plaintext -- but it does keep the riff-raff out. As an example, I know people who put up draft versions of documents that will eventually become public on password-protected Web sites.
I read stories on Salon, where I have paid for "premium" content. Similarly to the New York Times, there's a cookie on my system with my credential. The risks here are slightly higher -- if someone can nab a copy of my credential, then they can read Salon without paying for it. But Salon also has to make it easy for me to read stories without getting in my face too much. Their decision is to make things easy for the user, which I wholeheartedly support. Many such sites offer to mail a user their password to a registered e-mail address if they lose it. This has some security implications, in particular that it effectively ties ownership of the account to ownership of the e-mail address. If someone steals your e-mail address (or its password), then they have control of your various Web accounts. It also means that there is some database that actually has all the users' passwords, and in theory, this can be lost. This means that if you are the user of a Web service that can mail you your password, you should make sure it's a password that is not replicated in some high-value service (like your bank). This is the perfect place to use those passwords people tell you not to use, like your dog's name or your favorite color.
Web stores typically use a password protected by SSL as authentication for purchases. They may also use some low security mechanism like a cookie for low-security functions. A good example of this is Amazon. Cookies identify you to the site, so that it can be tailored to you, but when you get ready to use money, SSL comes into play. Some Web services require users to change their passwords periodically.
Some higher-valued services use SSL user (client-side) authentication. This uses a certificate to identify the user to the server. The problems here include: It depends on what sort of Web application you have. And that boils down in most cases to how much your application directly touches money. In many or most cases, a good old-fashioned password works just fine. Here are some examples:
How do you get the certificate to the user?
How do you handle a user who has a desktop machine and a laptop?
There are many answers to these problems, but you need to solve them. That's an overview of the sort of options you have, with a number of examples. It depends on what you want to do and how you feel about it. I've seen the most sophisticated mechanisms used for business systems, as well as the least sophisticated ones used for similar business systems. In all security analysis, you have to make your own analysis of what you have to protect and how much effort to expend in doing it. Since you are using IIS, you should also be aware that IIS is considered the least secure Web server there is. If you are going to make a high-value system then you should strongly consider one of these options:
A Web server other than IIS. Apache and iPlanet are each generally considered good choices. I use WebStar, myself.
A different Web server with a third-party implementation of Active Server Pages like Halcyon Immunity.
Buy, install, and use some third-party products for your IIS server to help secure it. Entercept, HP, Sanctum and Okena all make products that can help you protect an IIS server. It would be unfortunate to spend a lot of time on a secure authentication system for your users, only to have your system wiped out by the next work that comes along.
This was last published in January 2002
Dig Deeper on Two-factor and multifactor authentication strategies