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

der Mouse <mouse@Rodents-Montreal.ORG> Thu, 16 December 2010 18:25 UTC

Return-Path: <mouse@Sparkle.Rodents-Montreal.ORG>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1FE73A695C; Thu, 16 Dec 2010 10:25:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.592
X-Spam-Status: No, score=-8.592 tagged_above=-999 required=5 tests=[AWL=1.396, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x+kGeUEiyEFF; Thu, 16 Dec 2010 10:25:54 -0800 (PST)
Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG []) by (Postfix) with ESMTP id 156FD3A6953; Thu, 16 Dec 2010 10:25:53 -0800 (PST)
Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA03511; Thu, 16 Dec 2010 13:27:37 -0500 (EST)
Date: Thu, 16 Dec 2010 13:27:37 -0500
From: der Mouse <mouse@Rodents-Montreal.ORG>
Message-Id: <201012161827.NAA03511@Sparkle.Rodents-Montreal.ORG>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
X-Composition-Start-Date: Thu, 16 Dec 2010 12:54:01 -0500 (EST)
In-Reply-To: <>
References: <> <p06240809c928635499e8@[]> <> <> <> <> <> <> <> <> <2229.1292235952.971571@puncture> <> <2229.1292239384.281779@puncture> <> <> <> <> <>
X-Mailman-Approved-At: Fri, 17 Dec 2010 14:11:47 -0800
Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Dec 2010 18:25:55 -0000

>> * 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
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B