RE: Proxy with auth but without the request of the login+password every time

From: Chris Dillon <cdillon@dont-contact.us>
Date: Mon, 11 Oct 1999 16:34:34 -0500 (CDT)

On Mon, 11 Oct 1999, Williams Jon wrote:

> I haven't had any replies wanting to take this off-list, so I'll go ahead
> and talk here :-)
>
> Although the ident option could be used to improve the chances of
> identifying abusers somewhat, there are a couple of things to consider.
> First, there really isn't a way to confirm that the identity being presented
> is really the identity of the person at the keyboard (note, this is the main
> reason I don't like the so-called transparent authentication stuff). Since
> ident is running inside the process space on the local machine, it is
> relatively simple to modify it to present different credentials (i.e. log in
> as a different user, hit "Cancel" on the Win '95 login prompt, etc.).
> Furthermore, ident doesn't have a robust authentication or security
> mechanism behind it, making it very easy to defraud.

This is what I already pointed out. However, you can prevent someone
from pressing the "Cancel" button at the Win9X logon prompt. If the
user is able to log on as someone else, you have much bigger problems,
and any other type of authentication you can think of would be just as
useless.

> Second, remember that those users who are most likely to want to bypass any
> security mechanisms are also those who are most likely to have the
> knowledge/experience to get past the security-through-obscurity stuff. In
> many workplaces, for example, the end user is set up as a local
> administrator in NT so they can install software. This means that they have
> total control over that box, and can remove programs, modify system files,
> etc.

Nobody gets NT administrator rights around here but me, and installing
your own software is taboo. :-) Under a REAL operating system with
process and file security (NT, Unix, etc.) is where ident would work
the most reliably (and is actually where it was originally conceived
to be used) since the user would not be able to disable the service or
change it in any way. Granted, ident is still no better than using
plaintext passwords, but it is no worse, either, since you can "trust"
the host that the ident came from assuming you've used the proper
process and file security to protect the identd service on the host.

> Finally, identity is not very useful unless you can do some robust form of
> authentication (i.e. if I say that I'm really the John Williams who composed
> the theme music for Star Wars and Jaws, you wouldn't believe me unless I
> were to provide some supporting evidence of my identity). Without
> authentication, authorization becomes impossible since I can't decide what
> you should have access to if I don't know for sure who you are.

This is where PKI or even Kerberos comes into place. PKI everywhere
would be really nice, but its pretty complex, and nothing supports
using it for general user authentication on Windoze machines without
forking out the big bucks. Kerberos is just a bit complex, and is
generally only good for authentication (which goes hand-in-hand with
identity).

> This all just goes to underscore my main premise: end user convenience
> frequently adds nothing to security at best, and completely undermines it at
> worst. My guess, having just started looking at this, is that the HTTP
> specs will need to be updated to allow another proxy header that would make
> use of cookies or digital certificates to get a better way to verify an
> identity. I've got a couple of brainstorm-level ideas that I'd be happy to
> toss about, but I do really believe that it would go way off-topic so we
> should do the discussion outside the list.

You don't have to add anything to the HTTP protocol to use digital
certificates for authentication. SSL is already used for that.
However, I don't know exactly how that would come into play with
proxies. More than likely, you would still need to keep your proxy
authentication on the side as is done now, if you want it done
transparently. I'll leave it up to someone else to figure out how to
use SSL and PKI for that. :-)

Also, user convenience doesn't necessarily have to compromise security
at all. Only convenience using insecure methods will. PKI and
Kerberos can already provide convenience (at least for the end-user if
not the administrator) while maintaining extremely good security.
Applications must be written to take advantage of these, though, and
there are unfortunately relatively few.

>
> Jon
>
> > -----Original Message-----
> > From: Chris Dillon [SMTP:cdillon@wolves.k12.mo.us]
> > Sent: Friday, October 08, 1999 8:36 PM
> > To: Williams Jon
> > Cc: 'Luciano Ghezzi'; squid-users@ircache.net
> > Subject: RE: Proxy with auth but without the request of the
> > login+password every time
> >
> > On Fri, 8 Oct 1999, Williams Jon wrote:
> >
> > > Much to my dismay, I find that I'm going to have to at least look at
> > this
> > > option, as well. I'm not thrilled because this is basically worthless
> > from
> > > a security point of view and fairly useless from an authentication one,
> > but
> > > I just do what I'm told :-)
> > >
> > > At any rate, I can see that this discussion could fairly quickly flow
> > into
> > > the "off-topic" space, so I'd like to suggest that we put together a
> > small
> > > working group to work seperately from the squid-users list and then
> > report
> > > back on our findings. I'd be happy to try to coordinate such an effort
> > if
> > > others see a need.
> >
> > I've been doing exactly this since late last year. So far nearly all
> > of our workstations are running Windows95, and each one must log on to
> > a Windows NT domain. Using the logon scripts, I install and run an
> > ident server on each workstation each time a user logs in. The ident
> > server returns the name of the user currently logged in.
> >
> > See http://www.acs.ucalgary.ca/~mmastrac/files/identd.html for an
> > excellent identd server for 9X/NT that works exactly like it should in
> > this situation... invisibly. :-) I even identified an RFC compliancy
> > issue of this identd server that caused Squid to handle the ident
> > replies incorrectly (Squid was changed, too, so as to not be so
> > strict). I'm still using version 1.3, and I see that he has 1.5 out.
> > I'll have to download it next week and see what is new. If you need
> > help with the logon scripts that use this, send me another message
> > privately.. no sense in clogging things up here.
> >
> > I don't use it for authentication, which would be ridiculous, but
> > rather a "helper" for finding out who went where when the inevitible
> > question arises when someone thinks someone went where they shouldn't
> > have (I work for a K-12 school district). My only other alternative
> > was to match the IP address in the Squid logs to a DHCP lease to get a
> > NetBIOS machine name, and then match that machine name to the security
> > audit logs on each of the NT domain controllers to find out who was
> > logged into that workstation at that time. What a pain! Should a
> > definite answer be required, I still have to check things the hard
> > way, since ident can't be relied on for proof-positive logging for the
> > same reasons it can't be relied on for authentication.
> >
> > I suppose if your users are ignorant enough (I'm betting most of mine
> > are), they won't know that ident is being used for authentication, and
> > even if they did, they'd have to know how to subvert that. Security
> > through obscurity and/or ignorance. Not good practice, but when its
> > that or nothing... Maybe someone who needs this kind of thing badly
> > enough can develop a secure way to do transparent authentication to be
> > used with Squid.

-- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net
   FreeBSD: The fastest and most stable server OS on the planet.
   For Intel x86 and Alpha architectures (SPARC under development).
   ( http://www.freebsd.org )

   "One should admire Windows users. It takes a great deal of
    courage to trust Windows with your data."
Received on Mon Oct 11 1999 - 15:49:58 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:48:46 MST