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

Yaron Sheffer <> Mon, 13 December 2010 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A940F28C113; Mon, 13 Dec 2010 07:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oZ8HbcaePJoN; Mon, 13 Dec 2010 07:31:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9A8C328C111; Mon, 13 Dec 2010 07:31:28 -0800 (PST)
Received: by wyf23 with SMTP id 23so6133663wyf.31 for <multiple recipients>; Mon, 13 Dec 2010 07:33:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+0szgrNyk3mkmUDxf309oDZ+9GRtr8meNZqDA8AcMUE=; b=dNDusxC6geA5feEhxkQO/3IBIf77RSA4FBQR+bRQEH5tRXO/8PbfYInvGtfM9K8trB hcCmyCPLhLZDyJghltMS9GriRS04fRXtgKCYQbBqKzCt67nUbMaoehetoJAzO/+z7NgW Qd/tH93nfYIo2etamhq1o40Uf5iY0/vfVQCus=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ordqzJOVIbEfXFOsrikEoukznWeWMJCAiKTavCcDclq3YG2b4+ifhCv+/xIbEbrVvF bUpQvvk84xgm+pBbhP2bOCrwpM3LeQDpzqpCaAtJBKdvymqaMMv5wGqUxNRmsyHZ+S/T Mco8vjpjuS7KD/s07YacFrp4iBmzd1JkDQZMU=
Received: by with SMTP id s10mr1735853wbw.61.1292254386127; Mon, 13 Dec 2010 07:33:06 -0800 (PST)
Received: from [] ( []) by with ESMTPS id m10sm4489129wbc.16.2010. (version=SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 07:33:04 -0800 (PST)
Message-ID: <>
Date: Mon, 13 Dec 2010 17:32:53 +0200
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Yoav Nir <>
References: <> <p06240809c928635499e8@[]> <> <> <> <> <> <> <> <> <2229.1292235952.971571@puncture> <> <2229.1292239384.281779@puncture> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 13 Dec 2010 09:50:51 -0800
Cc:, General discussion of application-layer protocols <>, websec <>, - Next Generation <>, "" <>, " Group" <>, "" <>
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: Mon, 13 Dec 2010 15:31:32 -0000

Just like the phrase "I am not a lawyer" is always followed by amateur 
legal advice (I know that for sure, I've done it myself), the same goes 
for "I am not a UI expert".

Two comments:

- There are in fact a few security-usability experts. I don't know if 
any of them participate in the IETF. This is an emerging research field, 
see e.g.

- (I am not a UI expert, but...) Devising UI cues is extremely 
difficult. People will gladly enter their password when the web site 
displays a JPEG-rendered padlock icon. In fact *legitimate* sites have 
been known to display such icons, strange as it may sound.


On 12/13/2010 03:08 PM, Yoav Nir wrote:
> On Dec 13, 2010, at 2:14 PM, Carsten Bormann wrote:
>> On Dec 13, 2010, at 12:23, Dave Cridland wrote:
>>> every webapp currently uses a form
>> Yes.  Nice demonstration of conflicting requirements.
>> As a webapp developer, I want to control the user interface during authentication.
>> Leaving the user alone with the bland and unforgiving browser user interface for HTTP auth is suicide.
>> I want to provide extra buttons for forgotten passwords, maybe even password hints, and a "sign up" method.
>> HTML/CSS/JS lends itself well to providing such a friendly user interface.
> Yes. That's a big part of the problem. To get the security result we're looking for, the login field has to be clearly marked. A user should never be allowed to make the mistake of thinking that a regular input field is actually the password field. With Basic Auth you get some very distinctive clues (like the sheet in Safari).  So if we invent<input type="password_2.0" />, how can the browser show it that would not be possible to replicate with HTML/CSS/JS ?
>> As a security geek, I recognize this as exactly the problem that creates the potential for phishing.
>> Having the user type credentials into a random form is never going to be secure, HSTS notwithstanding.
> Agree.
>> Maybe the only way to address both requirements is to have something in HTML/CSS/JS that addresses authentication interactions.
>> Replacing<input type="password"/>  for the 21st century.  This would allow web app designers to design a nice context for this interaction, and would allow running security protocols that are binding themselves to a browser-server security association that may be identical to or different from the TLS envelope.  "Storing passwords" in the browser might turn into storing those security associations.
> I don't think the security requirements can be met using this (although I'd love to hear differently from browser people). Maybe if we could customize the authentication dialog with some kind of icon (like favicon), and maybe a frame or a div with some HTML elements (buttons, links).  I am not a UI expert (IANAUIE ?) but I think it's important that user authentication be quite distinct from the rest of the flow. IOW the user should know that at this point, she is not just surfing, but actually authenticating to a particular server, and if she's ever presented with some web form that says "username:_______ password:_______" she's going to know that something is wrong.
>> This is not "HTTP authentication", but it might be more useful in the long run.
>> We'll need the browser people to start any such effort.
> Fully agree. We really need to hear from both browser people and web application developers. No point in designing something really secure if the people in google/amazon/BOA then say "no, we'll never use that"
>> Gruesse, Carsten
>> PS.: And I'd still like to have some better form of authentication for machine-to-machine that can be independent from the TLS envelope.  But that is a completely different animal.
>> _______________________________________________
>> websec mailing list
>> Scanned by Check Point Total Security Gateway.
> _______________________________________________
> saag mailing list