Re: APOP - authentication..

Ned replied to me:
----------
]
] Of course there are options to be "kinda secure". In fact that's the 
only way:
] Everything we do is only "kinda secure". Security is, and always will be, a
] matter of compromise. Too much security makes things unusable. Too 
little makes
] things too easy to break into. A balance has to be found between 
usability and
] security. The only question is whether or not we've achieved the 
right balance.

I understand that there's no such thing as absolute security. By "kinda 
secure" I meant to informally denote two things: if it appears to or 
claims to provide more security than it actually does, especially to 
non-experts, so that they will trust it more than it should be trusted; 
or if it provides less or equal security than other mechanisms that are 
less expensive or intrusive, then that's what qualifies it for "kinda 
secure". Not a universal definition, I admit, and I was hoping it would 
be clearer from context than it appears to have been.

To apply this definition to the case at hand, a correct Digest 
Authentication implementation that does not use your recommendations in 
your original post, will be "kinda secure" -- not much more secure than 
basic authentication, and more computationally expensive, and the use 
of "strong" digest algorithms may encourage a false sense of security.  
(Snooping a basic password will probably get you immediate access to 
more URIs than snooping an Authorization: Digest header field, so 
Digest is somewhat better than Basic -- but if the snooper listens for 
very long, pretty soon they will have values for the Authorization: 
Digest header field for all the popular pages at the site...)

] The cost of all these things is the server having to modify a 
per-user database
] entry. This may be cheap or it may be expensive. The question is the 
cost worth
] the potential saving of a challenge operation in the protocol and the 
increased
] security you get out of it?

Yes. It will be very cheap. The implementation can be stupid, because 
it can always fall back on a challenge; all it has to do is reduce the 
frequency.

Climbing _way_ out on the limb, it seems it can't be much harder than this:

#define NTSIZE 1024		// any size is OK, tune to server load

typdef struct {
	char * username;	// username of client
	char * realm;		// realm, to support multirealm hosts
	int nonce;		// next nonce expected from this client
} nonce_ent;

nonce_ent noncetab[NTSIZE];

nonceinit() {
	int i;
	for (i - 0; i < NTSIZE; i++) noncetab[i].username = 0;
};

// return hash if not in table, -1 if it is
int noncecheck(char * username, char * realm, int nonce) {
	int h;

	h = hash(username) + hash(realm);
	h = h % NTSIZE;
	if (strcmp(noncetab[h].username, username) != 0)
		return(h);
	if (strcmp(noncetab[h].realm, realm) != 0)
		return(h);
	if (noncetab[h].nonce != nonce-1)
		return(h);
	return(-1);
};

noncenew(int h, char * username, char * realm, int nonce) {
	if (noncetab[h].username) {
		free(noncetab[h].username);
		free(noncetab[h].realm);
	};
	noncetab[h].username = strdup(username);
	noncetab[h].realm = strdup(realm);
	noncetab[h].nonce = nonce;
};

// stupid hash...
int hash(char * s) {
	int h;

	for (h = 0; *s; s++) h = (h << 4 ) + (h >> 28) + *s;
	return(h & 0x7fffffff);
};


Compared to computing and chcking the MD5, this is trivial in cost, and 
the table size can be made small if the server is configured for light duty.

There is *no* reason to risk more front page stories the the NYT and 
WSJ that undermine people's confidence in the Web for something that 
costs so little.


All the recommendations -- your's, Dave Kristol's, and John Franks' -- 
are all very good. All of them are cheap to implement, too.  So why not 
change the spec something like this:
	opaque= <opaque> | <recommended-stuff>
	<recommended-stuff> =
	<server-dependent (compile-time) random number>
	<timestamp>
	<request IP address>
	<(time-dependent) nonce>
	<security realm>
so that it is clear how implementors should do better security.
Make it clear that clients increment the nonce each time they send a 
new request, even if servers do not check for freshness of the nonce, 
in order to make possible ones that do.

Or at least include a synopsis of your posting and John Franks' and 
Dave Kristol's on how to do a good implementation, in an appendix. 
Isn't this sort of required in a "Security Considerations" section that 
will eventually have to be added if it gets turned into an RFC?

Paul

Received on Wednesday, 21 February 1996 12:21:12 UTC