Re: [Cfrg] [saag] New draft: Hashed Password Exchange

Steven Bellovin <smb@cs.columbia.edu> Sun, 11 March 2012 12:53 UTC

Return-Path: <smb@cs.columbia.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3017D21F84BF for <cfrg@ietfa.amsl.com>; Sun, 11 Mar 2012 05:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.72
X-Spam-Level: **
X-Spam-Status: No, score=2.72 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAqoGF-d6ZjG for <cfrg@ietfa.amsl.com>; Sun, 11 Mar 2012 05:53:45 -0700 (PDT)
Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6876021F84B2 for <cfrg@irtf.org>; Sun, 11 Mar 2012 05:53:45 -0700 (PDT)
Received: from [192.168.1.183] (46-117-231-34.bb.netvision.net.il [46.117.231.34]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q2BCrYmv005426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 11 Mar 2012 08:53:43 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=GB2312
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <OFE5B4F6A2.A17AFEF9-ON48257997.002D1C71-48257997.002D29C8@zte.com.cn>
Date: Sun, 11 Mar 2012 00:32:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <388059C0-E097-43D6-8472-B8874D535140@cs.columbia.edu>
References: <OFE5B4F6A2.A17AFEF9-ON48257997.002D1C71-48257997.002D29C8@zte.com.cn>
To: zhou.sujing@zte.com.cn
X-Mailer: Apple Mail (2.1257)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] [saag] New draft: Hashed Password Exchange
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Mar 2012 12:53:46 -0000

On Feb 1, 2012, at 3:13 AM, zhou.sujing@zte.com.cn wrote:

> 
> Hi,all 
> 
> cfrg-bounces@irtf.org 写于 2012-01-07 17:03:25:
> 
> > 
> > 
> > On Wed, January 4, 2012 2:56 pm, Steven Bellovin wrote:
> > > Good point; let me think about it for -01.  An obvious solution is to send
> > > the hostname with the effective password.
> > 
> >   How is that different than using random salt then? If _something_ is
> > going to be sent shouldn't it be a uniformly random bitstring instead of
> > a hostname?
> > 
> >   A uniformly random bitstring would be more appropriate as a key to
> > HMAC than a highly structured string like a password too. Iterate
> > HMAC(salt, password | service-URI) instead of HMAC(password, service-URI). 
> 
> 
> 
> I think Dan's suggestion is reasonable, I checked the RFC 2104 and found the following section : 
> 
> "3. Keys 
> 
>    The key for HMAC can be of any length (keys longer than B bytes are 
>    first hashed using H).  However, less than L bytes is strongly 
>    discouraged as it would decrease the security strength of the 
>    function.  Keys longer than L bytes are acceptable but the extra 
>    length would not significantly increase the function strength. (A 
>    longer key may be advisable if the randomness of the key is 
>    considered weak.) 
> 
>    Keys need to be chosen at random (or using a cryptographically strong 
>    pseudo-random generator seeded with a random seed), and periodically 
>    refreshed.  (Current attacks do not indicate a specific recommended 
>    frequency for key changes as these attacks are practically 
>    infeasible.  However, periodic key refreshment is a fundamental 
>    security practice that helps against potential weaknesses of the 
>    function and keys, and limits the damage of an exposed key.)" 
> 
> 
> Since passwords are often not too long, and not so random, it is better 
> to hash it before using it as a key in a HMAC. 

Although hashing the password first certainly doesn't hurt, I read that
text as more related to brute force attacks against the key, rather than
to any limitation of the underlying function.  Hugo -- are you on this list?
Could you clarify?

		--Steve Bellovin, https://www.cs.columbia.edu/~smb