Dave Winkle writes:
> 5. KLP -- A client-side proxy server and a server side cgi-bin handle
> authentication between them. It sounds like a cross between Gradient and
> CUKerb. The things I don't like about it are the cgi-bin overhead for
> every webrequest, and the authentication overhead for every web request.
> (For ever web request that goes through the CGI, the script starts up,
> gets a token from a srvtab, answers the request, and quits.) This is in
> development, and the only reason I mention it is because it was mentioned
> by Marcus. It requires a Kerberos implementation on every desktop.
I think gradient's approach may be a commercial DCE version of
KLP. I'm not real clear on that however. (I was much more
interested in how it worked, than in who owned it, when I saw it.)
With KLP, the authentication overhead only applies to requests
to the special URL's. Normal URLs are passed through in an
entirely transparent fashion, just like any other proxy server.
You have to have server side "overhead" no matter how you do things.
Somebody has to decrypt and encrypt the data, and do whatever additional
authorization checking is necessary. The most likely time when you
want web side authentication is when you are "Doing" something (like
changing a person's subscription information, etc.) and this
generally requires a cgi binary anyways. If this were a big
objection, though, I'm sure it would be easy enough to modify
apache (or anybody else) to do whatever was needed, or
to come up with clever wrapper programs.
>
> 6. "Basic Authentication" and SSL -- Hack basic authentication to
> hide behind a secure server, so that all calls are encrypted to and from
> the server. Which means that, while the password is passed for every
> request, it's passed encrypted with a 40-bit key, or if you're paranoid,
> with a 128-bit key in the US. This is supported by Netscape's browser.
> I haven't had any time to explore how viable this option is, though I'd
> like to.
Easy hack. Bring up your shady server. It looks *just* like the
real thing, except it uses plain old HTTP, and it's really a proxy
server. It snarfs your password, then sets up an HTTPS connection
to the real server. Set up a terrific set of links that point to
just the resources people really need (currently, umich's links are
really terrible and a horrible pain to traverse), and you're in business.
For best results, set up your server in Bermuda, and advertise an
809 # for assistance. With the weather cooling down in North America,
now is a great time to winter in Bermuda.
Fun variations. Don't set up your own server. Hack into any service
provider's server, and steal passwords there. Or go with the
easy approach. Hack a copy of netscape to use a lousy 128 bit key,
put it on a bunch of machines in a lab, then just sniff the wire.
Tell people that you're doing them a favour by installing a 128 bit
client, instead of the 40 bit binary everyone else is using.
Any solution that involves passing cleartext passwords to
a server is *definitely* a serious weakness (to kerberos at least,)
because that gives any service provider the chance to steal passwords
that work everywhere. You *really* only want to send kerberos tickets
to the server instead, that are (a) only valid for a limited period
of time, and (b) [& much more importantly] are only valid for
*THAT* server.
Nevertheless, HTTPS does do one valuable service - by encrypting
the whole conversation, it does a better job of protecting the
data in transit, & makes it that much harder for the bad guy to
either change data in transit, or sniff the wire and learn a secret
that is useful later.
The long term solution is probably to figure out a way to
integrate HTTPS client side authentication with existing
authentication infrastructure.
>
> 7. Netscape's API -- Run something under Netscape's cookie model that
> lets a user authenticate and get a Netscape cookie, which the browser then
> uses to get subsequent pages, until the cookie expires, the browser exits,
> or the user explicitly logs out. The server has to keep track of the
> cookies and identities, though. Drawback is that it limits you to
> Netscape's browsers, and Netscape's server.
Actually, most of the commercial browsers support cookies.
See http://www.research.digital.com/nsl/formtest/stats-by-test/NetscapeCookie.html
(which in turn is under http://www.research.digital.com/nsl/formtest/home.html).
The server does not need to keep track of the cookie. The cookie can
be of a fairly generous size. All you need do is store, in the cookie,
encrypted state information about the user, using a secret key only
known to the server.
Some of the early browsers had serious bugs with cookies. I forget
what they were, but they were bad.
Cookies do not protect the integrity of the data channel (unlike HTTPS).
However, cookies *can* be sent with a flag that request that they
only be sent over a secure channel (HTTPS), & cgi binaries should
also be able to check that the channel to the user is secure (with stronghold,
that's a matter of looking for the environment variables like:
HTTPS on
HTTPS_CIPHER (name)
HTTPS_KEYSIZE #
HTTPS_SECRETKEYSIZE #
The hardest problem with cookies is figuring out how to generate
them in the first place. There is a kind of a chicken and the
egg problem here.
Still, I agree cookies are an interesting technology.
-Marcus Watts
UM ITD PD&D Umich Systems Group
