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

Marsh Ray <marsh@extendedsubset.com> Fri, 14 January 2011 17:05 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 B06A53A6BA3; Fri, 14 Jan 2011 09:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level:
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 yVAyY+betpQV; Fri, 14 Jan 2011 09:05:15 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 74AE43A6B9A; Fri, 14 Jan 2011 09:05:15 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1Pdn7h-0004Py-OE; Fri, 14 Jan 2011 17:07:37 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4809C603E; Fri, 14 Jan 2011 17:07:33 +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: U2FsdGVkX18lbvaEQEauG/YHYvKNkaHDVNFTUVsfTMQ=
Message-ID: <4D3082D5.6070801@extendedsubset.com>
Date: Fri, 14 Jan 2011 11:07:33 -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: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <E1PdZLM-0001Nu-MT@login01.fos.auckland.ac.nz>
In-Reply-To: <E1PdZLM-0001Nu-MT@login01.fos.auckland.ac.nz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 14 Jan 2011 10:23:01 -0800
Cc: apps-discuss@ietf.org, benl@google.com, dwm@xpasc.com, websec@ietf.org, kitten@ietf.org, zedshaw@zedshaw.com, http-auth@ietf.org, ietf-http-wg@w3.org, hallam@gmail.com, saag@ietf.org
Subject: Re: [apps-discuss] [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: Fri, 14 Jan 2011 17:05:16 -0000

On 01/13/2011 08:24 PM, Peter Gutmann wrote:
> Marsh Ray<marsh@extendedsubset.com>  writes:
>
>> Phishing can be said to have been prevented only when the user can
>> be relied upon to refuse to enter his password into an insecure
>> box.
>
> I think you need to phrase that more generally, "when the user can be
> relied upon to not authenticate to the wrong site", because there's
> more ways of authenticating around than just typing a string into a
> web form.

I was trying to be as general as possible but still thinking in terms of 
phising for passwords.

(This conversation has bounced around a bit between "better HTTP 
password authentication don't you dare mention client certificates" and 
"open-minded discussion of login authentication methods". I'm happy to 
contribute to whatever, but we risk 
miscommunication-mistaken-for-disagreement unless we settle on the scope 
first.)

The term "authenticate to the wrong site" has completely different 
meaning depending on whether or not we're talking about 
capture-and-reuse credentials like passwords or whether or not we're 
assuming encryption which authenticates the server to the user (https).

So I was thinking of "password into insecure box" as being more general. 
Maybe the attack somehow doesn't even involve the "wrong site", maybe 
bad guy injects something into the right site instead?

> For example some password managers do site-specifc
> passwords, so even if you go to the wrong site you can't accidentally
> provide your credentials for the correct site.

OMG, I can't stand it when I type the right password (for something 
else) into the wrong box. I admit that I have not always immediately 
changed that password when I've done it into a computer I also sort-of 
trusted (but in a different scope).

> Site images rate
> more as a security gimmick than any real security measure.

It'd be interesting to know if banks get an actual reduction in the rate 
of phishing from that.

On 01/13/2011 08:33 PM, Peter Gutmann wrote:
> Phillip Hallam-Baker<hallam@gmail.com>  writes:
>
>> Such users have asked to do business with hundreds of entities, so
>>  at least something is working right.
>
> Actually they haven't asked to to business with most of them, but
> are required to have an account for
> user-tracking/spam-defeating/who-knows-what purposes.

Yep. I guess I was counting things like Slashdot and Twitter as "doing 
business", even though it wasn't a monetary transaction. There is some 
value stored in those credentials, or at least pain-in-the butt 
potential costs to me if they were compromised for some reason.

> If browsers
> provided a basic "generate a random password just for this site"
> feature, as many password managers have been doing for years and
> years, then we could focus on the tiny fraction of sites where
> authentication really matters.

That would be convenient, but how many people back up the password 
manager in their browser? I don't, I prefer to write them down.

I use multiple computers and multiple browsers. No browser has every 
password. Encouraging them to be centralized in the browser seems less 
than ideal, since it's the browser that gets pwned more than anything else.

> Two major problems that we initially
> need to overcome are:
>
> 1. Browsers (I'm using this as a generic for "client-side software")
> treat all passwords as being equal, from your high-value banking
> one to your throwaway knitting-patterns-blog one.

Yes, I agree that's a big problem.

I don't think we should think of them as being fully-ordered on a 
dimension of 'value' however.

For example, let's say I have:

A. Password for current employer's single-sign-on Kerberos/Active 
Directory infrastructure.

B. Password I use at job-hunting website

C. Password I use for my pseudonym where I flame newbies and post 
obscene patterns on the knitting patterns blog.

My work desktop computer will most likely be backdoored by my employer. 
They may not care about C, but I care greatly that they do not find B.

I log in to the employer from a home PC or smartphone from a VPN A. I 
may have a sense of responsibility about protecting A, but apparently 
I'm looking for a new job anyway. I'm more interested that prospective 
employers don't find out about C.

 From a public internet terminal I may not care at all about accessing C 
because it doesn't seem plausible that it would associate back with my 
professional identity.

> 2. Browsers (ditto) have close to zero support for even the most
> basic password management that any number of plugins and add-ons have
> had for years (the Firefox 3.6 password manager is, AFAICT, unchanged
> since the Netscape 2.0 one from fifteen years ago).

It works sort of OK for me. But I'm only happy with it because I 
wouldn't trust it with all of my passwords regardless of how .

> If we could start to address this, and at least begin to bound the
> problem, we've made a start.  Theorising about blue-sky solutions
> isn't useful when we haven't even defined the real problem we're
> trying to solve.

Yes, let's resist the attraction of actual solutions until we have 
defined the problem to death. The possible solutions and their pros and 
cons of will usually be obvious by that point.

- Marsh