HTTP(S) Authentication Response

["Chris L. Mason" <cmason () UNIXZONE COM>]

My post regarding the use of HTTP Basic Access Authentication generated a
bunch of replies and some criticism.  Since I don't have time to respond
invidually to everyone, I hope I can address each of the issues in a single
posting.


SSL is needed
-------------

Oops, I guess I should have said "HTTPS" authentication, not "HTTP"
authentication.  :)  Of course SSL should be used.  It's the same issue for
form submissions.  Just like people should be using ssh instead of telnet
or rlogin.  Remember, we're talking financial data here, it's probably best
to encrypt everything.  Of course, general non-account-specific data (which
would be outside the authentication realm) would not have to be encrypted.


Clients are insecure
--------------------

Right, but these insecurities exist regardless.  If your client system is
not secure you've got many problems.  Consider the following:

1.  You could have backorifice installed and your keystrokes could be
        monitored (if you're running windows.)

2.  You X-session could be monitored (if you're running Linux/*BSD/UNIX)

3.  A trojan copy of Netscape or another browser could be installed which
    logs all passwords.

4.  Someone could install a kernel module that monitors your memory.

5.  The infamous yellow sticky!

What's the solution?  Use applications and operating systems that are
sufficient secure for your needs.  For example usernames and passwords may
be cached in memory but shouldn't be cached to disk.  If worried about swap
space, it could be encrypted (a la OpenBSD.)  General host security
measures must be taken.  If your system can be broken into you've lost,
period.  It doesn't matter what security and application architecture
a remote website is using at that point.


Clients might cache data too long
---------------------------------

So, that's a client problem.  The client could also cache form submission
data.  In fact mozilla does this.  It's a client design problem and the
issues are the same no matter what type of authentication method you use.


Proxy servers don't always work
-------------------------------

Some proxy servers also have problems submitting forms that have too much
data.  Sometimes there are problems with chaining proxies.  There are going
to be potential incompatibility issues with *any* proxy server, whether it
be for ftp, telnet, http, whatever.  That is the nature of a proxy server.
It has a number of advantages, but also some disadvantage.  The client
(individual or firm) must weigh these when making a decision to use a proxy
server.

(Despite the above statement, I've used a number of proxies and never had
problems with HTTP authentication including Netscape proxy, squid and
junkbuster.)


Dictionary attacks are hard to detect
-------------------------------------

On the contrary!  It's true that authentication does not happen at the CGI
level.  This is an advantage.  All authentication can go through a single
module, perhaps talking to a central backend system, with the intelligence
to do logging, traffic analysis, intrusion detection, etc.  Removing the
authentication from the CGI can make it much *easier* to detect attacks.


Login/Logout paradigms are okay
-------------------------------

Perhaps in some cases, but the great majority of web users don't expect the
web to work like a client/server application.  They expect to be able to
bookmark pages, email URLs to friends, and be able to use the back button
in their browser.  If try to operate a website that breaks these
conventions, you will dramatically lower usability.

See Jakob Nielson's alertbox (www.useit.com/alertbox) for many well-written
articles that explain this much better than I can.


Cookies can do the job
----------------------

Okay, if coded properly and implemented carefully with the proper
cryptography, yes cookies can provide the same security and functionality
as HTTP Basic Access Authentication.  However, security and simplicity go
hand and hand.  A simpler solution will, in general, be more secure, and
easier to secure that a more complex one.

Secondly, some people don't trust cookies and turn them off.  Why should
you lose these customers?  Pretty much every browser supports HTTP
Authentication, including text based browsers like lynx and w3m and even
the ancient Mosaic.

I usually ask companies to think about it this way:  "Would you turn away
every customer in a red car, or wearing a brown jacket?"  Of course not,
even if they're only 10% of the potential clientele.  That could make the
difference between a profit and a loss. (I think Jakob Nielson first came
up with this type of example.)



Chris