Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation

[der Mouse <[e-mail]>]

>> * Certificates do not authenticate the user.  They authenticate a
>> device.
> I don't think they do that exactly either.  The client cert is
> generally public, its private key is a secret like a password, but
> one that's too hard to memorize.

Quite aside from memorizability, few-to-no humans are capable of
performing the cryptographic operations (large-number arithmetic,
usually) necessary to carry out certificate operations, at least not
with the required levels of reliability.  (I can do multi-hundred-digit
arithmetic, yes, but not nearly either fast enough or free enough of
mistakes to be useful for the purpose.)

Certificates, at best, determine that some device which is capable of
performing the cryptographic operations has been given access to the
corresponding private data.  This is close enough to authenticating a
user to be useful for many purposes, but it is not the same thing.

Of course, the same is true of passwords.  All passwords demonstrate is
that some device capable of injecting data into the comm channel in
question knows the password.  But passwords rarely lull people into
forgetting the difference.

> For most systems, the vast majority of 'no's are not actual attacks.

Are you sure of that?  There are an awful lot of doorknob-rattlers out
there.  Most of the login failures I see on my machines actually _are_
attackers poking to see if I've made stupid mistakes.

> Yeah.  How did the user select their password for the website in the
> first place, if not by an HTML form POST?

> If it was good enough for the initial sign up, why should the web
> designer use something other than HTML form POST for the regular
> login?

For all that that's rhetorical, there is an answer: because one occurs
only once while the other occurs many times.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[e-mail]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B