User authentication mechanisms for Web applications |
 |
EXPERT RESPONSE FROM: Jonathan Callas
|
|
|
|
| > |
QUESTION POSED ON: 14 January 2002
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.
|
|
| > |
EXPERT RESPONSE
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:
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:
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.
|
|
|
|
|
|
|
|
Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and
answer pairs from more than 250 TechTarget industry experts.
|
|
|
|
|
|
|
|
|
|
|
|
