Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06

Julian Reschke <julian.reschke@gmx.de> Fri, 20 February 2015 13:32 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE731A8ACA; Fri, 20 Feb 2015 05:32:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.916
X-Spam-Level: *
X-Spam-Status: No, score=1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=2.795, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMx8DASgCR1L; Fri, 20 Feb 2015 05:32:52 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49551A8A16; Fri, 20 Feb 2015 05:32:51 -0800 (PST)
Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M3RVA-1XYD6i2Nxg-00r3ZF; Fri, 20 Feb 2015 14:32:36 +0100
Message-ID: <54E7376C.5070303@gmx.de>
Date: Fri, 20 Feb 2015 14:32:28 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net>
In-Reply-To: <871tllbw2c.fsf@alice.fifthhorseman.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:FxBtHdFQoQRz5einn3CQUP/I1Xg+hR4Lg47uZ0NiGcZ1jAGmfgL /21WNPOT1VeeZycDk5+PBCBFN5Gxsz864Clp93MV8/UKjnb4xGRxnxVmLX4/JmEvF3GBw1Y MvMOtJKG4uJkAY5hFI0520q7VZy/382T4WEVAta/L6/SRVra7FmaOrLSVS4VLMgwmb8tcPx mxBolQWHnXHXUQNxpxcEA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/4oprVYeawx9U_kbJw4VnYx_NOcY>
Cc: "http-auth@ietf.org" <http-auth@ietf.org>, draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2015 13:32:53 -0000

On 2015-02-19 19:22, Daniel Kahn Gillmor wrote:> ...
 > I don't have the bandwidth to craft something fancy right now, but
 > here's a first stab that you're welcome to carve up as you see fit, if
 > no IETF references are forthcoming:
 >
 >     Servers and proxies requiring Basic Authentication must store user
 >     passwords in some form in order to verify the request's
 >     Authorization: header.  These passwords should be stored in such a
 >     way that a leak of the password table doesn't make them trivially
 >     recoverable.  This is especially when users are allowed to set their
 >     own passwords, since users are known to choose weak passwords and to
 >     reuse them across authentication realms.  While a full discussion of
 >     good password hashing techniques for HTTP Basic Authentication is
 >     beyond the scope of this document, server operators should make an
 >     effort to minimize risks to their users in the event of a password
 >     table leak.  For example, servers should not store user passwords in
 >     plaintext or as unsalted digests.  For more discussion about modern
 >     password hashing techniques, see [PHC].
 >
 >   [PHC] https://password-hashing.net Password Hashing Competition
 >
 > (i've used "should not" instead of RFC 2119 "SHOULD NOT" above because
 > this is not a recommendation about the on-the-wire protocol.  If anyone
 > thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd be happy to
 > see that happen, because this is seriously low-hanging fruit, and i'm
 > sure there are still operators out there disregarding it.
 > ...

I have added very similar text with 
<http://trac.tools.ietf.org/wg/httpauth/trac/changeset/125>):

 >>    Servers and proxies implementing Basic Authentication need to store
 >>    user passwords in some form in order to authenticate a request.
 >>    These passwords ought to be be stored in such a way that a leak of
 >>    the password data doesn't make them trivially recoverable.  This is
 >>    especially important when users are allowed to set their own
 >>    passwords, since users are known to choose weak passwords and to
 >>    reuse them across authentication realms.  While a full discussion of
 >>    good password hashing techniques is beyond the scope of this
 >>    document, server operators ought to make an effort to minimize risks
 >>    to their users in the event of a password data leak.  For example,
 >>    servers ought to avoid storing user passwords in plaintext or as
 >>    unsalted digests.  For more discussion about modern password hashing
 >>    techniques, see the "Password Hashing Competition"
 >>    (<https://password-hashing.net>).

Thanks for the proposal!

Best regards, Julian