Re: APOP - authentication..

> Here are some requirements that I am asked to provide today...

> 	An authentication scheme that can be implemented in a proxy to
> 	tie in a user to a request that is strong enough that if the
> 	user breaks the company rules then the employee can be dismissed.

> 	That is I need auth that can be demonstrated in a court of law as
> 	being "spoof proof"

> 	Can we do it?

Of course not. I am frankly appalled that you would even ask this question.

Let's suppose for a moment that we build a perfect authentication service for
the Internet, one that cannot possibly be compromised at the network level in
any way. The server is perfect, the on-wire protocol is perfect, and the
implementation on the user's PC is perfect. (I have no idea how we'd do such a
thing, but let's assume we can for the moment.)

This service has to interact with the user to obtain authorization to use their
credentials. It could use a password, or maybe a fingerprint, or perhaps a
retinal scan, or the hot new face-scanning technology I read about the other
day in some magazine. Doesn't matter. When faced with evidence that the user
employed his or her credentials to do something someone considers naughty, they
can always, repeat ALWAYS, claim that the credentials were stolen, forged,
scooped up by a Trojan Horse, they were coerced into providing them, someone
broken into the server and forged the logs that say they did it, and so on and
so forth. This is *especially* true of passwords. And there's no way to
disprove such assertions per se, and certainly not at the network protocol
level. Circumstances may exist that you think make the user's claim improbable
to the point of absurdity, but that doesn't necessarily mean squat in a court
of law. You have to look no further than recent court cases here in Los Angeles
(there are a number to choose from) to see that this is far from an academic
point.

So forget about offering guarantees that a given auth scheme will stand up
in court. As it happens I've been there and done this sort of thing, not
once but twice, and there are NO guarantees along these lines.

The best we can accomplish is to devise network authentication mechanisms
that are both reasonably implementable, deployable, and secure at the
network protocol level. In other words, we need to make sure we're part
of the solution, not the problem. And this means that things have to
balance -- there is no point in making a single element of the overall
setup highly restrictive when there are other, easier, ways to attack the
setup as a whole. In fact making things overly restrictive does more harm
than good, as people will find ways of avoiding the restrictions that
end up compromising the security we provide. The classic example is
password: Force people to use long, random passwords and they will write
them down every time, and thus defeat the purpose of having them in the
first place.

				Ned

Received on Wednesday, 21 February 1996 11:03:17 UTC