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

Marsh Ray <marsh@extendedsubset.com> Thu, 16 December 2010 19:31 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5B93A69C8; Thu, 16 Dec 2010 11:31:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level:
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaS+aehBc6ck; Thu, 16 Dec 2010 11:31:18 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 435043A69C7; Thu, 16 Dec 2010 11:31:17 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1PTJZW-000DRV-CF; Thu, 16 Dec 2010 19:33:02 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8B07360C6; Thu, 16 Dec 2010 19:32:58 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/FJrTY9uCYiXUNsZ5gCCuFYP7jyQqh5RI=
Message-ID: <4D0A6969.7010309@extendedsubset.com>
Date: Thu, 16 Dec 2010 13:32:57 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: der Mouse <mouse@Rodents-Montreal.ORG>
References: <4D02AF81.6000907@stpeter.im> <p06240809c928635499e8@[10.20.30.150]> <ADDEC353-8DE6-408C-BC75-A50B795E2F6C@checkpoint.com> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <A23730A9-728B-4533-96D7-0B62496CC98A@checkpoint.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> <4D0672F2.4070600@extendedsubset.com> <201012161827.NAA03511@Sparkle.Rodents-Montreal.ORG>
In-Reply-To: <201012161827.NAA03511@Sparkle.Rodents-Montreal.ORG>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 17 Dec 2010 14:11:20 -0800
Cc: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, ietf-http-wg@w3.org, saag@ietf.org
Subject: Re: [apps-discuss] [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Dec 2010 19:31:19 -0000

On 12/16/2010 12:27 PM, der Mouse wrote:
>
> 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.)

Which is a good argument for it being an example of something a computer 
is better at. Many auth systems have a component which involves 
something humans are good at and computers are lousy at.

> Certificates, at best, determine that some device which is capable of
> performing the cryptographic operations has been given access to the
> corresponding private data....   All passwords demonstrate is
> that some device capable of injecting data into the comm channel in
> question knows the password.

That's a good way to describe it.

> But passwords rarely lull people into
> forgetting the difference.

Pen-and-paper signatures work because people have thousands of years of 
history behind pen technology. It fits well the courtroom test "did you 
or did you not sign that document". It surely happens, but is extremely 
rare that someone who actually signed a contract would later claim that 
it was a forgery, or that their pen and paper were compromised by an 
attacker.

>> 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.

OK so there's a baseline attack rate for any given port number. If you 
use the system infrequently enough, attackers outweigh the legitimate users.

But, for example, I personally mistype my password about 10 to 25% of 
the time. That's a correct 'authentication denied' scenario but it's not 
an attack. Systems with a meaningful amount of legitimate activity, and 
are not specially targeted for some reason, are going to have many more 
mistyped passwords than credible attacks.

>> 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.

I bet for a lot of systems, people sign up once and try it out then go 
away and leave their accounts dormant. E.g., I might create an account 
to buy tickets for something and never go back.

So why can't the attacker attack it that one time then?

You've never signed up for a new account from a hotel or a public wifi?

Even still, how do you convince a web designer that they must give up 
their HTML login form for security when they have an HTML login form to 
choose the password in the first place?

- Marsh