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

Ben Laurie <> Thu, 06 January 2011 15:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 787FA3A6C33 for <>; Thu, 6 Jan 2011 07:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.855
X-Spam-Status: No, score=-103.855 tagged_above=-999 required=5 tests=[AWL=-1.879, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EIyOTHfIzS39 for <>; Thu, 6 Jan 2011 07:29:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E30B53A6D14 for <>; Thu, 6 Jan 2011 07:29:47 -0800 (PST)
Received: from ( []) by with ESMTP id p06FVrqC008803 for <>; Thu, 6 Jan 2011 07:31:53 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=beta; t=1294327914; bh=UP69RRHWGGYUU/4X7jvHl3J8mX4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=u8nc7/xQZ+AARX/yPFSLYnoxdm3MNriL6XXSM3oYTi9uTzHemKJl8EeU6i0qQkJCF DTLfKTFQS5p8DHzPhqxoA==
Received: from qyj19 ( []) by with ESMTP id p06FVmHf020772 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <>; Thu, 6 Jan 2011 07:31:52 -0800
Received: by qyj19 with SMTP id 19so17694829qyj.12 for <>; Thu, 06 Jan 2011 07:31:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4HF7vbiBG5YS3CoUX9wu70DOSHl4iLZrUnsX4DNBd8w=; b=BWKqmSdEvTDeyQ2eqttv3+gBNEmZ8ZTujH6HL3DADxzsmbBUAlcazFi9amXmpe/stX C8Xwy0FBWlv0jfqgUknQ==
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hH30kqLSSKa1ZEPU9Hu/va/17y7O5RquFN4F2cWEnZwLtv6zPxOQENUmecs1T29R8b EpxWBDsyopxO1loOVpOQ==
MIME-Version: 1.0
Received: by with SMTP id he7mr2980674qcb.104.1294327911945; Thu, 06 Jan 2011 07:31:51 -0800 (PST)
Received: by with HTTP; Thu, 6 Jan 2011 07:31:51 -0800 (PST)
In-Reply-To: <>
References: <> <p06240809c928635499e8@> <> <> <> <> <> <> <> <>
Date: Thu, 06 Jan 2011 15:31:51 +0000
Message-ID: <>
From: Ben Laurie <>
To: Robert Sayre <>
Content-Type: multipart/alternative; boundary="00163630f5376a161c04992f33be"
X-System-Of-Record: true
X-Mailman-Approved-At: Thu, 06 Jan 2011 08:34:53 -0800
Cc: "" <>, "Roy T. Fielding" <>, websec <>, "" <>, "" <>, "" <>, " Group" <>
Subject: Re: [apps-discuss] [websec] [kitten] [saag] 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, 06 Jan 2011 15:29:49 -0000

On 6 January 2011 01:28, Robert Sayre <> wrote:

> > Peter Saint-Andre <> wrote:
> > 2. In 2007, Robert Sayre put together a few slides on the topic:
> >
> These are back on the Web, in case anyone missed them (probably not).
> On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding <>
> wrote:
> >
> > Define them all and let's have a bake-off.  It has been 16 years since
> > HTTP auth was taken out of our hands so that the security experts could
> > define something perfect.  Zero progress so far.
> I think the IETF might do better to focus on a smaller problem, at
> first. People often use self-signed certificates with HTTP/TLS, even
> though the first thing their websites ask the user to do is type a
> username and password into a form. There are some well-understood ways
> to make this process more secure. Why hasn't the IETF fixed this
> problem? If this smaller problem has no ready solution, then the
> larger issue of authentication on the entire Web seems like a tough
> nut to crack.

Two comments (one really being a response to Roy):

1. The IETF has fixed the problem, but no-one is using the fix - perhaps
because it is not clear that it is the fix. I speak of RFC 4279, TLS
pre-shared keys. These could be derived from a hash of the password and the
site name, for example, and thus provide secure mutual authentication
despite password reuse.

2. I have often heard (though I am not aware of hard evidence for this,
nevertheless I find it plausible) that one reason no-one has bothered to
improve HTTP auth is because no-one would use it since site owners want to
control the user experience around signin. It seems to me, therefore, that
HTTP is the wrong layer to fix the problem at - it needs to be pushed down
into HTML or Javascript so that the page can control the look, while
appropriate HTML elements or JS code can deal with the secure exchange of

Of course, this still leaves the issue of trusted path: although we can
provide elements which are safe to use, even when being phished, how does
the user know those elements are actually being used, rather than simulated
so as to get hold of the underlying password?

The answer to this problem is hard, since it brings us back to taking the UI
out of the sites hands.

> It could be that the reasons for this lack of progress are
> nontechnical. Just throwing that out there.

If you think UI is nontechnical, then I agree.