Re: [websec] [saag] Fwd: [http-auth] re-call for IETF http-auth BoF

Marsh Ray <marsh@extendedsubset.com> Thu, 23 June 2011 21:05 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD111E819D; Thu, 23 Jun 2011 14:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O9sRKyYjg8G; Thu, 23 Jun 2011 14:05:49 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id BF7C511E819B; Thu, 23 Jun 2011 14:05:49 -0700 (PDT)
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 1QZr5x-000Fe9-6F; Thu, 23 Jun 2011 21:05:49 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A93A56073; Thu, 23 Jun 2011 21:05:31 +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: U2FsdGVkX18l9WmfuTCvaaqQMCGHl4jfTaoGBBgkS34=
Message-ID: <4E03AA9B.4030709@extendedsubset.com>
Date: Thu, 23 Jun 2011 16:05:31 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: Yutaka OIWA <y.oiwa@aist.go.jp>
References: <trg0YszL9F4Q.471l1SVV@smtp.o2.co.uk> <BANLkTi=seeFm0F0TFoA9__uERg_F1L37Tg@mail.gmail.com> <E3C31DB7-6AAA-4EF0-BA5F-BBE7C7EA6EEA@w3.org> <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <BANLkTikR9Ud5-yFzjYxu+V0vqcQCExyF4g@mail.gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> <BANLkTimChRk2mpKLTQ9Cg+6QKy0eaxcwpg@mail.gmail.com>
In-Reply-To: <BANLkTimChRk2mpKLTQ9Cg+6QKy0eaxcwpg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "public-identity@w3.org" <public-identity@w3.org>, "http-auth@ietf.org" <http-auth@ietf.org>, "websec@ietf.org" <websec@ietf.org>, gogwim@unijos.edu.ng, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [websec] [saag] Fwd: [http-auth] re-call for IETF http-auth BoF
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2011 21:05:50 -0000

On 06/22/2011 09:36 PM, Yutaka OIWA wrote:
> 2011/6/23 GOGWIM, JOEL GODWIN<gogwim@unijos.edu.ng>:
>> Supported.
>> Weak and predictable passwords should be avoided.
>
> I ideally agree, but in reality I hesitate to agree with it
> with technical means and backgrounds.

How is the IETF or w3 going to define "weak password" anyway?

Even if there were a way, it's common to see users getting hacked these 
days because the use the same (possibly strong) password at multiple sites.

It's best to pick a completely unique, strong password (12 or more 
characters) for each and every site. But unless you're some kind of 
savant, this requires writing these passwords down somewhere.

But instead, users are taught not to write their passwords down (mostly 
by employers who don't want it to end up on a sticky note in an obvious 
place). So users either pick simple passwords and/or they use the same 
one at every site.

> Of course, even if we introduce such "secure" password registration protocol,
> I foresee that some people will continue to stick on plain-text password
> registration for various reasons.  For example, if a law had required
> some servers (e.g. financial entities) to check and reject such predictable passwords,
> we would have no way to secure it.

That would be a bad law.

I don't think a protocol design can or should defend against bad laws.

At least in the US, financial institutions don't have such laws. They 
instead have a patchwork of audit requirements, industry standards, best 
practices, compliance, etc.. Which is probably better than passing laws 
about password complexity requirements, all things considered.

> For such purposes servers will
> continue to receive raw passwords and computes password-hashes
> (or whatever equivalent) on the server-side.
> But I think that providing a possibility to securely registering passwords
> to servers are one of required things to do for us.

This is far more important than working out ways to accommodate sites 
that want or need to transfer the password in clear text. Those sites 
are already able to do that just fine.

Ideally the technology would somehow prevent a site from accepting (or 
doing anything useful with) the user's plaintext password within the 
page. This would allow the browser to remove any ambiguity for users 
which would be exploitable by phishing.

The simplest message and the one that will "sink in" with the most users 
is: "You should never type this password into any web page or program 
except this unmistakable piece of browser chrome. Not to verify your 
account info, not to reset your password, not to receive tech support 
from someone you trust, and not even to see free pictures of kittens."

It would be amazing if we could get there, but browser vendors and sites 
conspire against us to defeat it.

- Marsh